Stefano,
I guess you mean the paravirtualized ones to be preferred.
Ooops, yes :-)
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).
Would this not break booting a non-PV driver equipped kernel? In the
general case, we don't know what guests will be booted (up to the
customer).
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.
The /dev/sda that is there is the emulated devices. xen_watch (judging
by the call trace) is trying to create another /dev/sda, presumably
for the paravirtualised device (given the call path through blkfront).
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.
The technology is simply ensuring the modules in the kernel initialise
in the right order. This makes UUID and label mounting prefer PV drivers.
It's described here:
http://blog.alex.org.uk/2010/05/09/linux-pv-drivers-for-xen-hvm-building-nor
mally-within-an-arbitrary-kernel-tree/
with patches.
I think our current method is to use a modular sd_mod and a builtin
blkfront etc., but it's possible to do it without that.
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.
That's easier said than done on a running platform with large numbers
of nodes, a huge variety of operating systems etc.; we have Xen 4 working
in the lab, but the code change our end is very substantial,
My first priority is to ensure 2.6.37 doesn't break anything (that's
fine, because it comes up without PV drivers which is no worse than
2.6.36). My second priority is to try and allow end users to get
2.6.37+ working with PV drivers easily (so adding grub command line
options is doable).
--
Alex Bligh
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home