Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2011-12-02 at 18:32 +0000, Alex Bligh wrote:
> Ian,
> 
> --On 2 December 2011 17:42:35 +0000 Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> 
> > Right.
> >
> >> FWIW my experience is that various built-for-cloud type distros don't use
> >> that scheme, mainly because they use grub1 which IIRC does not support
> >> this, and building images in a non-root environment that have grub1
> >> in is rather easier than grub2.
> >
> > UUID= and LABEL= are functions of your initrd (actually udev) and not
> > the bootloader. They work with both grub1 and grub2.
> 
> I /think/ we might be slightly at cross purposes.
> 
> At least when I was busy making images for Xen for PVHVM a couple of
> years ago, the problem is roughly as follows:
> 
> The boot loader needs to know what device to load the kernel and initrd 
> from. To do this (roughly speaking) it needs to know what BIOS device to 
> use. Of course it does not matter whether the boot loader uses the PV 
> device or the emulated device, save that this requires the emulated device 
> be present (at least whilst the boot loader doesn't support drivers for the 
> pv device). The problem is that the device the boot loader accesses is in 
> general specified in the boot loader configuration file not as a bios 
> device number, but as a device name. Equally, it needs to know the device 
> so that it can write the boot sector in order to reinstall the boot loader, 
> set options etc. The problem we ran into here was that this needs to be set 
> to xvda in order to to write the boot sector etc., because the sda device 
> is unplugged. However, it only recognised a BIOS mapping for sda. So 
> neither worked, without fiddling with mappings, but that wasn't possible on 
> a straight install. For some reason, grub1 was far more forgiving.

grub-install /dev/xvdX is supposed to work just as well as
grub-install /dev/sdX depending on which is currently active. If it does
not then you have found a bug and this should be reported against the
grub package in the distro you are using.

This was fixed in grub 1 in Debian Lenny (#456776) and grub2 in Debian
Squeeze (#456777). The grub2 fixes are upstream however grub1 doesn't
have an upstream so other distros may be missing this fix. If you find
this please report it to them. Likewise if you find that this support
has regressed in Debian (or Ubuntu) then please report those bugs to
them.

Please don't just assume that because something is broken for you that
this is the way it must be. Report bugs to the appropriate place and
there is some chance that they will get fixed. Likewise if something was
broken for you "years ago" please don't assume that it has remained so.

> >> So, for instance, all the vm-builder stuff in debian/ubuntu used grub1
> >> and did not work this way.
> >
> > Which ones are these?
> 
> EG:
>  http://packages.ubuntu.com/search?keywords=ubuntu-vm-builder
>  http://wiki.debian.org/VMBuilder
> 
> > The Debian installer uses UUID where it can AFAIK. Ubuntu's installer is
> > derived from Debian's so I'd expect it to be the same.
> 
> There is more than one method of generating debian/ubuntu images
> (debootstrap, multistrap, vmbuilder to name but 3). Some of these
> run an installer, some just generate a working image for a particular
> environment (and it's the latter which are problematic).

If a tools such as these are not correctly generating a PVHVM capable
configuration when possible then IMHO that is a bug in those tools.
Please report it to the tool authors as such.

If you cannot flip between PVHVM and emulated HVM easily then IMHO this
is also a bug (although perhaps less serious) and should be reported as
such, perhaps as a wishlist bug.

> FWIW my understanding is that though Ubuntu and Debian's installers both 
> use the same underlying d-i stuff (or used to), they are now reasonably 
> different (not that this has much bearing on the argument, as the main 
> difference between the two is the kernel which has led to rather different 
> results between the two); certainly which boot loader they use is
> independent of the install architecture, their partitioning schemes
> have been substantially different, and I would expect use of UUID/LABEL
> not necessarily to correspond.

The Ubuntu installer folks are closely involved in Debian installer and
in particular the folks who deal with bootloader type things on both
sides are the same people.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel