[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] 2.6.37 PV on HVM issues
OK. How modern a version of Xen am I meant to need to run 2.6.37?
You need xen 3.4 or later.
Thanks, that's useful.
version of Xen supports non-inline pvdrivers fine.
They use hacks to disable the emulated interfaces that couldn't possibly
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
> 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
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.
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.
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
Xen-devel mailing list