Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452299 - qcow data disks do not work with windows-xenpv-drivers.
Summary: qcow data disks do not work with windows-xenpv-drivers.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xenpv-win
Version: 5.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Paolo Bonzini
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 449823 (view as bug list)
Depends On: 532865
Blocks: 518407
TreeView+ depends on / blocked
 
Reported: 2008-06-20 19:34 UTC by Barry Donahue
Modified: 2011-09-01 10:13 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-01 10:13:39 UTC
Target Upstream Version:


Attachments (Terms of Use)
Message file output (deleted)
2008-11-14 20:05 UTC, Bill Burns
no flags Details
xm dmesg output (deleted)
2008-11-14 20:05 UTC, Bill Burns
no flags Details

Description Barry Donahue 2008-06-20 19:34:12 UTC
Description of problem: If you create a qcow disk and then add it to the
configuration of a guest running windows-xenpv-drivers, the guest will no longer
boot.


Version-Release number of selected component (if applicable):
RHEL 5.1 Dom 0
xenpv-drivers release .97
Windows guest Windows 2003 R2 32 or 64 bit.

How reproducible: every time.


Steps to Reproduce:
1. qcow-create -r 4096 <file> 
2. Add tap:qcow entry to /etc/xen/<config> for the guest.
3. xm create <guest>
  
Actual results:
   The guest hangs at the black splash screen. xm list of the guest shows that
it is getting a lot of time. Top on Dom 0 shows that xenstored seems to be the
only thread getting a lot of time.

Expected results:
   The guest should boot.

Additional info: guest config file:

disk = [ "file:/var/lib/xen/images/w2k3.img,hda,w" ,
         "file:/var/lib/xen/images/Win2003R2-disk1.iso,hdb:cdrom,r" ,
         "tap:aio:/var/lib/xen/images/container1,xvda,w" ,
         "tap:aio:/var/lib/xen/images/container2,xvdb,w" ,
         "tap:aio:/var/lib/xen/images/container3,xvdc,w" ,
         "tap:aio:/var/lib/xen/images/container4,xvdd,w" ,
         "tap:aio:/var/lib/xen/images/container5,xvde,w" ,
         "tap:aio:/var/lib/xen/images/container6,xvdf,w" ,
         "tap:aio:/var/lib/xen/images/container7,xvdg,w" ,
         "phy:/dev/sdb4,xvdh,w" ,
         "phy:/dev/dg0/data,xvdi,w"
         "tap:qcow:/var/lib/xen/images/qcow1.img,xvdj,w" ,
         "tap:qcow:/var/lib/xen/images/qcow2.img,xvdk,w" ,
         "tap:qcow:/var/lib/xen/images/qcow3.img,xvdl,w" ]

Comment 1 Barry Donahue 2008-07-28 14:52:42 UTC
verified fixed in 0.97-1

Comment 2 Barry Donahue 2008-08-13 19:59:37 UTC
We are now testing on RHEL 5.2 Dom0 and this is now broken on 5.2 so I'm moving this back to an open bug.

Comment 3 Bill Burns 2008-11-03 15:59:30 UTC
Is this a dup? Does this still fail on the latest drivers?

Comment 4 Barry Donahue 2008-11-03 17:32:53 UTC
I just retested this on the 97.4 drivers on Windows 2003 and it failed. We hang at the beginning on the Black Windows 2003 screen. The guest is accruing cpu time at the rate of wall clock time but the guest never moves forward in the boot process.

Comment 5 Bill Burns 2008-11-14 19:55:59 UTC
*** Bug 449823 has been marked as a duplicate of this bug. ***

Comment 6 Bill Burns 2008-11-14 20:02:58 UTC
OSR reports there are tapdisk segfault messages in /var/log/messages. Can we get that output posted? Also xm dmesg may be useful.

Comment 7 Bill Burns 2008-11-14 20:04:00 UTC
Nevermind, got the output from OSR...will post it.

Comment 8 Bill Burns 2008-11-14 20:05:19 UTC
Created attachment 323637 [details]
Message file output

Comment 9 Bill Burns 2008-11-14 20:05:52 UTC
Created attachment 323638 [details]
xm dmesg output

Comment 11 ashok 2009-02-24 14:12:05 UTC
In my case it is booting but the dmesg shows 

"virbr0: port 1(tap0) entering forwarding state
tapdisk[32000]: segfault at 00002b3909f15008 rip 0000003d5c274c0b rsp 00007fffa0bb2450 error 4"

Comment 12 Bill Burns 2009-02-24 14:48:51 UTC
Is this with or without the updated package from Michal?

Comment 13 ashok 2009-02-25 14:01:48 UTC
(In reply to comment #11)
> In my case it is booting but the dmesg shows 
> 
> "virbr0: port 1(tap0) entering forwarding state
> tapdisk[32000]: segfault at 00002b3909f15008 rip 0000003d5c274c0b rsp
> 00007fffa0bb2450 error 4"

I went some where WRONG, The system actually hangs at boot time after PV driver is installed.

Comment 14 Michal Novotny 2009-03-16 13:12:59 UTC
Well, do you use my fix ? If so, could you please give me some more information about that? My fix was solving issues of qcow images but I have no MSDN licence I haven't tested it on any VM running Windows. I tried it only with Fedora and RHEL5 guests and it was working fine.

Comment 15 ashok 2009-03-18 06:36:31 UTC
Can QE Look into it?

Comment 16 Barry Donahue 2009-03-18 12:46:18 UTC
We can retest if there is some new code beyond rev 97.4.

Comment 17 Michal Novotny 2009-04-02 09:49:41 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > In my case it is booting but the dmesg shows 
> > 
> > "virbr0: port 1(tap0) entering forwarding state
> > tapdisk[32000]: segfault at 00002b3909f15008 rip 0000003d5c274c0b rsp
> > 00007fffa0bb2450 error 4"
> 
> I went some where WRONG, The system actually hangs at boot time after PV driver
> is installed.  


Well, 'tapdisk[32000]: segfault at 00002b3909f15008 rip 0000003d5c274c0b rsp 00007fffa0bb2450 error 4' looks like this was tried before applying my patch. I know there were qcow image problems of segfaults before my patch applied because of missing poll-on-aio support. Anyway I am having MSDN licence now so I can have a look at this issue.

Comment 18 Michal Novotny 2009-05-12 14:45:51 UTC
Well, no comment for a while Barry. Did you tried it again and is it still failing or how so? I have tried to virtualize WinXP guest with QCOW image mounted and I found no errors with my patch applied. Also, writing to this drive was good as well as well reading from it so if this is still an issue could you please tell me steps to reproduce it using xen-3.0.3-85.el5 rpms?

Thanks,
Michal

Comment 19 Barry Donahue 2009-05-12 17:35:39 UTC
I installed the 4 rpms and redid the test. I brought up a Windows 2003 64 bit guest and installed the 0.97.4 xenpv-win drivers. I added 6 tap:aio disks to the configuration and rebooted the system. Everything worked fine. I brought the system down and then added a tap:qcow disk to the system. The system hangs on boot. We get to the black splash screen for W2K3 and hang there. xm list shows that the guest is getting a lot of cpu time but never advances past the splash screen.

Comment 20 Michal Novotny 2009-05-13 07:55:58 UTC
Well, I don't know where can I download Windows PV drivers and I found I have none on this Windows VM. Where can I download them? Anyway this seems to be a issue of windows xen low-level drivers and this is not the development I am working on. I can grab output of logs & errors to check it but this seems to be a xen-pv low-level drivers for Windows systems and therefore I maybe not the right person to do that.

Ashok, could you please take care of that (this is assigned to you now)?

Thanks,
Michal

Comment 21 ashok 2009-05-13 09:16:21 UTC
i Just sent you a mail as the link has internal nature.

Comment 22 Michal Novotny 2009-05-13 09:46:37 UTC
Thanks, but I'd prefer binaries of those drivers. Could you send me installation disks/binaries of those drivers please, Barry?

Michal

Comment 23 Paolo Bonzini 2009-09-01 17:56:27 UTC
Assigning for triaging.

Comment 24 Paolo Bonzini 2009-09-02 16:26:35 UTC
The configuration "tap:qcow" does not work even on Linux; I can block-attach only a "tap:aio" device.

However, I can confirm that paravirtualized qcow does not work yet on Windows.  The drivers do not present the device correctly; what will show as a RHEL SCSI disk is the .qcow file instead.

Comment 25 Paolo Bonzini 2010-01-15 16:45:14 UTC
Is this broken for the boot drive, additional attached drives, or both?

Comment 26 Barry Donahue 2010-01-15 17:25:52 UTC
This particular test was on a data disk. I honestly don't remember if I tried a qcow boot disk.

Comment 29 RHEL Product and Program Management 2010-08-09 19:30:15 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 30 Lei Wang 2010-09-21 07:54:03 UTC
Test with: 
xenpv-win-1.2.0-1, 
WinXP-32 guest
add an additional tap:qcow data disk
the guest hangs at the black splash screen, not move forward.

tap:aio with raw disk works fine.

So I think this bug still exists.

There are some windows guest images under:
nfs: 10.66.90.115:/vol/ovirt3/images
If need, you can copy them from here.

Comment 31 Lei Wang 2010-09-21 08:14:39 UTC
If I boot the WinXP guest without qcow disk added, make sure the guest works properly, then attach qcow disk to it:

xm block-attach WinXP tap:qcow:/data/config-file/qcow.img xvdb w

The guest will hang there immediately with no response to mouse and keyboard anymore.

Comment 32 Yuyu Zhou 2011-05-05 07:03:22 UTC
Is this bug already fixed?

Test with:
Host: Intel 64bit 
xenpv-win-1.3.4-9.el5, xen-3.0.3-130.el5, kernel-xen-2.6.18-259.el5
Guest:
WinXP(32bit), Win2003(32bit&64bit), Win2008(32bit&64bit), Win2008r2(64bit), Win7(32bit&64bit)

In all guests listed above, the qcow image can be hot attached and detached. Boot the guests with qcow image also won't hang on the splash page.

But sometimes, the qcow image can't be seen in the "My Computer". some operations like "Import Foreign Disks", "Change Driver Letter and Paths" are needed to active the Disk. After such operations, the qcow image works fine in the guests.

Comment 34 Yuyu Zhou 2011-05-13 07:00:47 UTC
Ok, paolo. I will try to investigate more and write a summary of what operations I used in different situations. 

It may take some time. Will reply u when I finish.


Note You need to log in before you can comment on or make changes to this bug.