| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] GPL PV TAP cow incompatible?
I will try testing HVM Linux with PV, and I will return with the
results as fast as i can. Should it be Xen's own "unmodified_drivers"
or the official ones in the main Linux kernel?
/Martin
Quoting "Fajar A. Nugraha" <fajar@xxxxxxxxx>:
On Mon, Mar 2, 2009 at 3:36 PM, James Harper
<james.harper@xxxxxxxxxxxxxxxx> wrote:
In my setup tap:aio works, but tap:qcow doesn't. I guess it's a bug.
When debugging this a while ago I found that tap:* wasn't passing
through the sector count correct. I have since upgraded to 3.3.1
and tap:aio works fine. I haven't tested tap:qcow.
Have you tried with a Linux HVM domain with PV drivers?
It doesn't work :(
I tested with RHEL5.3 x86_64 dom0, Xen 3.3.1, and fully up-to-date
RHEL5.3 x86_64 HVM domU, mapping the disk as xvda (yes, xvda, not hda)
With phy: and tap:aio everything works.
During installation Xen (or qemu, or RH's ide driver) seems to
silently change xvda to hda. After installation completed, I added
xen-vbd to initrd and it can detect two drives: hda and xvda (which is
the same drive, detected by two different driver). Adding
"ide0=noprobe" to grub.conf hides hda, so the disk is working
correctly.
The problem is when I use qcow, the emulated driver (ata_piix) can
detect hda correctly while xen-vbd does NOT detect xvda. Ouch. This
seems to be a Xen bug.
On another note, networking with Linux HVM sucks.
dom0 <-> domU traffic and domU <-> domU traffic on the same dom0
works, but domU <-> outside does not work. Same thing happens with
both realtek driver and xen-vnif driver.
What got me confused was that networking PV Linux domU and HVM Windows
domU (both with and without GPLPV) WORKS PERFECTLY. So I'm facing a
condition where a Windows HVM domU works BETTER than Linux HVM domU.
Ouch.
Regards,
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home