[fedora-virt] Dual boot Fedora15/Win7 with VM Win7 too

[David C. Mores]

Richard W.M. Jones wrote:
> On Mon, Sep 26, 2011 at 01:39:12PM -0400, David C. Mores wrote:
>> Richard W.M. Jones wrote:
>>> In addition to this, Windows won't work on an unpartitioned disk.
>>> There's a very hacky way to do it:
>>>
>>> https://rwmj.wordpress.com/2010/09/30/technique-for-synthesizing-a-partition-table-on-a-naked-filesystem/
>> So does this mean that the ntfs partition on the physical disk looks
>> like a unpartitioned disk as presented by KVM to the guest OS?
>> How would one hook up the Windows partition to the VM?
> Yes; and using the hacky technique described above.  This is really a
> shortcoming of Windows.  Linux has no problem booting from a naked
> filesystem.
After I used the virt-manager GUI to create a VM, I find 
/var/lib/libvirt/images which I assume is where the vm image is 
installed, but now empty.  So to connect this to the physical partition, 
would I put a link in here (e.g. ln -s /dev/sda1 
/var/lib/libvirt/images/win7.img) or some such?

Also, it is not clear to me how the above partition table hack fits into 
this picture.

Sorry - this is just not intuitively obvious to me at this point.

Dave


My physical partition table:

[root at playboy ~]# parted
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: ATA ST3750528AS (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size    Type      File system  Flags
  1      1049kB  106MB  105MB   primary   ntfs         boot
  2      106MB   370GB  370GB   primary   ntfs
  4      370GB   738GB  368GB   extended
  5      370GB   371GB  524MB   logical   ext4
  6      371GB   738GB  367GB   logical                lvm
  3      738GB   750GB  12.3GB  primary   ntfs

(parted) q




>
>> Are you saying that this is what I should expect to encounter based
>> on your experiences with running the physical install as a VM?
> Yes, my experiences doing P2V.
>
>> Is KVM technology evolution headed toward making the KVM represent
>> the actual physical hardware (chipset, IO devices, etc.)?
> No, in fact the other direction.  Emulating real hardware is tedious,
> and more importantly emulated devices are much slower than
> paravirtualized devices.
>
> Rich.
>