[kwlug-disc] Unique VM Installation
unsolicited
unsolicited at swiz.ca
Fri Apr 8 16:45:09 EDT 2011
William Park wrote, On 04/08/2011 4:05 PM:
>
> Hmm... I just tried VirtualBox (I rarely use KVM, because mouse is so
> slow and also I don't want 2 sets of VMs), and both "network copy" and
> "shared folder" works.
>
> 1. Network copy:
>
> - set network to "Host-only". Host is already 192.168.56.1, and VM
> will be 192.168.56.101.
>
> - boot into a Linux VM, and copy the real partition to virtual
> partition over the net,
>
> nc -l -p 9999 > /dev/sda2 # from VM
>
> cat /dev/sda2 > /dev/tcp/192.168.56.101/9999 # from host
>
> Here, I think you want to use tar or something, that is, "tar"
> from host and "untar" from guest.
>
> - boot into Windows VM, and the virtual partition now has what
> Windows expects. Here, I assume harddisk format doesn't change
> from VM to VM.
>
> 2. Shared folder:
>
> - mount the real partition in host, say /mnt/hd.
>
> - set "shared folder" to /mnt/hd (the name tag will be "hd").
>
> - boot into a Linux VM, and mount it manually under /mnt/hd,
>
> mount -f vboxsf hd /mnt/hd
>
> so /mnt/hd under both host and guest shows the same content.
>
> - copy /mnt/hd directory tree to virtual partition, say /dev/sda2.
>
> - boot into Windows and the virtual partition now has what Windows
> expects.
>
> You can set the "shared folder" to "auto-mount". It shows up under
> /mnt/sf_xxx in Linux VM. I don't know where it shows up for Windows,
> and probably wouldn't work for "installation", because "shared folder"
> is normally for after Windows is up and running.
>
> As long as host's /dev/sda2 content ends up in guest's /dev/sda2, I
> think it's doable.
If I understand correctly ...
The PE wants to install windows to another partition, and the
partition on which PE is will disappear (as far as the host is
concerned) once installed. It is that installed environment that must
go P2V - so John must install somewhere, first, and it is that he must
image. To it, that will be sda1, ultimately, and probably only.
Presumably, however manipulated after the fact, blessing the (virtual)
partition used is a matter of telling the BIOS which 'disk' to boot from.
Once there is a live, viable, partition to clone, then I can see the
mechanics you talk about.
So, a liveCD clonezilla of the disk (or cloned some other way),
restored elsewhere (so he doesn't schmuck his currently installed Red
Hat install), provides a safe place to do all this manipulation. The
hardware found doesn't matter - it's all going to be revamped once
it's in its final home, anyways. (Virtual CPU, disk, video, etc.)
-----
Another way would be to bring up virtual box within the current linux
environment, and point it at the PE partition in raw disk mode.
Defining a 2nd, virtual, disk within the linux filesystem. However, if
I read John's note correctly, the PE wants to install on the same
disk, not a 2nd disk - in this case the 2nd virtual disk within the
linux filesystem above.
Or bring up that vm with 2 disks (first raw / physical), second
virtual, do as you suggest above to get the physical into the first
partition of the virtual, then reboot the virtual pointed at the new
virtual disk, and proceed to install into a second partition.
-----
Arguably, a win 7 install is a win 7 install. i.e. Using a full win 7
cd on this machine, and the same (laptop) activation key, is all legal
and proper. You're just coming from a full cd instead of the minimal
pe partition, as source.
In which case, create a win vm within the current linux install, point
it at a win 7 cd for first boot, install as usual (within the vm).
When asked for the activation key, use the one that came with the
machine. Ignore the pe partition entirely. Ignore p2v entirely too,
for that matter.
This actually may be the most sensible way - it avoids the recovery
nonsense built into the PE, and whatever additional nonsense,
including 'trial additions', it may come with, in favour of a vanilla
install - the PE will have drivers for physical stuff present, that
just doesn't apply in the virtual environment.
More information about the kwlug-disc
mailing list