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

Re: [Xen-devel] xen_emul_unplug on xen 4.1, HVM guest 2.6.38



On Thu, 27 Oct 2011, Stefan Bader wrote:
> On 27.10.2011 16:08, Stefano Stabellini wrote:
> > On Thu, 27 Oct 2011, Stefan Bader wrote:
> >> On 27.10.2011 15:42, Stefano Stabellini wrote:
> >>> I take we are still talking about PV on HVM guests here.
> >>>
> >>> On Thu, 27 Oct 2011, Stefan Bader wrote:
> >>>> At least one part is not Ubuntu specific. And that is that the unplug 
> >>>> logic
> >>>> decides to unplug emulated devices based on having the pci and the 
> >>>> blkfront
> >>>> driver *available* (built-in or module). But later on the blkfront driver
> >>>> ignores all devices that are not *named* in a way to map to the xvd 
> >>>> major.
> >>>> Which leaves you without any usable devices when you named your disk hda 
> >>>> in
> >>>> the config file and you do not prevent unplugging.
> >>>
> >>> If you name your disk hda (as you should), blkfront is going to create
> >>> /dev/xvda in your guest.
> >>> It is not ignoring your disk, it just using "xvd" to name the device in
> >>> the guest.
> >>>
> >>>
> >>>> Still I would love to see this unplug handling become a bit more 
> >>>> obvious. If
> >>>> unplug was successful, then blkfront should not ignore the devices. Or 
> >>>> maybe
> >>>> just make the config more what-you-write-is-what-you-get and having hd 
> >>>> or sd
> >>>> there only gives you emulated devices and xvd gives you pv devices.
> >>>
> >>> Yes, if the unplug is unsuccessful blkfront should not ignore the
> >>> device: it is going to create a /dev/xvd* for you.
> >>
> >> The problem I saw in my test was that in blkfront_probe the following case 
> >> was
> >> hit when the device name was hda in the cfg:
> >>
> >>                 if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY) {
> >>                         int major;
> >>
> >>                         if (!VDEV_IS_EXTENDED(vdevice))
> >>                                 major = BLKIF_MAJOR(vdevice);
> >>                         else
> >>                                 major = XENVBD_MAJOR;
> >>
> >>                         if (major != XENVBD_MAJOR) {
> >>                                 printk(KERN_INFO
> >>                                                 "%s: HVM does not support 
> >> vbd %d
> >> as xen block device\n",
> >>                                                 __FUNCTION__, vdevice);
> >>                                 return -ENODEV;
> >>                         }
> >>                 }
> >>
> >> So major is not XENVBD_MAJOR and the device is ignored.
> >>
> > 
> > Why are you passing xen_emul_unplug=unnecessary?
> > The idea is that if you pass that option you have to use the emulated
> > path to access your disk unless you esplicitely add an xvd disk to your
> > config.
> > 
> > In the normal case, if you don't specify xen_emul_unplug, you are going
> > to get xvda for your hda disk.
> > Then if you use LABEL or UUID in your root= argument, you don't need to
> > change any configuration to make it work.
> 
> Because of the above I have to specify the xen_emul_unplug to get *any* 
> device.

Why?
If you do *not* specify xen_emul_unplug, you should get /dev/xvda
(provided you have blkfront available and hda in your disk config line).


> If I do not specify anything, then (because pci and pv driver are available) 
> the
> emulated disk gets unplugged. Ok. But then the probe does not give me any xvd
> because the major does not match.

that is only because you passed xen_emul_unplug=unnecessary; you
shouldn't do that

> The only form I could make this work was: use xvda in the config file.

you should use hda in the disk config line, and then configure the guest
kernel root= argument with /dev/xvda1 directly or LABEL or UUID
(better).

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


 


Rackspace

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