Bug 730223
it doesn't work too. Min (In reply to comment #5) > it doesn't work too. > Min What is the entire command line and the error message? Created attachment 518381 [details]
Boot-on-CMD
Please see two attachments one for error message,another for command line Are you sure that the image file path is correct in the following statement? -drive file=winxp-0811.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop,boot=on -device ide-drive,drive=drive-virtio0,id=virtio-blk-pci0 And why "ide-drive", you want to run it as virtio? Hi Vadim, As far as I know,there are two ways for installing virtio windows guest. We can install virtio windows with the following 2 methods: 1. Install guests with ide block firstly, and then boot again after attached the virtio data disk. ----it's for step 1. Then install virtio-win driver on the data disk.The virtio driver will copied to windows system disk. Finally,shut down guest and boot system disk with virtio . ------it's for step 2-3 2. Install virtio windows guest with older vfd or iso firstly, then update to the newer. The bug described the first method,it was why I booted the windows guest with "ide-drive" not "virtio" at the step 1. Any issues please let me know,thanks. Best Regards, Min Hi Min, Please let me see the following information: 1. qemu command line from step 1 (system disk - IDE, data disk - virtio) 2. screenshot, taken from Device Manager -> Storage Controllers -> Red Hat VirtIO SCSI Controller -> right click -> Properties -> Driver. 3. qemu command line from step 2 (system disk - virtio, data disk - virtio) 4. boot error message. Best regards, Vadim (In reply to comment #11) > Hi Min, > Please let me see the following information: > 1. qemu command line from step 1 (system disk - IDE, data disk - virtio) > 2. screenshot, taken from Device Manager -> Storage Controllers -> Red Hat > VirtIO SCSI Controller -> right click -> Properties -> Driver. > 3. qemu command line from step 2 (system disk - virtio, data disk - virtio) > 4. boot error message. > > Best regards, > Vadim Right. (In reply to comment #12) > (In reply to comment #11) > > Hi Min, > > Please let me see the following information: > > 1. qemu command line from step 1 (system disk - IDE, data disk - virtio) > > 2. screenshot, taken from Device Manager -> Storage Controllers -> Red Hat > > VirtIO SCSI Controller -> right click -> Properties -> Driver. > > 3. qemu command line from step 2 (system disk - virtio, data disk - virtio) > > 4. boot error message. > > > > Best regards, > > Vadim > > Right. Thank you, Min. Could you please send me all this information: 1. The initial QEMU command line when system disk is IDE and data disk is virtio. 2. Sctreenshot with the viostor driver's version information. 3. The modified (problematic) QEMU command line where both, system and data disks are virtio. 4. Screenshot with the boot error message. 5. Output from "info pci" QEMU monitor command. Best regards, Vadim. (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Hi Min, > > > Please let me see the following information: > > > 1. qemu command line from step 1 (system disk - IDE, data disk - virtio) > > > 2. screenshot, taken from Device Manager -> Storage Controllers -> Red Hat > > > VirtIO SCSI Controller -> right click -> Properties -> Driver. > > > 3. qemu command line from step 2 (system disk - virtio, data disk - virtio) > > > 4. boot error message. > > > > > > Best regards, > > > Vadim > > > > Right. > > Thank you, Min. > > Could you please send me all this information: > > 1. The initial QEMU command line when system disk is IDE and data disk is > virtio. > 2. Sctreenshot with the viostor driver's version information. See additional info > 3. The modified (problematic) QEMU command line where both, system and data > disks are virtio. /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=winxp-0811.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop -device virto-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:35 -boot c -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5966 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -drive file=disk2.raw,format=raw,if=none,id=drive-virtio2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio2,id=virtio-blk-pci2 -drive file=disk3.raw,format=raw,if=none,id=drive-virtio3,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio3,id=virtio-blk-pci3 -drive file=disk4.raw,format=raw,if=none,id=drive-virtio4,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio4,id=virtio-blk-pci4 -monitor stdio > 4. Screenshot with the boot error message. Attachment named Failure > 5. Output from "info pci" QEMU monitor command. Attachment named info pci > > Best regards, > Vadim. Created attachment 518793 [details]
Log
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > Hi Min, > > > > Please let me see the following information: > > > > 1. qemu command line from step 1 (system disk - IDE, data disk - virtio) > > > > 2. screenshot, taken from Device Manager -> Storage Controllers -> Red Hat > > > > VirtIO SCSI Controller -> right click -> Properties -> Driver. > > > > 3. qemu command line from step 2 (system disk - virtio, data disk - virtio) > > > > 4. boot error message. > > > > > > > > Best regards, > > > > Vadim > > > > > > Right. > > > > Thank you, Min. > > > > Could you please send me all this information: > > > > 1. The initial QEMU command line when system disk is IDE and data disk is > > virtio. > > 2. Sctreenshot with the viostor driver's version information. > See additional info > > 3. The modified (problematic) QEMU command line where both, system and data > > disks are virtio. > /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice > tablet > -drive > file=winxp-0811.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop Thank you, Min. You need "boot=on" here. Best regards, Vadim. > -device virto-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0 -netdev > tap,id=hostnet0,script=/etc/qemu-ifup -device > rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:35 -boot c -uuid `uuidgen` > -rtc-td-hack -no-kvm-pit-reinjection -chardev > socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon > chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice > disable-ticketing,port=5966 -vga qxl -drive > file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop > -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -drive > file=disk2.raw,format=raw,if=none,id=drive-virtio2,cache=none,werror=stop,rerror=stop > -device virtio-blk-pci,drive=drive-virtio2,id=virtio-blk-pci2 -drive > file=disk3.raw,format=raw,if=none,id=drive-virtio3,cache=none,werror=stop,rerror=stop > -device virtio-blk-pci,drive=drive-virtio3,id=virtio-blk-pci3 -drive > file=disk4.raw,format=raw,if=none,id=drive-virtio4,cache=none,werror=stop,rerror=stop > -device virtio-blk-pci,drive=drive-virtio4,id=virtio-blk-pci4 -monitor stdio > > 4. Screenshot with the boot error message. > Attachment named Failure > > 5. Output from "info pci" QEMU monitor command. > Attachment named info pci > > > > > Best regards, > > Vadim. This boot=on was already mentioned several times in this thread. Is there a problem with making it the default for (all) virtio drives? (In reply to comment #17) > This boot=on was already mentioned several times in this thread. Is there a > problem with making it the default for (all) virtio drives? 1. There is no reason in setting "boot=on" for every virtio drive, we need it for system disk only. 2. IIRC, Virtual Machine Manager does it automatically. Created attachment 519211 [details]
info-pci
(In reply to comment #17) > This boot=on was already mentioned several times in this thread. Is there a > problem with making it the default for (all) virtio drives? Hi Ronen,Vadim According to Gleb ,boot=on is not supported in RHEL6 ,we need to use bootindex to specify the boot order for multiple disks guest . Best Regards, Mike Hi Mike. Please try running VM with boot=on parameter in the command line. It shouldn't take long time, right? Best, Vadim. Hi All, Please see comments 5,I gave the answer for using 'boot=on'.Besides,I re-tried the command again but still failed.could you please double check the bug ? /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=winxp-0811.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop,boot=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:35 -boot c -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5966 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -drive file=disk2.raw,format=raw,if=none,id=drive-virtio2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio2,id=virtio-blk-pci2 -drive file=disk3.raw,format=raw,if=none,id=drive-virtio3,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio3,id=virtio-blk-pci3 -drive file=disk4.raw,format=raw,if=none,id=drive-virtio4,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio4,id=virtio-blk-pci4 -monitor stdio where is extboot.bin on your system, and do you get any error or warning message when you start qemu process? Can I get access to your host? I can reproduce this issue when running WinXP SP2(SP3) VM on top of RHEL6.2 and switching the boot (system) device from "ide" to "virtio", and the system was initially installed on ide device. I cannot reproduce this issue with exactly the same conditions, but when running VM on top of RHEL5.7 If a system was initially installed on a virtio device, the device type can be switched from virtio to ide and back from ide to virtio without any problem. Right now it seems like a pretty innocent BIOS/QEMU problem, except for the fact that it can make some problems for P2V and V2V conversion. Gleb, can you please comment on this? Best regards, Vadim. (In reply to comment #32) > I can reproduce this issue when running WinXP SP2(SP3) VM on top of RHEL6.2 and > switching the boot (system) device from "ide" to "virtio", and the system was > initially installed on ide device. > > I cannot reproduce this issue with exactly the same conditions, but when > running VM on top of RHEL5.7 > > If a system was initially installed on a virtio device, the device type can be > switched from virtio to ide and back from ide to virtio without any problem. > > Right now it seems like a pretty innocent BIOS/QEMU problem, except for the > fact that it can make some problems for P2V and V2V conversion. > > Gleb, can you please comment on this? > First of all forget about boot=on on RHEL 6.1 and greater :) The message on the screenshot is not the BIOS one. Windows prints it and this means that BIOS successfully booted something. Now to be sure what disk BIOS booted from you need to specify bootindex. So lets start with adding bootindex=1 to boot disk. If this doesn't help we will have to recompile bios with debug support and see what happens. (In reply to comment #33) > > The message on the screenshot is not the BIOS one. Windows prints it and this > means that BIOS successfully booted something. Now to be sure what disk BIOS > booted from you need to specify bootindex. So lets start with adding > bootindex=1 to boot disk. If this doesn't help we will have to recompile bios > with debug support and see what happens. Hi, Gleb, Referring to https://bugzilla.redhat.com/show_bug.cgi?id=730223#c29 senario 5 ,we tried bootindex=1 on the boot disk ald ,but it does not help , (In reply to comment #34) > (In reply to comment #33) > > > > > The message on the screenshot is not the BIOS one. Windows prints it and this > > means that BIOS successfully booted something. Now to be sure what disk BIOS > > booted from you need to specify bootindex. So lets start with adding > > bootindex=1 to boot disk. If this doesn't help we will have to recompile bios > > with debug support and see what happens. > > Hi, Gleb, > Referring to https://bugzilla.redhat.com/show_bug.cgi?id=730223#c29 senario 5 > ,we tried bootindex=1 on the boot disk ald ,but it does not help , So did I. Seems like it doesn't work when we switch from "ide" to "virtio". (In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #33) > > > > > > > > The message on the screenshot is not the BIOS one. Windows prints it and this > > > means that BIOS successfully booted something. Now to be sure what disk BIOS > > > booted from you need to specify bootindex. So lets start with adding > > > bootindex=1 to boot disk. If this doesn't help we will have to recompile bios > > > with debug support and see what happens. > > > > Hi, Gleb, > > Referring to https://bugzilla.redhat.com/show_bug.cgi?id=730223#c29 senario 5 > > ,we tried bootindex=1 on the boot disk ald ,but it does not help , > > So did I. Seems like it doesn't work when we switch from "ide" to "virtio". Lets run with debug bios then. Can you run with attached bios.bin and capture serial output? Created attachment 520966 [details]
bios with debug enabled
Created attachment 521467 [details] The bios logs for the Bug 730223. The bios logs for the Bug 730223. (In reply to comment #37) > Created attachment 520966 [details] > bios with debug enabled Reproduce this issue on the kernel-2.6.32-193.el6.x86_64 and qemu-kvm-0.12.1.2-2.184.el6.x86_64 and get the logs by serial ports. Steps to Reproduce: 1.Boot guest with the following cmd /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=xpbug730223.raw,format=raw,if=none,id=drive-virtio0,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-virtio0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:15 -boot order=c,menu=on -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5900 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -option-rom /usr/share/seabios/bios.bin -monitor stdio 2.install the virtio-win driver for the data disk http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/15/win/virtio-win-prewhql-0.1.zip 3.shut down guest and change 'ide-drive' to 'virtio-blk-pci'and add "-serial unix:/tmp/xp-sluo,server,nowait" to the qemu command line 4.do "nc -U /tmp/xp-sluo" and get the /tmp/log Actual results: The guest boot failed. Additional info: Pls refer to the attachment 521467 [details] for the bios logs. Created attachment 521472 [details]
change the disk back to ide and then take the logs
OK, so the log from comment #38 shows that bios loaded boot sector from a correct disk and pass control to it. Than Windows loaded second stage loader successfully using BIOS int13 and likely failed to communicate with the disk using native driver. (In reply to comment #41) > OK, so the log from comment #38 shows that bios loaded boot sector from a > correct disk and pass control to it. Than Windows loaded second stage loader > successfully using BIOS int13 and likely failed to communicate with the disk > using native driver. Frankly, I doubt, that it is a driver's problem. Sibiao, could you please perform a fresh installation on virtio drive and show us the relevant boot log. Also, please keep xpbug730223.raw image unchanged for awhile. Probably we will need to analyse sectors 0 and 63 on both images. Best regards, Vadim (In reply to comment #42) > (In reply to comment #41) > > OK, so the log from comment #38 shows that bios loaded boot sector from a > > correct disk and pass control to it. Than Windows loaded second stage loader > > successfully using BIOS int13 and likely failed to communicate with the disk > > using native driver. > > Frankly, I doubt, that it is a driver's problem. > Definitely possible that BIOS creates some in-memory data that Windows does not like. I just can't think of what that can be. (In reply to comment #43) > (In reply to comment #42) > > (In reply to comment #41) > > > OK, so the log from comment #38 shows that bios loaded boot sector from a > > > correct disk and pass control to it. Than Windows loaded second stage loader > > > successfully using BIOS int13 and likely failed to communicate with the disk > > > using native driver. > > > > Frankly, I doubt, that it is a driver's problem. > > > Definitely possible that BIOS creates some in-memory data that Windows does not > like. I just can't think of what that can be. Or Windows driver does not like the fact that virtio-blk is initialized by bios already when it starts running (this was not the case in rhel5), but I thought we fixed such issues long time ago. (In reply to comment #40) > Created attachment 521472 [details] > change the disk back to ide and then take the logs The log shows that there are two virtio disks and no ide disk. Are you sure this is correct log? Created attachment 521562 [details]
Use ide-drive to boot the guest and get the log.
Created attachment 521563 [details]
Use virtio-blk-pci to boot the guest and get the log.
(In reply to comment #45) > (In reply to comment #40) > > Created attachment 521472 [details] > > change the disk back to ide and then take the logs > > The log shows that there are two virtio disks and no ide disk. Are you sure > this is correct log? (In reply to comment #42) > (In reply to comment #41) > > OK, so the log from comment #38 shows that bios loaded boot sector from a > > correct disk and pass control to it. Than Windows loaded second stage loader > > successfully using BIOS int13 and likely failed to communicate with the disk > > using native driver. > > Frankly, I doubt, that it is a driver's problem. > > Sibiao, could you please perform a fresh installation on virtio drive and show > us > the relevant boot log. > Also, please keep xpbug730223.raw image unchanged for awhile. Probably we will > need to analyse sectors 0 and 63 on both images. > > Best regards, > Vadim Hi Gleb/Vadim, I have tested again and resubmitted the two logs. As you know, I have two disks,system disk and data disk. Firstly, The system disk use the ide-drive,the data disk use the virtio-pci-blk, and add "-serial unix:/tmp/xp-sluo,server,nowait" in the CLI, and then boot the guest, do the "nc -U /tmp/xp-sluo | tee /tmp/log" and get the log (attachment 521562 [details]). Secondly, The system disk change to the virtio-pci-blk,the data disk also use the virtio-pci-blk, and use the same serial ports to get the log (attachment 521563 [details]). I have cleared the log before I do the test every time. Pls check it. Best Regards. Created attachment 521595 [details]
Use ide-drive to boot the guest and get the log.
CLI:
# /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=xpbug730223.raw,format=raw,if=none,id=drive-ide0-0-0,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-ide0-0-0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:15 -boot order=c,menu=on -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5900 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -option-rom /usr/share/seabios/bios.bin -monitor stdio
Created attachment 521604 [details]
Use ide-drive to boot the guest and get the log.
The command line as follow:
# /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=xpbug730223.raw,format=raw,if=none,cache=none,werror=stop,rerror=stop -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:15 -boot order=c,menu=on -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5900 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -option-rom /usr/share/seabios/bios.bin -monitor stdio -serial unix:/tmp/xp-sluo,server,nowait
Created attachment 521614 [details]
Use ide-drive to boot the guest and get the log.
command line:
# /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=xpbug730223.raw,format=raw,if=ide,cache=none,werror=stop,rerror=stop -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:15 -boot order=c,menu=on -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5900 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -option-rom /usr/share/seabios/bios.bin -monitor stdio -serial unix:/tmp/xp-sluo,server,nowait
Created attachment 521616 [details] the log for the comment #49 (qemu) info qtree bus: main-system-bus type System dev: i440FX-pcihost, id "" bus: pci.0 type PCI dev: virtio-blk-pci, id "virtio-blk-pci1" dev-prop: class = 0x100 dev-prop: drive = drive-virtio1 dev-prop: logical_block_size = 512 dev-prop: physical_block_size = 512 dev-prop: min_io_size = 0 dev-prop: opt_io_size = 0 dev-prop: bootindex = -1 dev-prop: discard_granularity = 0 dev-prop: ioeventfd = on dev-prop: vectors = 2 dev-prop: indirect_desc = on dev-prop: event_idx = on dev-prop: scsi = on bus-prop: addr = 04.0 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = off class SCSI controller, addr 00:04.0, pci id 1af4:1001 (sub 1af4:0002) bar 0: i/o at 0xc200 [0xc23f] bar 1: mem at 0xf4040000 [0xf4040fff] dev: rtl8139, id "" dev-prop: mac = 00:11:1c:16:73:15 dev-prop: vlan = <null> dev-prop: netdev = hostnet0 dev-prop: bootindex = -1 bus-prop: addr = 03.0 bus-prop: romfile = "pxe-rtl8139.bin" bus-prop: rombar = 1 bus-prop: multifunction = off class Ethernet controller, addr 00:03.0, pci id 10ec:8139 (sub 1af4:1100) bar 0: i/o at 0xc100 [0xc1ff] bar 1: mem at 0xffffffffffffffff [0xfe] bar 6: mem at 0xffffffffffffffff [0xfffe] dev: PIIX4_PM, id "" dev-prop: smb_io_base = 45312 bus-prop: addr = 01.3 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = off class Bridge, addr 00:01.3, pci id 8086:7113 (sub 1af4:1100) dev: piix3-usb-uhci, id "" dev-prop: masterbus = <null> dev-prop: firstport = 0 bus-prop: addr = 01.2 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = off class USB controller, addr 00:01.2, pci id 8086:7020 (sub 1af4:1100) bar 4: i/o at 0xc020 [0xc03f] bus: usb.0 type USB dev: usb-tablet, id "" dev-prop: migrate = 1 bus-prop: port = <null> addr 0.1, port 1, speed 12, name QEMU USB Tablet, attached dev: piix3-ide, id "" bus-prop: addr = 01.1 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = off class IDE controller, addr 00:01.1, pci id 8086:7010 (sub 1af4:1100) bar 4: i/o at 0xc000 [0xc00f] bus: ide.1 type IDE dev: ide-drive, id "virtio-blk-pci0" dev-prop: unit = 0 dev-prop: drive = drive-ide0-0-0 dev-prop: logical_block_size = 512 dev-prop: physical_block_size = 512 dev-prop: min_io_size = 0 dev-prop: opt_io_size = 0 dev-prop: bootindex = -1 dev-prop: discard_granularity = 0 dev-prop: ver = <null> bus: ide.0 type IDE dev: qxl-vga, id "" dev-prop: ram_size = 67108864 dev-prop: vram_size = 67108864 dev-prop: revision = 3 dev-prop: debug = 0 dev-prop: guestdebug = 0 dev-prop: cmdlog = 0 bus-prop: addr = 02.0 bus-prop: romfile = "vgabios-qxl.bin" bus-prop: rombar = 1 bus-prop: multifunction = off class VGA controller, addr 00:02.0, pci id 1b36:0100 (sub 1af4:1100) bar 0: mem at 0xf0000000 [0xf3ffffff] bar 1: mem at 0xf8000000 [0xfbffffff] bar 2: mem at 0xf4000000 [0xf4001fff] bar 3: i/o at 0xc040 [0xc05f] bar 6: mem at 0xffffffffffffffff [0xfffe] dev: PIIX3, id "" bus-prop: addr = 01.0 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = on class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100) bus: isa.0 type ISA dev: isa-fdc, id "" dev-prop: driveA = floppy0 dev-prop: driveB = <null> dev-prop: bootindexA = -1 dev-prop: bootindexB = -1 isa irq 6 dev: i8042, id "" isa irqs 1,12 dev: isa-parallel, id "" dev-prop: index = 0 dev-prop: iobase = 0x378 dev-prop: irq = 7 dev-prop: chardev = parallel0 isa irq 7 dev: isa-serial, id "" dev-prop: index = 0 dev-prop: iobase = 0x3f8 dev-prop: irq = 4 dev-prop: chardev = serial0 isa irq 4 dev: mc146818rtc, id "" dev-prop: base_year = 2000 isa irq 8 dev: i440FX, id "" bus-prop: addr = 00.0 bus-prop: romfile = <null> bus-prop: rombar = 1 bus-prop: multifunction = off class Host bridge, addr 00:00.0, pci id 8086:1237 (sub 1af4:1100) (qemu) info block drive-ide0-0-0: type=hd removable=0 file=xpbug730223.raw ro=0 drv=raw encrypted=0 drive-virtio1: type=hd removable=0 file=disk1.raw ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] Created attachment 521617 [details]
change to the drive-ide0-1-0 and then take the logs
the command line:
# /usr/libexec/qemu-kvm -m 2G -smp 2 -cpu cpu64-rhel6,+x2apic -usbdevice tablet -drive file=xpbug730223.raw,format=raw,if=none,id=drive-ide0-1-0,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-ide0-1-0,id=virtio-blk-pci0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device rtl8139,netdev=hostnet0,mac=00:11:1c:16:73:15 -boot order=c,menu=on -uuid `uuidgen` -rtc-td-hack -no-kvm-pit-reinjection -chardev socket,id=111a,path=/tmp/monitor-winxp-blk-sluo,server,nowait -mon chardev=111a,mode=readline -name winxp-blk-sluo-13 -spice disable-ticketing,port=5900 -vga qxl -drive file=disk1.raw,format=raw,if=none,id=drive-virtio1,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio1,id=virtio-blk-pci1 -option-rom /usr/share/seabios/bios.bin -monitor stdio -serial unix:/tmp/xp-sluo,server,nowait
This is not a bug. The problem is that qemu-kvm relies on libvirt names for searching block devices when configuring ATA disk geometry. If id of a disk is not what qemu-kvm expects bios sees incorrect geometry. With virtio disk bios does not rely on qemu-kvm to provide geometry info, so by switching from ide to virtio we change disk geometry that bios sees.
Here is relevant comment in qemu-kvm source:
/*
* hd_table[] has only IDE drives defined with -drive if=ide, not
* the ones defined with -device. A proper fix requires quite a
* bit of surgery. This is just a quick, temporary patch to make
* things work with libvirt. It relies on the way libvirt names
* drives, namely "drive-ide0-BUS-UNIT".
*/
The fix is to use libvirt naming in testing.
I'm closing this bug, based on the Gleb's last comment. If you still think that it is a bug, feel free to open a new bug against qemu-kvm component. Best regards, Vadim. Last week I used "Virtual Machine Manager" for a real-life scenario. Fedura 14 Win7 32 Single IDE (system) disk. I added a virtio disk and used the latest prewhql drivers (1-16), to install the virtio driver. Removed the virtio disk, and changed the sys disk to virtio Reboot, and everything worked. I didn't check how comes, but "Virtual Machine Manager", might be doing it properly. (In reply to comment #56) > Last week I used "Virtual Machine Manager" for a real-life scenario. > Fedura 14 > Win7 32 > Single IDE (system) disk. > > I added a virtio disk and used the latest prewhql drivers (1-16), to install > the virtio driver. > Removed the virtio disk, and changed the sys disk to virtio > > Reboot, and everything worked. > > I didn't check how comes, but "Virtual Machine Manager", might be doing it > properly. https://bugzilla.redhat.com/show_bug.cgi?id=730223#c0 Description of problem: Guest (windows xp) boots unsuccessfully after changing from 'ide' to 'vistor' ^^^^^^^^^^ (In reply to comment #54) > This is not a bug. The problem is that qemu-kvm relies on libvirt names for > searching block devices when configuring ATA disk geometry. If id of a disk is > not what qemu-kvm expects bios sees incorrect geometry. With virtio disk bios > does not rely on qemu-kvm to provide geometry info, so by switching from ide to > virtio we change disk geometry that bios sees. > Hi, Gleb I still doubt it is a bug if hypervisior(qemu-kvm) need to rely on management layer(libvirt) . BTW,Why other guest does not hit this issue ? Mike (In reply to comment #58) > (In reply to comment #54) > > This is not a bug. The problem is that qemu-kvm relies on libvirt names for > > searching block devices when configuring ATA disk geometry. If id of a disk is > > not what qemu-kvm expects bios sees incorrect geometry. With virtio disk bios > > does not rely on qemu-kvm to provide geometry info, so by switching from ide to > > virtio we change disk geometry that bios sees. > > > > Hi, Gleb > > I still doubt it is a bug if hypervisior(qemu-kvm) need to rely on management > layer(libvirt) . > BTW,Why other guest does not hit this issue ? > There is a huge difference between NTLDR (XP & W2K) and BOOTMGR (Vista and later) > Mike (In reply to comment #58) > (In reply to comment #54) > > This is not a bug. The problem is that qemu-kvm relies on libvirt names for > > searching block devices when configuring ATA disk geometry. If id of a disk is > > not what qemu-kvm expects bios sees incorrect geometry. With virtio disk bios > > does not rely on qemu-kvm to provide geometry info, so by switching from ide to > > virtio we change disk geometry that bios sees. > > > > Hi, Gleb > > I still doubt it is a bug if hypervisior(qemu-kvm) need to rely on management > layer(libvirt) . This is documented limitation. |
Created attachment 517985 [details] Failure