[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Ian.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.