Description of problem: I can do the first part of the install for either WinXP or Win2K using virt-manager, but on reboot I keep getting a disk error Version-Release number of selected component (if applicable): libvirt-0.7.7-3.fc14.i686 qemu-0.12.3-4.fc14.i686 virt-manager-0.8.4-1.fc14.noarch How reproducible: Always Steps to Reproduce: 1. Ensure virtd is running 2. Use either qemu or virt-manager to install WinXP or Win2K (I have 1Gb of memory set for it on a 25Gb virtual drive) 3. Allow it to run it's course and do a reset Actual results: virt-manager reports Booting from hard disk A disk read error has occurred Press CTRL-ALT-DEL to restart Expected results: The installed WinXP or Win2K runs Additional info: May be related to http://article.gmane.org/gmane.comp.emulators.qemu/66135
This procedure works for me: - create WinXP ISO image from install disk - mount the image in the host as CDROM - set boot sequence to CDROM VM will then try to boot from CDROM first. Skip "press any key to boot form CDROM" by NOT pressing any key, and it will continue to boot from the disk. Unfortunately, you will need this bootable CDROM mounted if you want to boot VM at all. Hopefully, this issue will be soon resolved.
*** Bug 599224 has been marked as a duplicate of this bug. ***
Created attachment 421267 [details] libvirtd logfile while installing windows xp I attached the requested log file for my vm. Nothing special in there, i guess... Just 2 notes: I have tried out the above procedure, my vm indeed boots, but than hangs with a blue screen. I also tried to install good old "Windows 98 SE", but this install media will not boot. This win98 vm will exit with: kvm: unhandled exit 80000021 kvm_run returned -22 I think you removed support for Win98 in this version, but maybe it will be helpfull. best regards
I'm not sure if it's a libvirt or a KVM bug, but this thread is interesting: http://www.mail-archive.com/qemu-devel@nongnu.org/msg32988.html Bruce Rogers wrote a KVM patch that fixes the problem, but I don't know if it's the right way to fix the bug...
> I've been able to determine that there is a CMOS byte which indicates to the > BIOS what IDE drives should use translation. This gets handled correctly for > the old way of specifying drives, but the same isn't done in the qdev storage > device code. This comment from the URL in the initial description strongly points to QEMU as the source of the bug. It says that the old style '-drive' options work, but the new '-drive + -device' style does not. This isn't libvirt's fault, because we're just following the recommended QEMU command line argument usage here.
Created attachment 430133 [details] Odd character in the SeaBIOS string I am running into the same or a similar problem with the current libvirt/QEMU packages from Debian 'testing' running a Windows 2003 R2 virtual machine. When booting via de CD-ROM as noted above the VM boots fine, when booting directly from disk (qcow2 image) it shows an odd character in the SeaBIOS string that isn't there when using the CD-ROM 'bypass' ... there should be a '5' instead of that odd circle thingie. Hope this helps someone with more of a clue than me :)
Created attachment 430885 [details] screenshot of error Message I see right after it copies the files and starts it downward swing to reboot and finish the initial setup.
I get the exact same problem as the reporter.
I seem to be having the same bug with a Windows 2000 guest. Install completes successfully, but then I get the "disk read error has occurred" message as described. Trying to boot from a CD, qemu died leaving this in the log: qemu: hardware error: level sensitive irq not supported CPU #0: EAX=0000007d EBX=00000000 ECX=f710ffff EDX=00010020 ESI=00000086 EDI=00000250 EBP=0000f438 ESP=0000f442 EIP=0000665b EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =0000 00000000 0000ffff 00009b0f SS =0000 00000000 0000ffff 00009300 DS =07c0 00007c00 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 000f7a30 00000037 IDT= 00000000 000003ff CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 (remaining registers all 0) I am using qemu-system-x86-0.12.3-8.fc13.x86_64. This machine is not kvm capable. Note that the above occurs whether or not the mounted ISO is bootable. An image I created previously in F11 works when I run qemu directly. Since I use -hda with qemu, the -drive/-device issue may be in play here.
> Note that the above occurs whether or not the mounted ISO is bootable. My bad, the ISO I thought wasn't bootable, is. When a non-bootable ISO is used, I just get the same error as booting straight from the HD image.
I have found this same problem. I'm installing using a slightly different situation -- I'm restoring a WinXP/Win2k3 backup that was made with fsarchiver -- but essentially I run across the same issue namely that boot fails when mbr tries to boot the first partition. In my case I use install-mbr from the mbr package but have also tried to install the windows mbr from the boot cd without success. After much trial and error and a comparison of a previously successful installations (using older version) and current, it seems that the ntfs filesystem made while booted into a kvm virt does not correctly set the offset value of the boot partition found and thus the ntfs will not load properly after the mbr hands off. For example, a single partition install of XP or Win2k3 will have a partition that begins at sector 63. To boot the NTFS file system would record this offset at 0x7E1C. In previous versions this would result in the value '3F' but in the current version it results in '00'. In this single partition example, after install using a hexeditor on the raw disk to change the value of 0x7E1C to '3F' will allow the boot to work normally. Seems like there has been a change with kvm that prevents the ntfs filesystem from being created successfully. It still seems valid for data but the BIOS parameter block of the NTFS file system is not being created successfully. My steps to reproduce were as follows: 1. make backup fsarchiver savefs win.fsa /dev/sda1 2. create disk lvcreate -L10GB -n win vg 3. partition fdisk /dev/vg/win 4. mount to loop, restore, detach kpartx -av /dev/vg/win fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1 kpartx -dv /dev/loop0 5. install mbr install-mbr /dev/vg/win at this point the system wil noot boot -- hangs after MBR. However, if you change 0x7E1C to '3F', the resulting image will boot fine: 6. after hexedit, boot, success kvm -m 1024 -hda /dev/vg/win
I have had a Windows 7 32-bit guest for many months now. I haven't tried to start it in a few weeks. Using virt-manager... I try to start it and I get the following error: - - - - - Booting from Hard Disk... Boot failed: not a bootable disk No bootable device. - - - - - I went into virt-manager's config section for the VM and made sure that only the hard disk was selected for boot. Then I removed that. Then I added it back... just in case but I still get the same error. Luckily I had a backup of the VM disk image... that is known good... because the VM has booted many times after making that backup. I restored the backup image and tried booting that (moved the suspected bad .img out of the way and put the backup in its place and then restarted libvirtd)... and I still get the same error. It appears there is something about the disk img MBR or header... that KVM isn't liking... and has decided that it isn't a bootable device. I'll attached the .xml config for the VM.
Created attachment 435349 [details] XML config for my Windows 7 VM that has a "No bootable device." error XML config for my Windows 7 VM that has a "No bootable device." error
I have isolated it a little... and come up with a bootable (although networking is broken) command line: The command line that virt-manager was issuing was: /usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 \ -name Windows7 -uuid 7fef71c2-185a-9924-0439-bd5b85decf3e -nodefaults \ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait \ -mon chardev=monitor,mode=readline -rtc base=localtime -boot c \ -drive file=/vm/Windows7Pro.img,if=none,id=drive-ide0-0-0,boot=on,format=raw \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw \ -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -device rtl8139,vlan=0,id=net0,mac=52:54:00:0e:75:2e,bus=pci.0,addr=0x4 \ -net tap,fd=40,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 \ -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus \ -device ES1370,id=sound0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 That would not boot from the command line. To get it to work I stripped off some of the -drive options as well as altered the -net options. The following command booted the machine... although like I said, networking was broken. /usr/bin/qemu-kvm -M pc-0.11 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 \ -name Windows7 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait \ -mon chardev=monitor,mode=readline \ -rtc base=localtime -boot c -drive file=/vm/Windows7Pro.img \ -device rtl8139,vlan=0,id=net0,mac=52:54:00:0e:75:2e,bus=pci.0,addr=0x4 \ -net user \ -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 \ -sdl -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x5 \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 Something about the -drive and/or the -net options that virt-manager was passing caused the the disk image to appear to be unbootable.
Just wanted to mention that my Fedora 13 x86_64 install is completely up-to-date and I have the following packages installed: libvirt-0.8.2-1.fc13.x86_64 libvirt-client-0.8.2-1.fc13.x86_64 libvirt-python-0.8.2-1.fc13.x86_64 python-virtinst-0.500.3-2.fc13.noarch python-virtkey-0.50-6.fc12.x86_64 qemu-kvm-0.12.3-8.fc13.x86_64 seabios-bin-0.5.1-3.fc13.noarch virt-manager-0.8.4-1.fc13.noarch virt-viewer-0.2.1-1.fc13.x86_64
Nevermind. nirik in the #fedora IRC channel pointed out to me the updated libvirt package details (although not included in the rpm changelog) for the recent libvirt update. Info here: https://admin.fedoraproject.org/updates/libvirt-0.8.2-1.fc13 Sure enough according to qemu-img info my Windows7.img was qcow2 format. To fix it I edited the qemu.conf to turn probing back on and edited the Windows7.xml config and changed the disk format from "raw" to "qcow2". All of those details are mentioned in the updated libvirt update info linked above.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
According to the upstream qemu bug at https://bugs.launchpad.net/bugs/586175 the debian qemu has a fix for this. Is that gonna get to fedora sometime soon? I was just trying to install XP from scratch to test something and ran into this same problem on a fully updated fedora 13 64 bit system. My impression is that the problem is the disk image itself being busted. I think I'll trying copying an old XP image I have and see if I can just overwrite it to get a new XP.
Nope, even using a copy of an existing (and working) disk image and re-installing on top of it still produces a new XP that can only boot from CD.
OK, I got it to boot by following some of the hexedit advice in the various links. It was slightly complicated by the fact that my image is a qcow2 file, so rather than try to deal with it directly, I simply added it as a 2nd disk in a linux virtual machine then ran hexedit on /dev/vdb inside that KVM. I poked around and compared various fields that were mentioned in different bugs, and the one that made the disk image bootable for me was changing 0x7E1A to 0xFF.
You should be able to use ntfsreloc to fixup the Windows boot sector without having to resort to hexediting it... http://www.linux-ntfs.org/doku.php?id=contrib:ntfsreloc Tim.
I hope this gets fixed soon. There are so many possible solutions all over the web but none of them work consistently. Same problem: Booting from Hard Disk... A disk read error occurred This is a WinXP Professional x86 VM Running: fedora 13 2.6.33.8-149.fc13.x86_64 qemu-common-0.12.5-1.fc13.x86_64 qemu-system-sh4-0.12.5-1.fc13.x86_64 qemu-system-sparc-0.12.5-1.fc13.x86_64 gpxe-roms-qemu-1.0.1-1.fc13.noarch qemu-system-arm-0.12.5-1.fc13.x86_64 qemu-system-mips-0.12.5-1.fc13.x86_64 qemu-system-x86-0.12.5-1.fc13.x86_64 qemu-kvm-0.12.5-1.fc13.x86_64 qemu-system-m68k-0.12.5-1.fc13.x86_64 qemu-user-0.12.5-1.fc13.x86_64 qemu-img-0.12.5-1.fc13.x86_64 qemu-system-cris-0.12.5-1.fc13.x86_64 qemu-system-ppc-0.12.5-1.fc13.x86_64 qemu-0.12.5-1.fc13.x86_64
Created attachment 441329 [details] Attempted backport to qemu 0.12 stable
Markus, this winxp startup bug is still present in F13 and a lot of users seem to be hitting it. I know you did the upstream fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c0897e0cb94e83ec1098867b81870e4f51f225b9 but it doesn't backport cleanly to 0.12 stable. I attempted a backport (the attached patch), but besides getting it to compile and not immediately blow up, it didn't seem to resolve the situation, understandable since I have little understanding of the affected code. Any hints for fixing this properly?
*** Bug 611065 has been marked as a duplicate of this bug. ***
I am looking at back porting the patch for F13, but this is listed as an F14 bug. F14 is using the 0.13 tree now which should not have the issue. Can anyone verify that F14 (or F13 virt-preview) works for them, and we can relabel this bug as F13?
Using F13 virt-preview I get "VNC connection to hypervisor host got refused or discinnected!" as soon as windows setup finishes formatting the partition. After reboot I get (to be expected): --- Booting from Hard Disk... Error loading operating system_ ---
I have the same exact problem trying to install Windows 2000 Pro on a 64 bit Fedora-13 system. After the first phase of the install I get a boot device failure. I also found that importing the ".img" file for a Windows XP Pro installation done on a 32 bit Fedora-11 system works. It boots up just fine on the same machine, the 64 bit Fedora-13 system, where I have the problem with installing Windows 2000 Pro from a bootable iso file. Looks like if the VM boot disk doesn't get screwed up things work.
Created attachment 445802 [details] VM file from booting Fedora-11 system This is the Windows XP pro VM xml file from a booting Fedora-11 system using 1 cpu
Created attachment 445803 [details] Booting VM xml file for Fedora-13 This is the same xmf generated from a VM ".img" imported from a booting Windows XP Pro installation, on a 32 bit Fedora-11, in to a 64 bit Fedora-13 system. The memory and number of cpu's was increased after the VM booted on the target Fedora-13 system several times without a problem.
I've attached copies of the two xml files generated by first a 32 Fedora-11 installtion of Windows XP Pro. Then the ".img" file was copied to a 64 bit Fedora-13 system an imported user virt-manager. The imported "img" VM seems to fuction just as well in Fedora-13 as it did in Fedora-11, including networking, since I can do the Windows updates through IE7 right from the Microsoft site.
Description of problem: I an having the same issue... > I can do the first part of the install for WinXP using > virt-manager, but on reboot I keep getting a disk error booting from hard disk... a disk read error ocurred press ctrl-alt-del to restart # virt-manager * Click on "create a new virtual machine" * Set "name" to WinTST * Choose "local install media..." * Set "OS Type" to "windows" and "Version" to "Microsoft Windows XP (X86)" * Select "use iso image..." ---> click "browse" ---> click "browse local" ---> select install media * Set "memory" to 512 and "cpus" to 1 * Choose "Select managed or other existing storage" ---> click "browse" * Select "foo-pool" storage pool ---> click "new volume" * Create a volume "wintst_disk0.img" format "raw" with max capacity set to 8000 mb ---> finish ---> select volume and click "choose volume" * Choose a custom private network for the vm * Virt Type is kvm * Architecture is x86_64 ---> click "finish" * The vm-guest boots, the install process starts... ...setup is copying files, bla bla bla... and then it needs to reboot to finish installing * guest reboots and it says: booting from hard disk... a disk read error ocurred press ctrl-alt-del to restart WORKAROUND: ----------- -) force power off the vm -) click "show virtual hardware deails" ---> select "boot options" -) click and select "cdrom" ---> press "up arrow" and move it to the top of the list. -) click and unselect "hard disk" ---> click "apply" -) power on the vm -) it boots from cdrom (the install media), wait for the timeout to expirte, then it boots from hard disk. -) Wait for the instalation process to finalize. The install (bootable) cd must be allways be present. -) there is no way to boot the guest from the hard disk image directly .... :-( # yum list installed '*virt*' Loaded plugins: presto, refresh-packagekit Installed Packages libvirt.x86_64 0.8.2-1.fc13 @updates libvirt-client.x86_64 0.8.2-1.fc13 @updates libvirt-python.x86_64 0.8.2-1.fc13 @updates python-virtinst.noarch 0.500.4-1.fc13 @updates virt-manager.noarch 0.8.5-1.fc13 @updates virt-viewer.x86_64 0.2.1-1.fc13 @fedora virtuoso-opensource.x86_64 6.1.2-1.fc13 @updates # yum list installed '*qemu*' Loaded plugins: presto, refresh-packagekit Installed Packages gpxe-roms-qemu.noarch 1.0.1-1.fc13 @updates qemu-common.x86_64 2:0.12.5-1.fc13 @updates qemu-img.x86_64 2:0.12.5-1.fc13 @updates qemu-kvm.x86_64 2:0.12.5-1.fc13 @updates qemu-system-x86.x86_64 2:0.12.5-1.fc13 @updates # uname -a Linux xxxxxxxxx.xxxx 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27 08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
The original patch from Markus Armbruster (http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c0897e0cb94e83ec1098867b81870e4f51f225b9) was backported to 0.12.5 in Debian. See here: http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=blob;f=debian/patches/upstream-stable02-fix-CMOS-info-for-drives-defined-with--device.diff;h=24cd5598a722fe79bdcc245f664402fd6e2e0339;hb=HEAD
*** Bug 611725 has been marked as a duplicate of this bug. ***
I have loaded Fedora 14 beta and updated all. I had all the problems listed in F13 I can now only create VM, format disk (xp install). At the end of the format the manager drops back to "Guest not Running" and that the end of it. I am running on a Dell Optiplex 620 Pentium 4 so no VT only qemu I have logged this here as it would seem F14 versions will need some testing. If any one wants me to try anything let me know Mike
qemu-0.13.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/qemu-0.13.0-1.fc14
qemu-0.13.0-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update qemu'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/qemu-0.13.0-1.fc14
Yep can now install from .iso. BUT using Virt Manager it reports Connection to Hypervisor lost or refused. Needed to do a complete restart of system but was then able to continue install
Works for me, installed windows xp pro as guest without problems using f14 as host.
In addition to comment 38 i should have said It does install and run. its just strange behaviour when XP want to reboot during the install. It drops the conection to the Virtual Manager and cant or does not re-establish it. Is this normal ?
The strange behaviour above I think can be attributed to Bug 628721 The upstream fix quoted in Bug 628721 also does not appear to fix the problem
The workaround worked on my fedora 12
qemu-0.13.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Where are the Fedora-13 updated files? I got and email from a Justin Forbes on 10/12 that read in part as ... --------------------------------------------------------------------------- It will be in the next update for F13. I mistakinely thought it had made the 0.12.5 stable release upstream, so did not apply seperately. In the meantime, there is a workaround, or you can use the F14 qemu from virt-preview. Justin ---------------------------------------------------------------------------- As far as I can tell it still hasn't made it to the updates. I've done several updates to my system including a new kernal just a few days ago, but no fix was seen for this bug yet as he mentioned. Is this bug going to be ignored so anybody that wants a fix will be forced to upgrade to Fedora-14, where I assume, or hope, its fixed?
Reopening against F13. Comment #33 links to a possible backported fix.
I tried re-test the bug, and found that it is not currently fixed in F13. And while testing this issue (due to this an other issues, i do not use libvirt on this machine) libvirt caused the most ugly kernel KraSh i have seen (i do experience xorg crashes due to other bugs in xorg/nouveau [reported] related). Once i am sure that i can reproduce it i will open a proper bugreport. Again speaking on this bugreport issue, will it be included in F13? if not, please tell so i prepare for the update to F14.
Does this work now as haven't seen reports on this lately?
I no longer update F13, now using F15 (in another partition) which works great. The last time i updated F13, i think (i need to recheck, maybe during the week) that it was fixed. The problem is that it BROKE the affected VMs, so i downgraded and stopped updating until F15 is released. I will try to update again and check.
I updated F13 and re-tested * For newly installed winxp guests (type windows/winxp, default kvm/x86_64), the issue seems fixed now. These can boot from hard disk now. * Already installed guest must keep using the 'boot via winxp cdrom' workaround, since these guests cannot boot from hard disk. The breakage i experienced the other time is now gone. libvirt.x86_64 0.8.2-6.fc13 @updates libvirt-client.x86_64 0.8.2-6.fc13 @updates libvirt-python.x86_64 0.8.2-6.fc13 @updates python-virtinst.noarch 0.500.4-2.fc13 @updates virt-manager.noarch 0.8.5-1.fc13 @updates virt-viewer.x86_64 0.2.1-1.fc13 @fedora virtuoso-opensource.x86_64 6.1.2-1.fc13 @updates
- I don't see this issues any longer on new installs. - On old installs that were broken or ones I was migrating during this period using 'ntfsreloc' as suggested above to fix the ntfs partition corrected the problem and allowed booting from disk.
I cannot downgrade :-( both python and qemu-kvm uses more that 100% cpu each one. idle xp guest uses 60% cpu. xp guest segfault qemu-kvm afer some minutes of high cpu usage, and display freezes very often. Migrating to my F15 beta is not an option due to 'similar' performance problems recently introduced there, also linux guests crashes there due to high cpu usage.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I no longer have F13 installed, moved on to F15. The last time i tried with F13, it worked. (But i got another big problem) The reason to downgrade in F13 (i ended downgrading before switching to F15) was a performance problem. Downgrading mitigated it enough to be usable.
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.