| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] 2.6.37 PV on HVM issues
On Thu, 2 Dec 2010, Alex Bligh wrote:
> >> This
> >> version of Xen supports non-inline pvdrivers fine.
> >
> > They use hacks to disable the emulated interfaces that couldn't possibly
> > be upstreamed.
>
> I don't need the emulated interfaces to be disabled. Both the emulated
> interfaces and the PV-Ops ones appear and we use only one of them.
> So, for instance, we see /dev/xvda and /dev/sda. We mount by UUID or label
> and have technology that causes the emulated ones to be preferred (if
> present).
>
I guess you mean the paravirtualized ones to be preferred.
> >> > You can try to enable them anyway at your own risk passing
> >> > xen_emul_unplug=unnecessary to the kernel command line options.
> >>
> >> OK, so I get the following, which looks superficially nasty, but
> >> in fact suggests I need to unplug the disks. But the same happens
> >> with "xen_emul_unplug=unnecessary,all".
> >
> > You could try specifying "xvda" instead of hda in the VM config file,
>
> We're in HVM mode on 3.3.1. I'm not quite sure what you mean here.
> The name "xvda" comes from blkfront.c (or at least it used to last
> time I was playing around with modified_drivers and produced a standalone
> patch into the new kernel). Looking at the current source, it seems
> to still think it's called /dev/xvda. However, something in the
> xen_watch thread is causing it to try and register as /dev/sda
> (even though that exists). Where exactly is it picking this up from?
> IE how is that name being passed through? Is there some new technology
> that causes the device name in the guest to be called something in
> the config file? We're using the same config file (well, system)
> as with the unmodified_drivers based machines, and they come up
> fine with /dev/xvdX.
>
I was referring to the device name in the disk config file option,
usually is "hda" in HVM config files. Some blkfront development versions
don't always create an xvd device, so if you manually specify xvda in
the disk config file you would rule that problem out (even though it
also depends on the behaviour toolstack and I don't remember what xend 3.3
would do).
But in any case upstream blkfront should always create xvd devices so I am
not sure how you could end up with a /dev/sda there.
> > and make sure the root= command line option points to /dev/xvda1 so that
> > there is no confusion with possible emulated paths.
>
> That should make any difference as it just controls which root option
> is mounted. We pass a label or UUID.
>
If you pass a label or a UUID you cannot be sure if you end up using the
emulated or the paravitualized interface, unless xen supports the unplug
protocol.
Maybe the technology you mentioned before solves also this problem for
you.
> > Or you could always disable the IDE driver or blkfront in the kernel.
>
> That would sort of defeat the object. I already have kernels that run
> just fine (and support /dev/xvda and /dev/sda). What I am trying to
> do is to get a stock kernel to run (specifically a stock Ubuntu
> kernel).
>
If you'd like a stock kernel, the best thing to do is upgrade xen, then
you don't need any changes in the guest.
Keep in mind that xen 3.4 was released almost 2 years ago.
If you know what you are doing you can manually remove the check for the
unplug protocol in the kernel, just hack
arch/x86/xen/platform-pci-unplug.c:check_platform_magic.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home