[libvirt-users] Dual-boot and also use raw disk in virtual machine
I've got a new computer with two SATA disks. I installed a minimal Fedora 13 64-bit on the first disk. I shut down the computer, unplugged the first disk, booted up and installed Windows 7 on the second disk. Then I shut down, and plugged the first disk back in. I added a grub option to boot Windows from the second disk. All fine so far - I had a working dual boot system. Then in F13 using virt-manager I created a virtual machine using the second disk as a raw disk. Well, the only option I had (using virt-manager, at least) was to configure it as an IDE disk. Booting this virtual machine gets as far as "Starting Windows", and the animation appears (a dot or two), and then BSOD. Running the Windows diagnosis didn't help. I gave up. Then, keeping the same virtual machine configuration, I installed Windows 7 again into the virtual machine. I shut down the computer and booted from the second disk. Saw "Starting Windows", and the animation got a bit further, but got a BSOD again. Now running sfdisk -l /dev/sdb in the F13 host shows: Disk /dev/sdb: 121601 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdb1 * 0+ 12- 13- 102400 7 HPFS/NTFS start: (c,h,s) expected (0,32,33) found (2,0,33) end: (c,h,s) expected (12,223,19) found (205,3,19) /dev/sdb2 12+ 121601- 121589- 976657408 7 HPFS/NTFS start: (c,h,s) expected (12,223,20) found (205,3,20) end: (c,h,s) expected (1023,254,63) found (1023,15,63) /dev/sdb3 0 - 0 0 0 Empty /dev/sdb4 0 - 0 0 0 Empty So there is some obvious disagreement about the partition table. Am I going to be able to get this to work?
On 06/01/2010 01:09 PM, Richard Walker wrote: <snip>
Am I going to be able to get this to work?
Hi Richard, Reading through the steps you took, my initial thought is that it sounds like a bad idea (sorry). It sounds like you want to have Windows 7 on the 2nd hard drive, and be able to boot it from either inside a virtual machine, or natively as a dual boot. To me, the major problem that presents is the different devices windows will see with each type of boot. For example: Native boot *********** Real motherboard chip set (ie drivers for Intel, or AMD, or nVidia, or something else) Real CPU (ie Intel or AMD) Real hard drives for storage (perhaps Intel, or nVidia drivers) Real network card(s) (ie drivers for Intel, or Broadcom, or Realtek, etc) Real graphics cards (ie graphics drivers for nVidia, or ATI, or Intel, etc) <and more> Virtualised (KVM) boot ********************** Virtual motherboard chip set (software) Virtual CPU (partially a pass through of your real one) Virtual hard drive storage (KVM provided emulation layer) Virtual graphics cards (KVM provided emulation layer) <and more> I'm not going to say it's 100% impossible, but it's definitely likely going to confuse the heck out of windows, when it tries to boot up using (for example) an nVidia or Intel chipset and they're not there. Have you told windows not to automatically reboot at BSOD, so you can read what's causing the BSOD? It may specifically list the cause (ie a specific driver?) on the BSOD screen, and you may be able to work around it. Regards and best wishes, Justin Clift -- Salasaga - Open Source eLearning IDE http://www.salasaga.org
On 1 June 2010 16:14, Justin Clift <justin@salasaga.org> wrote:
On 06/01/2010 01:09 PM, Richard Walker wrote: <snip>
Am I going to be able to get this to work?
Hi Richard,
Reading through the steps you took, my initial thought is that it sounds like a bad idea (sorry).
It sounds like you want to have Windows 7 on the 2nd hard drive, and be able to boot it from either inside a virtual machine, or natively as a dual boot.
Exactly.
To me, the major problem that presents is the different devices windows will see with each type of boot.
It wasn't a completely random idea to try this -- I had found some evidence of people getting this to work successfully (albeit with XP): http://un.codiert.org/2008/09/booting-windows-xp-from-raw-disk-with-linux-kv... (I did wonder whether the deletion of the Hardware Profiles function from Windows 7 would have any effect.)
Have you told windows not to automatically reboot at BSOD, so you can read what's causing the BSOD? It may specifically list the cause (ie a specific driver?) on the BSOD screen, and you may be able to work around it.
I have now . . . good tip. It seems I get one of the standard messages: *** STOP: 0x0000007B (0xFFFFF880009A9928, ...) which appears to indicate an inability to "find" the disk. I will take a note of the drivers that are currently installed, then do another fresh "native" install and try to add the extra drivers manually. Is there any significance to the apparently "broken" partition table entries? Probably yes . . . I will do some more investigation of that too.
On 2 June 2010 13:18, Richard Walker <walkerrichardj@gmail.com> wrote:
I will take a note of the drivers that are currently installed, then do another fresh "native" install and try to add the extra drivers manually.
I went through Device Manager and made a note of all the filenames of all the drivers. Then I did the fresh "native" install. It turned out that that installed all the filenames I'd written down (plus many others). But rebooting into F13 and starting Win 7 as a virtual machine gave the same symptoms as before. :-(
Is there any significance to the apparently "broken" partition table entries? Probably yes . . . I will do some more investigation of that too.
It seems that even though sfdisk says there is strangeness, the partition table still "works".
On 06/03/2010 01:04 PM, Richard Walker wrote: <snip>
Is there any significance to the apparently "broken" partition table entries? Probably yes . . . I will do some more investigation of that too.
It seems that even though sfdisk says there is strangeness, the partition table still "works".
Hmmm... as a thought, is it possible to wipe the drive and set up the partitions the way you want them from F13, prior to install Windows 7? Then tell Windows 7 to use those existing partitions instead of it doing the setup? I have absolutely no idea if this will work, mind you. Might be easier to try first with FAT32 partitions as well (unsure). I'm more in "thinking of possible options" mode, than knowing what to try next for sure with this. :) Regards and best wishes, Justin Clift -- Salasaga - Open Source eLearning IDE http://www.salasaga.org
On 2 June 2010 13:18, Richard Walker <walkerrichardj@gmail.com> wrote:
Have you told windows not to automatically reboot at BSOD, so you can read what's causing the BSOD? It may specifically list the cause (ie a specific driver?) on the BSOD screen, and you may be able to work around it.
I have now . . . good tip. It seems I get one of the standard messages: *** STOP: 0x0000007B (0xFFFFF880009A9928, ...) which appears to indicate an inability to "find" the disk.
I will take a note of the drivers that are currently installed, then do another fresh "native" install and try to add the extra drivers manually.
Is there any significance to the apparently "broken" partition table entries? Probably yes . . . I will do some more investigation of that too.
Many days later, many hours spent . . . And at last . . . success! There are hints floating about on the web; it was just a matter of finding the right one. I made a fresh install into a VM so I could compare registry keys. In: HKLM\SYSTEM\CurrentControlSet\services there are some differences between the native install and the VM install. In the native install, intelide's Start setting is 3, and pciide's Start setting is 0. In the fresh install into a VM, those settings are reversed. So in the native install I set intelide's Start setting to 0 (i.e., to enable it). I didn't touch pciide's Start setting. Reboot natively - still boots (a relief!). And then it also booted as a VM! After logging in, the drivers for the virtual devices (except audio) were installed OK. I can now switch between booting natively and booting as a VM. There's now no sign of driver installation when switching. So far so good . . .
On 06/07/2010 02:39 PM, Richard Walker wrote: <snip>
And at last . . . success!
Interesting. Hope you've taken a backup (image the hdd or something). :) I wonder if it's possible to use a dedicated hdd as a snapshot backing store, with the copy on write difference file being else where. ie. /some/location/snapshot1.qcow2 That would let you use a VM with "/some/location/snapshot1.qcow2" as it's hard drive, and wouldn't then make any changes to your actual (working) dedicated windows hdd. Lets you try things in a vm easily without ruining the primary image. Disk i/o performance in the vm could be less than great though. :/ Regards and best wishes, Justin Clift -- Salasaga - Open Source eLearning IDE http://www.salasaga.org
On 7 June 2010 14:59, Justin Clift <justin@salasaga.org> wrote:
On 06/07/2010 02:39 PM, Richard Walker wrote: <snip>
And at last . . . success!
Interesting. Hope you've taken a backup (image the hdd or something). :)
Uh, yes, well, maybe I will get around to that. The next problem to face is activation. Having activated the native install, now I have three days to activate in the VM, and that doesn't work. Too many hardware "changes" I suppose . . .
On 06/07/2010 04:22 PM, Richard Walker wrote:
On 7 June 2010 14:59, Justin Clift<justin@salasaga.org> wrote:
On 06/07/2010 02:39 PM, Richard Walker wrote: <snip>
And at last . . . success!
Interesting. Hope you've taken a backup (image the hdd or something). :)
Uh, yes, well, maybe I will get around to that.
The next problem to face is activation. Having activated the native install, now I have three days to activate in the VM, and that doesn't work. Too many hardware "changes" I suppose . . .
Btw, the snapshot approach mentioned works. It's very easy. For a 500GB physical disk, with an OS installed on it: # qemu-img create -f qcow2 -o backing_file=/dev/sdb,backing_fmt=host_device /home/images/sdbimagesnap2.qcow2 500G That creates the snapshot. Then change a guest XML file to point to the snapshot. From: <disk type='block' device='disk'> <driver name='qemu'/> <-- no "type" here <source dev='/dev/sdb'/> <-- physical device here <target dev='hda' bus='ide'/> </disk> To: <disk type='block' device='disk'> <driver name='qemu' type='qcow2'/> <-- qcow2 type here <source dev='/home/images/sdbimagesnap2.qcow2'/> <--snapshot file <target dev='hda' bus='ide'/> </disk> And the guest then uses the snapshot file, making writes only to that and leaving the physical device alone. It probably would have been a good way to experiment with your dual boot solution, without invalidating the license keys when physically booting Windows. Though, booting windows for real would likely silently corrupt the vm snapshots. :/ Good luck with your pursuit though. Hope you figure the license activation thing out. :) Regards and best wishes, Justin Clift -- Salasaga - Open Source eLearning IDE http://www.salasaga.org
participants (2)
-
Justin Clift -
Richard Walker