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

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 03.12.2011 11:44, Ian Campbell wrote:
> 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.
> 
At least in my limited experiments, this was not any issue. Though any newer
installation uses grub2 and uuids. The grub stage was working most of the time
(beside initial interrupt related problems). It was more the missing pv modules
and the default to unplug emulated devices, that caused later stages to go not
so smoothly. And finding that there is a way to configure NICs that seems to
work in any combination of pci platform and tool stack sounds like a good way
forward. It just seems that sometimes there are a bit too many knobs to frob and
twiddle. ;)

-Stefan
> Ian.
> 
> 
> 


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