Hi
Is it true that the GPLPV drivers is incompatible with QCOW images?
The Windows DomU works fine with raw standard "file:/" images, and
paravirtualized Linux DomU works fine with QCOW and raw images.
If i use QCOW images with my Windows DomU''s i get a stop error:
0x00000007b (inaccessible boot device).
It looks like the blkback.3.hda process, that normally starts with
normal raw backend, doesnt get started with tap:qcow disks.
Instead i get this repeating entry in the qemu log:
XenPCI Still waiting for 2 (currently 1)...
XenPCI Still waiting for 2 (currently 1)...
XenPCI Still waiting for 2 (currently 1)...
Any ideas?
/Martin
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
What version of Xen are you running? I've never been able to get
tap:{aio,cow} to work with the GPL PV drivers under Xen 3.2.x. However,
James Harper has reported that they work find under Xen 3.3.x.
-Nick
-----Original Message-----
From: Martin Kjær Jørgensen <shaoh@gotu.dk>
To: xen-users@lists.xensource.com
Cc: james.harper@bendigoit.com.au
Subject: [Xen-users] GPL PV TAP cow incompatible?
Date: Thu, 26 Feb 2009 16:32:48 +0100
Hi
Is it true that the GPLPV drivers is incompatible with QCOW images?
The Windows DomU works fine with raw standard "file:/" images, and
paravirtualized Linux DomU works fine with QCOW and raw images.
If i use QCOW images with my Windows DomU's i get a stop error:
0x00000007b (inaccessible boot device).
It looks like the blkback.3.hda process, that normally starts with
normal raw backend, doesnt get started with tap:qcow disks.
Instead i get this repeating entry in the qemu log:
XenPCI Still waiting for 2 (currently 1)...
XenPCI Still waiting for 2 (currently 1)...
XenPCI Still waiting for 2 (currently 1)...
Any ideas?
/Martin
This e-mail may contain confidential and privileged material for the sole use of
the intended recipient. If this email is not intended for you, or you are not
responsible for the delivery of this message to the intended recipient, please
note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information. In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way. If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox. Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
I''m running Xen 3.3.1 with a patched ioemu-qemu-xen (patched with the qemu_disable_patches.diff patch (6 Jan 2009)) on a Debian Lenny machine. I''ve compiled Xen manually as Lenny only delivers Xen 3.2.1. I''ve also tried with the official ioemu-qemu-xen but with no luck. /Martin Quoting Nick Couchman <Nick.Couchman@seakr.com>:> What version of Xen are you running? I''ve never been able to get > tap:{aio,cow} to work with the GPL PV drivers under Xen 3.2.x. However, > James Harper has reported that they work find under Xen 3.3.x. > > -Nick > > > -----Original Message----- > From: Martin Kjær Jørgensen <shaoh@gotu.dk> > To: xen-users@lists.xensource.com > Cc: james.harper@bendigoit.com.au > Subject: [Xen-users] GPL PV TAP cow incompatible? > Date: Thu, 26 Feb 2009 16:32:48 +0100 > > > Hi > > Is it true that the GPLPV drivers is incompatible with QCOW images? > > The Windows DomU works fine with raw standard "file:/" images, and > paravirtualized Linux DomU works fine with QCOW and raw images. > > If i use QCOW images with my Windows DomU''s i get a stop error: > 0x00000007b (inaccessible boot device). > It looks like the blkback.3.hda process, that normally starts with > normal raw backend, doesnt get started with tap:qcow disks. > Instead i get this repeating entry in the qemu log: > XenPCI Still waiting for 2 (currently 1)... > XenPCI Still waiting for 2 (currently 1)... > XenPCI Still waiting for 2 (currently 1)... > > Any ideas? > > /Martin > > > > > > > > > > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. If this email is not intended > for you, or you are not responsible for the delivery of this message > to the intended recipient, please note that this message may contain > SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In > such a case, you are strictly prohibited from downloading, > photocopying, distributing or otherwise using this message, its > contents or attachments in any way. If you have received this > message in error, please notify us immediately by replying to this > e-mail and delete the message from your mailbox. Information > contained in this message that does not relate to the business of > SEAKR is neither endorsed by nor attributable to SEAKR. >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Could you send me a short description of your setup so that i can compare with my own? It sound like i''m missing some stupid setting somewhere... /Martin Quoting Nick Couchman <Nick.Couchman@seakr.com>:> What version of Xen are you running? I''ve never been able to get > tap:{aio,cow} to work with the GPL PV drivers under Xen 3.2.x. However, > James Harper has reported that they work find under Xen 3.3.x. > > -Nick > > > -----Original Message----- > From: Martin Kjær Jørgensen <shaoh@gotu.dk> > To: xen-users@lists.xensource.com > Cc: james.harper@bendigoit.com.au > Subject: [Xen-users] GPL PV TAP cow incompatible? > Date: Thu, 26 Feb 2009 16:32:48 +0100 > > > Hi > > Is it true that the GPLPV drivers is incompatible with QCOW images? > > The Windows DomU works fine with raw standard "file:/" images, and > paravirtualized Linux DomU works fine with QCOW and raw images. > > If i use QCOW images with my Windows DomU''s i get a stop error: > 0x00000007b (inaccessible boot device). > It looks like the blkback.3.hda process, that normally starts with > normal raw backend, doesnt get started with tap:qcow disks. > Instead i get this repeating entry in the qemu log: > XenPCI Still waiting for 2 (currently 1)... > XenPCI Still waiting for 2 (currently 1)... > XenPCI Still waiting for 2 (currently 1)... > > Any ideas? > > /Martin > > > > > > > > > > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. If this email is not intended > for you, or you are not responsible for the delivery of this message > to the intended recipient, please note that this message may contain > SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In > such a case, you are strictly prohibited from downloading, > photocopying, distributing or otherwise using this message, its > contents or attachments in any way. If you have received this > message in error, please notify us immediately by replying to this > e-mail and delete the message from your mailbox. Information > contained in this message that does not relate to the business of > SEAKR is neither endorsed by nor attributable to SEAKR. >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Mar 2, 2009 at 12:53 AM, Martin Kjær Jørgensen <shaoh@gotu.dk> wrote:> Could you send me a short description of your setup so that i can compare > with my own? It sound like i''m missing some stupid setting somewhere... >In my setup tap:aio works, but tap:qcow doesn''t. I guess it''s a bug. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > On Mon, Mar 2, 2009 at 12:53 AM, Martin Kjær Jørgensen <shaoh@gotu.dk> > wrote: > > Could you send me a short description of your setup so that i can > compare > > with my own? It sound like i''m missing some stupid setting somewhere... > > > > 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? James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Mar 2, 2009 at 3:36 PM, James Harper <james.harper@bendigoit.com.au> 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@lists.xensource.com http://lists.xensource.com/xen-users
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@fajar.net>:> On Mon, Mar 2, 2009 at 3:36 PM, James Harper > <james.harper@bendigoit.com.au> 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@lists.xensource.com http://lists.xensource.com/xen-users
I''ve tried testing the unmoddified drivers for Linux HVM. Apparently tap:aio works but not tap:qcow. This with a patched qemu (ioemu-qemu-xen) patched with recent qemu_disable_patches.diff. My disk config is: disk = [ ''tap:qcow:/xen/test.qcow,xvda,w'', ''tap:qcow:/xen/test2.qcow,xvdb,w'', ''tap:aio:/xen/test3.raw,xvdc,w'', ''file:/root/debian-500-amd64-netinst.iso,hdc:cdrom,r'' ] On Dom0 upon xen-vbd.ko insertion dmesg shows: [13644.995275] blktap: ring-ref 8, event-channel 6, protocol 1 (x86_64-abi) [13644.997697] blktap: ring-ref 9, event-channel 7, protocol 1 (x86_64-abi) [13644.999927] blktap: ring-ref 10, event[ 112.122528] xen-vbd: registered block device major 202 My DomU Linux HVM dmesg shows: [ 112.122528] xen-vbd: registered block device major 202 [ 112.123653] xvdc: unknown partition table [ 112.171299] register_blkdev: cannot get major 22 for ide [ 112.172410] vbd vbd-5632: 19 xlvbd_add at /local/domain/0/backend/vbd/8/5632 Only the tap:aio is shown in the DomU. /Martin Quoting James Harper <james.harper@bendigoit.com.au>:>> >> On Mon, Mar 2, 2009 at 12:53 AM, Martin Kjær Jørgensen <shaoh@gotu.dk> >> wrote: >>> Could you send me a short description of your setup so that i can >> compare >>> with my own? It sound like i''m missing some stupid setting somewhere... >>> >> >> 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? > > James >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users