I looked at some images in /var/lib/xen/images/ and since they have partition tables and look, to me, just like disks, I copied part of my hard disk to /var/lib/xen/images/WindowsXP.img
The reason is that I want to try the Windows XP that came preinstalled, and copying /dev/sda for a length I calculated includes the entire /dev/sda1 partition seems a likely way to test it. These are the commands: dd if=/dev/sda of=/var/lib/xen/images/WindowsXP.img count=76597082 dd of=/var/lib/xen/images/WindowsXP.img seek=320072933376 bs=1 count=0
the second makes the disk image seem to be the proper size.
I tried to start it like so: qemu-kvm -boot c -snapshot -m 256 -smp 2 -std-vga \ /var/lib/xen/images/WindowsXP.img
and it choked:
[root@potoroo ~]# qemu-kvm -boot c -snapshot -m 256 -smp 2 -std-vga /var/lib/xen/images/WindowsXP.img vram_pointer=0x2aaac0b5d000 exception 0 (0) rax 0000000000000022 rbx 0000000000007000 rcx 000000000064e165 rdx 0000000000000100 rsi 00000000ffff7c05 rdi 000000000008ffea rsp 0000000000001ffe rbp 0000000000000000 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 000000000000fce2 rflags 00033206 cs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0800 (00008000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0000 (10850000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt fad00/30 idt 0/3ff cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: d5 03 e4 fc 24 44 d5 03 3e 00 d4 03 00 c0 f8 01 00 00 d5 03 --> f6 fc 24 44 d5 03 3f 00 d4 03 00 c0 f8 01 00 00 d5 03 08 fd 24 44 d5 03 40 00 d4 03 00 c0 Aborted [root@potoroo ~]#
Here is the source disk: Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xd42ad42a
Device Boot Start End Blocks Id System /dev/sda1 * 1 8669 69633711 7 HPFS/NTFS /dev/sda2 8671 9715 8393962+ 7 HPFS/NTFS /dev/sda3 9716 9728 104422+ 72 Unknown /dev/sda4 9729 38913 234428512+ 5 Extended /dev/sda5 9729 9741 104391 83 Linux /dev/sda6 9742 38913 234324058+ 8e Linux LVM [root@potoroo ~]#
Partitions 2 and up are unimportant.
fdisk on the disk image reports: Command (m for help): p
Disk /var/lib/xen/images/WindowsXP.img: 0 MB, 0 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xd42ad42a
Device Boot Start End Blocks Id System /var/lib/xen/images/WindowsXP.img1 * 1 8669 69633711 7 HPFS/NTFS /var/lib/xen/images/WindowsXP.img2 8671 9715 8393962+ 7 HPFS/NTFS /var/lib/xen/images/WindowsXP.img3 9716 9728 104422+ 72 Unknown /var/lib/xen/images/WindowsXP.img4 9729 38913 234428512+ 5 Extended
Command (m for help): q
but I had to specify the number of cylinder, 38913 but qemu-kvm rejects that nonsense.
Is there a better way to do this? I really want to test running this Windows under Linux before allowing it to use the real disk.
John Summerfield wrote:
I looked at some images in /var/lib/xen/images/ and since they have partition tables and look, to me, just like disks, I copied part of my hard disk to /var/lib/xen/images/WindowsXP.img
The reason is that I want to try the Windows XP that came preinstalled, and copying /dev/sda for a length I calculated includes the entire /dev/sda1 partition seems a likely way to test it. These are the commands: dd if=/dev/sda of=/var/lib/xen/images/WindowsXP.img count=76597082 dd of=/var/lib/xen/images/WindowsXP.img seek=320072933376 bs=1 count=0
I don't understand this second command. What's the input? Are you typing something on stdin (eg. ^D)?
Rich.
Richard W.M. Jones wrote:
John Summerfield wrote:
I looked at some images in /var/lib/xen/images/ and since they have partition tables and look, to me, just like disks, I copied part of my hard disk to /var/lib/xen/images/WindowsXP.img
The reason is that I want to try the Windows XP that came preinstalled, and copying /dev/sda for a length I calculated includes the entire /dev/sda1 partition seems a likely way to test it. These are the commands: dd if=/dev/sda of=/var/lib/xen/images/WindowsXP.img count=76597082 dd of=/var/lib/xen/images/WindowsXP.img seek=320072933376 bs=1 count=0
I don't understand this second command. What's the input? Are you typing something on stdin (eg. ^D)?
count=0 -- doesn't read anything. Its purpose is to make a 320 Gbyte file, to match the source disk in size. It becomes a sparse file, effectively with lots of zeroes between the end of data copied with the first command.
I've since edited the partition table with GNU Parted, it now looks like this: [root@potoroo ~]# parted /var/lib/xen/images/WindowsXP.img GNU Parted 1.8.6 Using /var/lib/xen/images/WindowsXP.img Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: (file) Disk /var/lib/xen/images/WindowsXP.img: 320GB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 32.3kB 71.3GB 71.3GB primary ntfs boot
(parted) q [root@potoroo ~]#
It approximates to how I've copied Windows systems around on real hardware from time to time. If I were to copy that file to a real disk and boot in real hardware, I would fully expect it to work.
how embarrassing. I needed to copy about 80 Gbytes, and only copied half that.
Worse, the boot sector has grub in it.
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
fwiw same happens when I boot directly from the partition. Ideas welcome.
John Summerfield wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
fwiw same happens when I boot directly from the partition. Ideas welcome.
Can you capture a screenshot of the BSOD? Maybe some info there.
Avi Kivity wrote:
John Summerfield wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
fwiw same happens when I boot directly from the partition. Ideas welcome.
Can you capture a screenshot of the BSOD? Maybe some info there.
This is not the same BSOD I had earlier. http://debian.merseine.nu/bsod.png
I think this is: http://debian.merseine.nu/bsod0.png
John Summerfield wrote:
Can you capture a screenshot of the BSOD? Maybe some info there.
This is not the same BSOD I had earlier. http://debian.merseine.nu/bsod.png
This one is due to the -no-acpi switch being passed to qemu, while the guest really wants ACPI. Don't pass -no-acpi, but do look at http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround.
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
Avi Kivity wrote:
John Summerfield wrote:
Can you capture a screenshot of the BSOD? Maybe some info there.
This is not the same BSOD I had earlier. http://debian.merseine.nu/bsod.png
This one is due to the -no-acpi switch being passed to qemu, while the guest really wants ACPI. Don't pass -no-acpi, but do look at http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround.
the f7 key works for that.
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
John Summerfield wrote:
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
Ah, I haven't tried very large disks. I'll check it out.
On Thu, Dec 27, 2007 at 05:39:22PM +0200, Avi Kivity wrote:
John Summerfield wrote:
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
Ah, I haven't tried very large disks. I'll check it out.
Funnily enough, a change was just commited to the Xen's copy of the QEMU ROMBIOS to support disks > 128 GB which I suspect would also apply to upstream QEMU / KVM's rombios
changeset: 16669:7fbc521b07a9 tag: tip user: Keir Fraser keir.fraser@citrix.com date: Thu Dec 27 13:00:40 2007 +0000 files: tools/firmware/rombios/rombios.c description: x86, hvm, rombios: INT13 LBA48 support for disks bigger than 128GB. The new limit should be 2TB.
Signed-off-by: Samuel Thibault samuel.thibault@citrix.com
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/7fbc521b07a9
Regards, Dan.
Daniel P. Berrange wrote:
On Thu, Dec 27, 2007 at 05:39:22PM +0200, Avi Kivity wrote:
John Summerfield wrote:
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
Ah, I haven't tried very large disks. I'll check it out.
Funnily enough, a change was just commited to the Xen's copy of the QEMU ROMBIOS to support disks > 128 GB which I suspect would also apply to upstream QEMU / KVM's rombios
changeset: 16669:7fbc521b07a9 tag: tip user: Keir Fraser keir.fraser@citrix.com date: Thu Dec 27 13:00:40 2007 +0000 files: tools/firmware/rombios/rombios.c description: x86, hvm, rombios: INT13 LBA48 support for disks bigger than 128GB. The new limit should be 2TB.
Signed-off-by: Samuel Thibault samuel.thibault@citrix.com
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/7fbc521b07a9
Regards, Dan.
Thanks, Dan, that's encouraging. When is (and is) this likely to filter through to those of us who prefer to not patch their own software?
On Fri, Dec 28, 2007 at 05:50:40AM +0900, John Summerfield wrote:
Daniel P. Berrange wrote:
On Thu, Dec 27, 2007 at 05:39:22PM +0200, Avi Kivity wrote:
John Summerfield wrote:
I think this is: http://debian.merseine.nu/bsod0.png
This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
Ah, I haven't tried very large disks. I'll check it out.
Funnily enough, a change was just commited to the Xen's copy of the QEMU ROMBIOS to support disks > 128 GB which I suspect would also apply to upstream QEMU / KVM's rombios
changeset: 16669:7fbc521b07a9 tag: tip user: Keir Fraser keir.fraser@citrix.com date: Thu Dec 27 13:00:40 2007 +0000 files: tools/firmware/rombios/rombios.c description: x86, hvm, rombios: INT13 LBA48 support for disks bigger than 128GB. The new limit should be 2TB.
Signed-off-by: Samuel Thibault samuel.thibault@citrix.com
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/7fbc521b07a9
Regards, Dan.
Thanks, Dan, that's encouraging. When is (and is) this likely to filter through to those of us who prefer to not patch their own software?
When Avi releases -59 we'll include that in rawhide. If you need the LBA-48 fix applied to other releases please file a BZ against the appropriate Fedora release and add a link to this thread in the BZ report.
Regards, Dan.
Daniel P. Berrange wrote:
On Fri, Dec 28, 2007 at 05:50:40AM +0900, John Summerfield wrote:
Daniel P. Berrange wrote:
On Thu, Dec 27, 2007 at 05:39:22PM +0200, Avi Kivity wrote:
John Summerfield wrote:
> I think this is: > http://debian.merseine.nu/bsod0.png > This is a corrupted disk, or perhaps the IDE driver is not installed correctly.
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
It's also possible that Windows is picking up garbage device geometry.
Ah, I haven't tried very large disks. I'll check it out.
Funnily enough, a change was just commited to the Xen's copy of the QEMU ROMBIOS to support disks > 128 GB which I suspect would also apply to upstream QEMU / KVM's rombios
changeset: 16669:7fbc521b07a9 tag: tip user: Keir Fraser keir.fraser@citrix.com date: Thu Dec 27 13:00:40 2007 +0000 files: tools/firmware/rombios/rombios.c description: x86, hvm, rombios: INT13 LBA48 support for disks bigger than 128GB. The new limit should be 2TB.
Signed-off-by: Samuel Thibault samuel.thibault@citrix.com
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/7fbc521b07a9
Regards, Dan.
Thanks, Dan, that's encouraging. When is (and is) this likely to filter through to those of us who prefer to not patch their own software?
When Avi releases -59 we'll include that in rawhide. If you need the LBA-48 fix applied to other releases please file a BZ against the appropriate Fedora release and add a link to this thread in the BZ report.
Where? I couldn't find a matching one at RH, though I saw some that could have been created by this problem, if the disks had been big enough, and was contemplating creating one until this happened: Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later
Regards, Dan.
Avi Kivity wrote:
the disk is fine, I can boot it natively. The hardware emulation in qemu is very old (circa Pentium Pro CPUs). It's possible (probable, do I remember LBA supports 120 Gbytes? wasn't there an earlier max of 32 Gbytes?) the disk (320 Gbytes) is larger than the emulation supports.
Ah, I haven't tried very large disks. I'll check it out.
You were right, it was missing LBA48 support. I added it for kvm-59 (by coincidence, an LBA48 patch was posted for Xen four hours ago; so I used that).
I now have Windows happily installing into a 300GB virtual disk.
On Tue, 18 Dec 2007 17:58:24 +0900 John Summerfield debian@herakles.homelinux.org wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
fwiw same happens when I boot directly from the partition. Ideas welcome.
Windows is picky about hard disk drivers. The initial installation seems to install some drivers that get loaded early for your disk hardware. QEMU emulates a different type of hardware than what you probably have and so it can't find the root disk once the kernel has booted. If you change the main disk controller on a real machine, you'll probably have the same problem.
I'm not aware of a way to fix that, unfortunately. I've generally had to install my windows images from scratch.
If you have this system set up how you want and it required a lot of configuration, one option might be to do a full backup (including system state) of the configured system, then install windows on an hvm and do a full restore, I have read that this is a good p2v (and vice versa) method for Windows, as the system state backup apparently doesn't replace drivers. I have never tried it, so I can't tell you the caveats, but depending on your situation, it might be worth a shot (I have read similar articles about moving from one piece of hardware to another). Also, in Windows, all drivers are loaded the same way, so if the right driver can be installed from the initial hardware configuration, Windows will boot in the new configuration. I have done this many times to change HD controllers in the same system for performance reasons (going to a separate IDE controller was a big performance boost on old IDE computers). I never had much luck doing that, though, unless I could put the hardware in to install the drivers for, that may mean that it won't automatically use a driver just because it is there, it has to be associated with the specific piece of hardware. Nonetheless, depending on how much time you want to spend, you might have some options. Dustin
-----Original Message----- From: fedora-xen-bounces@redhat.com [mailto:fedora-xen-bounces@redhat.com] On Behalf Of Jeff Layton Sent: Wednesday, December 19, 2007 09:55 To: John Summerfield Cc: Fedora Xen Subject: Re: [Fedora-xen] kvm crash on f8
On Tue, 18 Dec 2007 17:58:24 +0900 John Summerfield debian@herakles.homelinux.org wrote:
John Summerfield wrote:
Richard W.M. Jones wrote:
John Summerfield wrote:
The good news is that the system now boots grub sans menu. I typed in the necessary information to boot windows: chainloader (hd0,0)+1 boot
and windows boots all the way to a BSOD and the stuff on the screen recommends "chkdsk /f."
Hmm. Type to find a rescue system.
fwiw same happens when I boot directly from the partition. Ideas welcome.
Windows is picky about hard disk drivers. The initial installation seems to install some drivers that get loaded early for your disk hardware. QEMU emulates a different type of hardware than what you probably have and so it can't find the root disk once the kernel has booted. If you change the main disk controller on a real machine, you'll probably have the same problem.
I'm not aware of a way to fix that, unfortunately. I've generally had to install my windows images from scratch.
Dustin Henning wrote:
If you have this system set up how you want and it required a lot of configuration, one option might be to do a full backup (including system state) of the configured system, then install windows on an hvm and do a full restore, I have read that this is a good p2v (and vice versa) method for Windows, as the system state backup apparently doesn't replace drivers. I have never tried it, so I can't tell you the caveats, but depending on your situation, it might be worth a shot (I have read similar articles about moving from one piece of hardware to another). Also, in Windows, all drivers are loaded the same way, so if the right driver can be installed from the initial hardware configuration, Windows will boot in the new configuration. I have done this many times to change HD controllers in the same system for performance reasons (going to a separate IDE controller was a big performance boost on old IDE computers). I never had much luck doing that, though, unless I could put the hardware in to install the drivers for, that may mean that it won't automatically use a driver just because it is there, it has to be associated with the specific piece of hardware. Nonetheless, depending on how much time you want to spend, you might have some options. Dustin
<snip> and now I think it's Jeff.
Windows is picky about hard disk drivers. The initial installation seems to install some drivers that get loaded early for your disk hardware. QEMU emulates a different type of hardware than what you probably have and so it can't find the root disk once the kernel has booted. If you change the main disk controller on a real machine, you'll probably have the same problem.
I'm not aware of a way to fix that, unfortunately. I've generally had to install my windows images from scratch.
This is a trial of what I really want to do, which includes running Windows 2003 Server and a domain of Windows XP Professional clients (not many - likely 2-3 of them) for testing and education, and ideally a Windows XP system which is to be moved to different hardware anyway, but preferably without being reinstalled.
Installing drivers is okay, using xen is fine, I tried kvm because it doesn't require a special kernel.
I'm a bit dismayed to see mentions of FX chipset and piix3 in the qemu-kvm doc (I remember piix4, but piix3?). Surely that won't work for Vista.
I did try an install of my Windows on the HP dc7700p using the ISO in its recovery partition, but I quit as soon as it asked me for the other CD as evidence I'm licenced[1]. I suspect this version is locked to my BIOS and so doesn't require activation, so it's probably not going to work at all, but enquiring minds need to know.
The backup/restore procedure might work, it's supposed to preserve user data, but if it's supposed to clean out malware then it should not.
I might let it sit though, and see whether someone has another idea:-)
Merry Xmas all.
[1] Producing the CD isn't a problem, sticking it in the imaginary CD drive was, and while I think the needed ISO is right there too, I especially don't know how to shuffle virtual CDs.
On Thu, 20 Dec 2007 09:57:24 +0900 John Summerfield debian@herakles.homelinux.org wrote:
[1] Producing the CD isn't a problem, sticking it in the imaginary CD drive was, and while I think the needed ISO is right there too, I especially don't know how to shuffle virtual CDs.
Generally, what I've had to do is run qemu-kvm from the command line with "-monitor stdio". When you need to change cd's, in the qemu monitor console you do:
eject cdrom change cdrom /path/to/iso/image.iso
It would be nice if there were some way to do this from virsh or the virt-manager GUI, but I don't think there is as of yet. Maybe open a BZ for it if you're feeling daring.
When I do this, I usually disable networking since libvirt isn't setting it up anyway (-net none). Once the image is installed, you can boot it as usual via virt-manager or virsh with networking enabled.
Jeff Layton wrote:
On Thu, 20 Dec 2007 09:57:24 +0900 John Summerfield debian@herakles.homelinux.org wrote:
[1] Producing the CD isn't a problem, sticking it in the imaginary CD drive was, and while I think the needed ISO is right there too, I especially don't know how to shuffle virtual CDs.
Generally, what I've had to do is run qemu-kvm from the command line with "-monitor stdio". When you need to change cd's, in the qemu monitor console you do:
Most of my vms are xen; I decided to give kvm a fly when I decided I really don't like that I can't get framebuffer working on the xenified kernel.
If kvm works, that's probably what I'll use where I have hardware assist, I like that I don't have to choose it at boot tine.
-
Avi Kivity -
Daniel P. Berrange -
Dustin Henning -
Jeff Layton -
John Summerfield -
Richard W.M. Jones