Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 01/06/16 16:36, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail 
> to boot from xvda"):
>> On Tue, May 31, 2016 at 12:41 PM, Olaf Hering <olaf@xxxxxxxxx> wrote:
>>> I think if some domU.cfg for xen-4.3+ has 'vdev=xvd*' and the domU uses
>>> for some reason kernel names in config files and the domU uses a
>>> xenlinux kernel, then changing domU.cfg to 'hd*' will allow the guest to
>>> boot again. But its userland will miss the /dev/xvd* device nodes.
>>> That probably remained unnoticed during testing the referenced commit if
>>> a pvops based kernel was used.
> 
> Linux doctrine, at least, nowadays, is that hd* device names are not
> stable.  On my own colo machine I find that on some boots the actual
> hard disks are sda and sdb and the emergency usb stick is sdc, but on
> other boots the disks are sdb and sdc and the usb stick is sda.  So
> some would say that what you are doing is inherently unstable.
> 
> But I don't think I really agree with that view.  I think we should be
> able to do better.
> 
>> Really 'vdev' string in the the guest config file is only meant to
>> tell libxl how it should behave -- it should ideally not have any
>> effect on what devices you see in the backend.
> 
> The vdev specifies the virtual block number.  See vbd-interface.txt.
> hda and xvda have different numbers.
> 
>>  And furthermore, it
>> seems to me that when Linux upstream rejected the idea of the pv
>> drivers stealing the "hd*" namespace, that SuSE's xenlinux should have
>> followed suit and had the pv drivers only create devices named xvd*.
> 
> Right.  This is the root cause.  vbd-interface.txt is designed to cope
> with modern PV frontends which never steal the hda minor numbers.
> 
> I think we should fix this with a syntax for explicitly specifying a
> pv-only device with the hd* pv block number.

Olaf,

Would this be a suitable solution for you, and do you think you
understand the suggestion well enough / have enough time to write up a
patch?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel