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" ]
verified fixed in 0.97-1
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.
Is this a dup? Does this still fail on the latest drivers?
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.
*** Bug 449823 has been marked as a duplicate of this bug. ***
OSR reports there are tapdisk segfault messages in /var/log/messages. Can we get that output posted? Also xm dmesg may be useful.
Nevermind, got the output from OSR...will post it.
Created attachment 323637 [details] Message file output
Created attachment 323638 [details] xm dmesg output
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"
Is this with or without the updated package from Michal?
(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, 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.
Can QE Look into it?
We can retest if there is some new code beyond rev 97.4.
(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.
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
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.
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
i Just sent you a mail as the link has internal nature.
Thanks, but I'd prefer binaries of those drivers. Could you send me installation disks/binaries of those drivers please, Barry? Michal
Assigning for triaging.
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.
Is this broken for the boot drive, additional attached drives, or both?
This particular test was on a data disk. I honestly don't remember if I tried a qcow boot disk.
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.
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.
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.
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.
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.