Re: [libvirt-users] Libvirt, virtmanager & Windows 7 installation partition

On 07/04/2013 04:21 PM, Roland Giesler wrote: While what you're seeing with a failure this early in the boot process may have something to do with disk geometry or naming, note that booting an existing Windows installation as a virtual machine is fraught with peril. This is because Windows tailors what it installs on a particular machine to the hardware of the machine at the time of the installation. A virtual machine is *not* the same as the physical machine it is running on (for example, qemu virtual machines currently all use the i440FX chipset, which hasn't been manufactured in probably 15 years or so), so if you try to boot an installation created on real (and certainly much more modern) hardware in a virtual machine, Windows will see the difference and could "freak out"; the result could be something as innocuous as automatically installing some new drivers for the "new hardware" it has found, or it could require you to re-activate your copy of Windows (whatever that entails these days - the newest Windows that I've run is WinXP :-P), or it could result in a total disaster of a failure to boot or blue screen. There is a package called "virt-p2v that can help in converting an existing Windows installation over so that it will run properly under qemu (it mounts the image from Linux and injects new/different drivers and registry changes). However, this is a permanent, one way process - once you've done this to a Windows installation, you can't go back and run it directly on hardware. (well, that's actually glossing things over a bit; I believe the way virt-p2v works is to make a *copy* of the original machine's disk, then modify that copy so the original is still there, but then you have two copies, and changes to one will not be registered in the other... you see the problem). So if you're willing to permanently use this windows installation only as a virtual machine, you should look into virt-p2v (at least to see the kind of stuff it does). If you're not willing to make a permanent switch, you may want to rethink your goals. Wait! This is another problem - you can't mount the device in the host OS *and* try to use it as a block device for a virtual guest! If you manage to be successful in booting the guest, you'll then have two independent entities modifying the same file system at the same time, which will lead to disaster in the form of a corrupt disk very quickly. If you're going to use a disk in a guest, don't mount it in the host, and if you're going to mount it in the host, don't use it in a guest. Not much (other than that NetworkManager can't seem to keep its mitts of of libvirt's tap devices :-/, but that's not related to your problem). You *might* see something useful in /var/log/libvirt/qemu/$guestname.log, but it's unlikely. Beyond that, investigating something like this usually requires looking at the guest's libvirt config ("virsh dumpxml $guestname"), although in this case I think you have much bigger problems. As mentioned above - if you're willing to give up native Windows boot forever, then look into virt-p2v or something similar. Otherwise, you'll have to dual boot, or have two separate Windows images - one for native boot and one for booting as a guest. Brilliant!! :-) This makes at least as much sense as the ones that think they're serious...