← Back to team overview

openstack team mailing list archive

DevStack, Xen and "Bad archive mirror" error

 

Hi,

I've just tried out DevStack with my XCP 1.6.10 server using the
instructions at

https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md

I hit exactly the same issue that Hu Yanrui mentioned in a mail to the list
last month - see https://lists.launchpad.net/openstack/msg22167.html

I think I've been able to trace down the root cause and, if I'm right, it
traces back to a problem with the README.md file.

Running the 'route' command in a VM command prompt showed that the VM
hadn't been able to autoconfigure an IP address via DHCP. This in turn
caused the "Bad archive mirror" error described by Hu. The reason is that
the boot options created on the VM had "netcfg/choose_interface=eth0".
Checking DevStackOSDomU VM configuration in XenCenter, I saw that its eth0
was bound the vmbr network/VLAN. The xen host management/internet facing
LAN, is eth3.

Boot options are set in line 57 of install_ubuntu_template.sh (
https://github.com/openstack-dev/devstack/blob/master/tools/xen/scripts/install_ubuntu_template.sh
):

   netcfg/choose_interface=${HOST_IP_IFACE} \

>From the comments in xenrc (
https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc)
lines 19-23 it looks like the HOST_IP_IFACE variable relates to the
interface in the DomU VM on which services should be exposed. As far as I
can tell (with very limited DevStack knowledge), the xenrc default of eth3
is *always* correct as the VM interfaces are created by the devstack Xen
scripts themselves.

For some reason, the README.md includes an explicit override of
HOST_IP_IFACE in the localrc example, and unfortunately both the
description and the variable name itself are very misleading to someone not
familiar with DevStack. I naturally (but wrongly) assumed that it was the
interface on the Xen *host* on which to access services - in my case my
management/public network eth0, as opposed to my storage networks on
eth1+eth2. I think Hu made a similar mistake as he had picked eth1. Once I
commented out the HOST_IP_IFACE line from my localrc, I was able to get
through the stack.sh install and service start, and to successfully log
into Horizon. I still can't successfully start an instance, but that's
probably a completely different issue and one I'll look at next.

To avoid other people hitting the same problem, I suggest the following two
lines are removed from README.md:

---
# Interface on which you would like to access services
HOST_IP_IFACE=ethX
---

Alternatively, if there's a good reason for them to be there, perhaps the
comment could be improved to say how the variable should be set and why?

Should I file a bug for this?

Cheers,

Martin