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