Hello.

I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and would
like to be able to run the Vista OS as a virtual machine within the Linux
environment. I have installed the virtualization applications but it only
appears to be able to create a new image using the original installation
media.

How can I get the existing installation to run from within Linux?

Thanks,

Graham

Graham Vincent wrote:

> Hello.
> 
> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and would
> like to be able to run the Vista OS as a virtual machine within the Linux
> environment. I have installed the virtualization applications but it only
> appears to be able to create a new image using the original installation
> media.
> 
> How can I get the existing installation to run from within Linux?

First, that's usually a bad thing to do. The existing installation contains
software, drivers and settings suitable for the real hardware. When you run
it in the virtual machine, those software, drivers and settings suddenly
become invalid, as the virtual machine provides its own simulated hardware,
which is different from the real one. In the best-case scenario, you end up
reinstalling most of the software and drivers, and recustomize the whole
thing; this takes time and you cannot be sure you'll still be able to
restore things as they were before. In the worst-case scenario, you end up
with a system that doesn't boot under the virtual machine, but the changes
triggered by the "new" hardware have rendered the system unbootable on the
real hardware too.

Then you don't mention which virtualization platform you installed and want
to use. Without that, it's difficult to give advice. Some platforms support
using an existing "raw" partition for the virtual machine (instead of a
file), however unadvisable that might be.
If you're using VMWare, there is a tool called vmware converter that could
somewhat help (I've never used it).

Graham Vincent <graham@spamtrap.co.nz> wrote:
> Hello.
> 
> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and would
> like to be able to run the Vista OS as a virtual machine within the Linux
> environment. I have installed the virtualization applications but it only
> appears to be able to create a new image using the original installation
> media.
> 
> How can I get the existing installation to run from within Linux?
> 

You can't.

You have to do a new install. As far as the OS is concerned
your VM is just another computer- a blank one to start with.
So you need to do a fresh install of Windows within the VM
from your media.

Stan

On Friday 09 October 2009 22:49 in comp.os.linux.misc, somebody
identifying as Graham Vincent wrote...

> Hello.
> 
> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and
> would like to be able to run the Vista OS as a virtual machine within
> the Linux environment. I have installed the virtualization
> applications but it only appears to be able to create a new image
> using the original installation media.
> 
> How can I get the existing installation to run from within Linux?

If the virtual machine monitor you're using only allows for the creation
of a virtual machine via a fresh install of the guest operating system,
then the problem lies with your virtual machine monitor, of which you
are not mentioning which one it is.  VirtualBox?  VMWare?  Each of
those have different versions, and some of those versions might be
deliberately crippled.

If your machine has hardware virtualization extensions - and given that
it is a Core Duo, it should - then I would recommend solving your
problem by using the Xen hypervisor instead of whatever virtual machine
monitor you are attempting to use.

Here's how to proceed.  Boot your system up with Fedora and install the
Xen hypervisor and, if your kernel is older than 2.6.30, a Xen-patched
dom0 kernel.  Set up GRUB so that the it loads Xen with the patched
kernel (or a regular 2.6.30 kernel) as a module to it - see the GRUB
documentation - and then reboot your machine, enabling the hardware
virtualization extensions in the BIOS set-up program.

Next, look at the Xen documentation on how to boot a
hardware-virtualized guest system.  It's not that difficult, and you
don't need to create any virtual machine images.  Xen will boot Vista
as a hardware-virtualized guest, next to the Fedora 11 privileged
guest.

(Note: there is no "host" in a Xen context, because the hypervisor does
not run atop of an operating system, but underneath it.  So instead,
there is a privileged guest - i.e. the system started by Xen directly
at cold-boot time - and there are multiple unprivileged guests, which
are started by the privileged guest once that is up and running, or by
the superuser in the privileged guest.  

Xen supports both paravirtualization - which is the Xen-native
technology and which means that the unprivileged guest kernels have
been modified to work with the hypervisor and with the back-end
hardware drivers in the privileged guest, but this is unusable for
Windows, of course - or it can use hardware virtualization on hardware
that supports it, which allows for unmodified guests (such as Windows)
to run on top of Xen.  Their hardware accesses will then be trapped by
the hardware, translated into hypercalls and forwarded to the
hypervisor.

The Xen website offers three kinds of patched 2.6.18 kernels - as
sources or as RPM packages - i.e. a priviliged guest kernel (dom0), an
unprivileged guest kernel (domU) and a unified guest kernel which is
capable of running both as dom0 or as domU.  However, as of Linux
2.6.30 on, the native Linux kernel supports running as a Xen dom0,
running as a Xen domU or running on the bare metal, all without
patching the kernel.  

Linux will automatically detect whether it is running on the bare metal
or on top of Xen, and whether it is a dom0 or a domU.  It is therefore
preferred and advised - even by Xen.org - to use Linux 2.6.30 on modern
hardware instead of the patched 2.6.18 kernels, considering that the
support for lots of modern hardware will still be missing in 2.6.18.)

-- 
*Aragorn*
(registered GNU/Linux user #223157)

On Saturday 10 October 2009 00:05 in comp.os.linux.misc, somebody
identifying as pk wrote...

> Graham Vincent wrote:
> 
>> Hello.
>> 
>> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and
>> would like to be able to run the Vista OS as a virtual machine within
>> the Linux environment. I have installed the virtualization
>> applications but it only appears to be able to create a new image
>> using the original installation media.
>> 
>> How can I get the existing installation to run from within Linux?
> 
> First, that's usually a bad thing to do. The existing installation
> contains software, drivers and settings suitable for the real
> hardware. When you run it in the virtual machine, those software,
> drivers and settings suddenly become invalid, as the virtual machine
> provides its own simulated hardware, which is different from the real
> one.

Not if he were to go with my suggested solution, i.e. to use the Xen
hypervisor instead of a virtual machine monitor running inside a host
operating system.

With the hardware virtualization extensions turned on in the BIOS, the
Xen hypervisor can run an unmodified guest, and to the guest, it will
appear as if it is running on the bare metal.  All I/O and similar
other hardware accesses are trapped by the hardware's virtualization
extensions, translated into hypercalls and forwarded to the hypervisor. 
The guest doesn't even know that it is running virtualized.

He also need not re-install his Windows, because Xen allows him to use
the existing Windows installation as is.

> [...]
> 
> Then you don't mention which virtualization platform you installed and
> want to use. Without that, it's difficult to give advice. Some
> platforms support using an existing "raw" partition for the virtual
> machine (instead of a file), however unadvisable that might be.
> If you're using VMWare, there is a tool called vmware converter that
> could somewhat help (I've never used it).

It is not any more dangerous to use a partition than it is to use a
file-backed filesystem.  In either case, the filesystem is exported to
the unprivileged guest via the privileged guest.  In a Xen context,
this is done by assigning virtual block devices to the unprivileged
guests, which could in reality be files, partitions or whole disks, and
which may be presented to the unprivileged guests as being partitions
or whole disks (so that the guest's own partitioning tools can be used
to device the virtual disk into partitions or logical volumes).

-- 
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:

>> First, that's usually a bad thing to do. The existing installation
>> contains software, drivers and settings suitable for the real
>> hardware. When you run it in the virtual machine, those software,
>> drivers and settings suddenly become invalid, as the virtual machine
>> provides its own simulated hardware, which is different from the real
>> one.
> 
> Not if he were to go with my suggested solution, i.e. to use the Xen
> hypervisor instead of a virtual machine monitor running inside a host
> operating system.
> 
> With the hardware virtualization extensions turned on in the BIOS, the
> Xen hypervisor can run an unmodified guest, and to the guest, it will
> appear as if it is running on the bare metal.  All I/O and similar
> other hardware accesses are trapped by the hardware's virtualization
> extensions, translated into hypercalls and forwarded to the hypervisor.
> The guest doesn't even know that it is running virtualized.
> 
> He also need not re-install his Windows, because Xen allows him to use
> the existing Windows installation as is.

Thanks for the information. I haven't used xen full virtualization yet, but
it's good to know that it allows the guest to see unmodified hardware.
 
>> Then you don't mention which virtualization platform you installed and
>> want to use. Without that, it's difficult to give advice. Some
>> platforms support using an existing "raw" partition for the virtual
>> machine (instead of a file), however unadvisable that might be.
>> If you're using VMWare, there is a tool called vmware converter that
>> could somewhat help (I've never used it).
> 
> It is not any more dangerous to use a partition than it is to use a
> file-backed filesystem.  

Yes, of course. I was referring to using a raw partition containing a
preinstalled OS that used to run on the real hardware.

> In either case, the filesystem is exported to the unprivileged guest via
> the privileged guest.  In a Xen context, this is done by assigning virtual
> block devices to the unprivileged guests, which could in reality be files,
> partitions or whole disks, and which may be presented to the unprivileged
> guests as being partitions or whole disks (so that the guest's own
> partitioning tools can be used to device the virtual disk into partitions
> or logical volumes). 

Thanks. Again, I have used only disk images (ie files) with xen guests so
far, but it's nice that xen allows that flexibility.

pk wrote:

> Aragorn wrote:
> 
>>> First, that's usually a bad thing to do. The existing installation
>>> contains software, drivers and settings suitable for the real
>>> hardware. When you run it in the virtual machine, those software,
>>> drivers and settings suddenly become invalid, as the virtual machine
>>> provides its own simulated hardware, which is different from the real
>>> one.
>> 
>> Not if he were to go with my suggested solution, i.e. to use the Xen
>> hypervisor instead of a virtual machine monitor running inside a host
>> operating system.
>> 
>> With the hardware virtualization extensions turned on in the BIOS, the
>> Xen hypervisor can run an unmodified guest, and to the guest, it will
>> appear as if it is running on the bare metal.  All I/O and similar
>> other hardware accesses are trapped by the hardware's virtualization
>> extensions, translated into hypercalls and forwarded to the hypervisor.
>> The guest doesn't even know that it is running virtualized.
>> 
>> He also need not re-install his Windows, because Xen allows him to use
>> the existing Windows installation as is.
> 
> Thanks for the information. I haven't used xen full virtualization yet,
> but it's good to know that it allows the guest to see unmodified hardware.

Uhm on second thought...I seem to remember that xen full virtualization used
qemu for some tasks. Qemu, in turn presents the guest with a virtual,
generic hardware, different from the real one (so that would still make the
operation of running an OS originally thought for the real hardware a bit
risky). Is that still the case? Or, is my understanding correct?

Stan Bischof wrote:
> Graham Vincent <graham@spamtrap.co.nz> wrote:
>> Hello.
>>
>> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and would
>> like to be able to run the Vista OS as a virtual machine within the Linux
>> environment. I have installed the virtualization applications but it only
>> appears to be able to create a new image using the original installation
>> media.
>>
>> How can I get the existing installation to run from within Linux?
>>
> 
> You can't.
> 
> You have to do a new install. As far as the OS is concerned
> your VM is just another computer- a blank one to start with.
> So you need to do a fresh install of Windows within the VM
> from your media.
> 
> Stan

Hi Graham,

I think the best you can do is use Vista's "windows
easy transfer" wizard to save what you can.  Then
reinstall Vista in your VM and double click on the
backup file the wizard made.

Also, consider waiting a week or two to get Windows 7.
It is so, so much better done than is Vista.  I have
both in VM's on my machine.  Vista is horrible in a
VM but W7 (release candidate) is rather well behaved.

And, consider XP too.  It runs a lot faster in a VM than
does Vista or Window 7 (Vista R2).  But you can not
downgrade with Vista's "windows easy transfer" to XP.

-T

On Saturday 10 October 2009 00:26 in comp.os.linux.misc, somebody
identifying as pk wrote...

> pk wrote:
> 
>> Aragorn wrote:
>> 
>>>> First, that's usually a bad thing to do. The existing installation
>>>> contains software, drivers and settings suitable for the real
>>>> hardware. When you run it in the virtual machine, those software,
>>>> drivers and settings suddenly become invalid, as the virtual
>>>> machine provides its own simulated hardware, which is different
>>>> from the real one.
>>> 
>>> Not if he were to go with my suggested solution, i.e. to use the Xen
>>> hypervisor instead of a virtual machine monitor running inside a
>>> host operating system.
>>> 
>>> With the hardware virtualization extensions turned on in the BIOS,
>>> the Xen hypervisor can run an unmodified guest, and to the guest, it
>>> will
>>> appear as if it is running on the bare metal.  All I/O and similar
>>> other hardware accesses are trapped by the hardware's virtualization
>>> extensions, translated into hypercalls and forwarded to the
>>> hypervisor. The guest doesn't even know that it is running
>>> virtualized.
>>> 
>>> He also need not re-install his Windows, because Xen allows him to
>>> use the existing Windows installation as is.
>> 
>> Thanks for the information. I haven't used xen full virtualization
>> yet, but it's good to know that it allows the guest to see unmodified
>> hardware.
> 
> Uhm on second thought...I seem to remember that xen full
> virtualization used qemu for some tasks.

Xen does make use of some Qemu code for emulation of hardware, yes, and
of some Linux kernel code as well (for the backend drivers and NUMA
memory management), but see below. ;-)

> Qemu, in turn presents the guest with a virtual, generic hardware,
> different from the real one (so that would still make the operation of
> running an OS originally thought for the real hardware a bit risky).
> Is that still the case? 
> Or, is my understanding correct?

This is one of the things that a native Qemu does, but the Qemu code
used in Xen (and for Linux kvm and lguest) has been modified, and Xen
only uses a small part of that code, in order to emulate
certain "classic" devices such as an IDE controller and two different
types of ethernet controllers.  

However, this emulation only pertains to when paravirtualization is
used, and for the event that the paravirtualized guest wishes to use
its native drivers for communicating with an IDE controller or one of
the two supported network adapters instead of using the more
recommended front-end/back-end driver pairs.

This emulation still exists in Xen today, but it's been obsoleted for a
while already, and especially now that Xen support has been fully
integrated into vanilla Linux.  In other words, with kernel 2.6.30 (or
later) running in both dom0 and domU, you have paravirtualized support
for everything supported in a native Linux 2.6.30 (or later) kernel.

Xen was originally developed for servers and works in a way very similar
to how mainframes work, i.e. all operating systems are guests and run
atop the hypervisor, which itself runs on the bare metal but does not
contain any interactive console or other tools, so it requires a
privileged guest virtual machine to manage the other virtual machines. 
One could consider Xen to be a kind of microkernel - it was originally
said to be a nanokernel, but it already contains so much code now - of
which most comes directly from the Linux kernel[1] - that this no
longer applies.

Things like VMWare Workstation or VirtualBox however are designed for
workstations and desktop computers, with a virtual machine monitor
running as a process inside a host operating system.  This is quite a
different approach.  

VMWare Server is a different set-up, which could possibly best be
compared to native Linux with /kvm/ enabled.  It's basically a modified
Linux kernel that runs the virtual machines on top of it.  It's larger
than a hypervisor, though.

OpenVZ and zServer are yet another kind of virtualization technology. 
This is operating system level virtualization and does not support
anything other than "the host".  In this case, there is a GNU/Linux
host, but the userspace end of the operating system is virtualized so
that it can run inside isolated containers - to which the host's own
userspace has access via certain tools - with their own process space,
their own user accounts, their own filesystems and their own init
levels.  

One could consider it a much more advanced and much safer implementation
of a /chroot/ jail.  (Open)Solaris and FreeBSD already natively support
this, but Linux doesn't yet.  I would personally like seeing this code
get assimilated into vanilla Linux, but from the looks of it, Linus &
friends - especially the "friends" - seem to prefer /kvm/ and /lguest,/
which are much more like VMWare and VirtualBox, and which make use of a
modified Qemu to run the guests, although unlike VMWare and
VirtualBox, /kvm/ and /lguest/ support paravirtualization.

Still, I consider those technologies to be "ad hoc desktop
virtualization solutions".  Things like Xen and OpenVZ are far more
suitable for serious use, and the combination of both technologies -
i.e. an OpenVZ system running paravirtualized in a Xen virtual machine,
as I am planning to pull off for my pseudo-mainframe over here, is
simply state-of-the-art virtualization.  

Granted, neither paravirtualization nor OpenVZ support Windows, but then
again, who needs Windows anyway? :p  A server running Windows is only
beneficial to a sysadmin with severe masochistic tendencies. ;-)  Well,
that goes for workstations too, actually. :p


[1] NUMA node management, process schedulers, I/O schedulers, et al.

-- 
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:

>> Qemu, in turn presents the guest with a virtual, generic hardware,
>> different from the real one (so that would still make the operation of
>> running an OS originally thought for the real hardware a bit risky).
>> Is that still the case?
>> Or, is my understanding correct?
> 
> This is one of the things that a native Qemu does, but the Qemu code
> used in Xen (and for Linux kvm and lguest) has been modified, and Xen
> only uses a small part of that code, in order to emulate
> certain "classic" devices such as an IDE controller and two different
> types of ethernet controllers.
> 
> However, this emulation only pertains to when paravirtualization is
> used, and for the event that the paravirtualized guest wishes to use
> its native drivers for communicating with an IDE controller or one of
> the two supported network adapters instead of using the more
> recommended front-end/back-end driver pairs.
> 
> This emulation still exists in Xen today, but it's been obsoleted for a
> while already, and especially now that Xen support has been fully
> integrated into vanilla Linux.  In other words, with kernel 2.6.30 (or
> later) running in both dom0 and domU, you have paravirtualized support
> for everything supported in a native Linux 2.6.30 (or later) kernel.

Sorry for being dumb, but then you mean that this paragraph from wikipedia
no longer applies today:

"Xen-HVM has device emulation based on the QEMU project to provide I/O
virtualization to the virtual machines. The system emulates hardware via a
patched QEMU "device manager" (qemu-dm) daemon running as a backend in
dom0. This means that the virtualized machines see as hardware: a PIIX3 IDE
(with some rudimentary PIIX4 capabilities), Cirrus Logic or vanilla VGA
emulated video, RTL8139 or NE2000 network emulation, PAE, and somewhat
limited ACPI and APIC support and no SCSI emulation."

and the HVM guest (ie an unmodified windows OS) sees the same hardware it
would see if running on the bare metal?

On Saturday 10 October 2009 12:36 in comp.os.linux.misc, somebody
identifying as pk wrote...

> Aragorn wrote:
> 
>>> Qemu, in turn presents the guest with a virtual, generic hardware,
>>> different from the real one (so that would still make the operation
>>> of running an OS originally thought for the real hardware a bit
>>> risky). Is that still the case?
>>> Or, is my understanding correct?
>> 
>> This is one of the things that a native Qemu does, but the Qemu code
>> used in Xen (and for Linux kvm and lguest) has been modified, and Xen
>> only uses a small part of that code, in order to emulate
>> certain "classic" devices such as an IDE controller and two different
>> types of ethernet controllers.
>> 
>> However, this emulation only pertains to when paravirtualization is
>> used, and for the event that the paravirtualized guest wishes to use
>> its native drivers for communicating with an IDE controller or one of
>> the two supported network adapters instead of using the more
>> recommended front-end/back-end driver pairs.
>> 
>> This emulation still exists in Xen today, but it's been obsoleted for
>> a while already, and especially now that Xen support has been fully
>> integrated into vanilla Linux.  In other words, with kernel 2.6.30
>> (or later) running in both dom0 and domU, you have paravirtualized
>> support for everything supported in a native Linux 2.6.30 (or later)
>> kernel.
> 
> Sorry for being dumb, but then you mean that this paragraph from
> wikipedia no longer applies today:
> 
> "Xen-HVM has device emulation based on the QEMU project to provide I/O
> virtualization to the virtual machines. The system emulates hardware
> via a patched QEMU "device manager" (qemu-dm) daemon running as a
> backend in dom0. This means that the virtualized machines see as
> hardware: a PIIX3 IDE (with some rudimentary PIIX4 capabilities),
> Cirrus Logic or vanilla VGA emulated video, RTL8139 or NE2000 network
> emulation, PAE, and somewhat limited ACPI and APIC support and no SCSI
> emulation."

Ah ok, my bad.  Yes, those are used for certain device emulations, but
the main factor is that the processor is not emulated, as would be the
case on VMWare or VirtualBox with hardware virtualization extensions
switched off.

> and the HVM guest (ie an unmodified windows OS) sees the same hardware
> it would see if running on the bare metal?

Some of that hardware, yes.  Not all of it, obviously, from the snippet
above.  I must honestly admit that I haven't concerned myself with
hardware virtualization too much, as my interest (and intended use)
lies with paravirtualization.

Still, that said, it is possible to "pass through" certain PCI devices
to domU by hiding them from dom0.  Of course, if you're going to pass
through an nVidia videocard and you don't have a secondary videocard in
the system, then dom0 won't have anything to display its console on. 
Likewise for SCSI, et al.  Anything you pass through to domU must be
hidden from dom0 or else it won't work.

In addition to the above, I also think that a lot more has been made
possible with regard to SCSI support and the likes for domU since Xen
3.3.  The Wikipedia article is probably not up to date anymore - even
Xen's own Wiki isn't up to date.

-- 
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:

>> Sorry for being dumb, but then you mean that this paragraph from
>> wikipedia no longer applies today:
>> 
>> "Xen-HVM has device emulation based on the QEMU project to provide I/O
>> virtualization to the virtual machines. The system emulates hardware
>> via a patched QEMU "device manager" (qemu-dm) daemon running as a
>> backend in dom0. This means that the virtualized machines see as
>> hardware: a PIIX3 IDE (with some rudimentary PIIX4 capabilities),
>> Cirrus Logic or vanilla VGA emulated video, RTL8139 or NE2000 network
>> emulation, PAE, and somewhat limited ACPI and APIC support and no SCSI
>> emulation."
> 
> Ah ok, my bad.  Yes, those are used for certain device emulations, but
> the main factor is that the processor is not emulated, as would be the
> case on VMWare or VirtualBox with hardware virtualization extensions
> switched off.

Ah yes sure. My original answer to the OP was referring to this different
emulated hardware provided by the VM, and the problems that could arise if
an OS that was set to run on the bare hardware would suddenly be run in
this virtual environment. It would be like unplugging the HD and moving it
to another box with different hardware.
 
>> and the HVM guest (ie an unmodified windows OS) sees the same hardware
>> it would see if running on the bare metal?
> 
> Some of that hardware, yes.  Not all of it, obviously, from the snippet
> above.  I must honestly admit that I haven't concerned myself with
> hardware virtualization too much, as my interest (and intended use)
> lies with paravirtualization.

Same for me.
 
> Still, that said, it is possible to "pass through" certain PCI devices
> to domU by hiding them from dom0.  Of course, if you're going to pass
> through an nVidia videocard and you don't have a secondary videocard in
> the system, then dom0 won't have anything to display its console on.
> Likewise for SCSI, et al.  Anything you pass through to domU must be
> hidden from dom0 or else it won't work.
> 
> In addition to the above, I also think that a lot more has been made
> possible with regard to SCSI support and the likes for domU since Xen
> 3.3.  The Wikipedia article is probably not up to date anymore - even
> Xen's own Wiki isn't up to date.

Thanks for this and the previous answers, they have been very useful.

On Fri, 09 Oct 2009 23:05:48 +0100, pk wrote:

> Graham Vincent wrote:
> 
>> Hello.
>> 
>> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and
>> would like to be able to run the Vista OS as a virtual machine within
>> the Linux environment. I have installed the virtualization applications
>> but it only appears to be able to create a new image using the original
>> installation media.
>> 
>> How can I get the existing installation to run from within Linux?
> 
> First, that's usually a bad thing to do. The existing installation
> contains software, drivers and settings suitable for the real hardware.

Not for me, I've done it on two different machines using Acronis
TrueImage.

> When you run it in the virtual machine, those software, drivers and
> settings suddenly become invalid, as the virtual machine provides its
> own simulated hardware, which is different from the real one. In the

True but it has not caused any issues for me.

-- 
// This is my opinion.

jebblue wrote:
> On Fri, 09 Oct 2009 23:05:48 +0100, pk wrote:
> 
>> Graham Vincent wrote:
>>
>>> Hello.
>>>
>>> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and
>>> would like to be able to run the Vista OS as a virtual machine within
>>> the Linux environment. I have installed the virtualization applications
>>> but it only appears to be able to create a new image using the original
>>> installation media.
>>>
>>> How can I get the existing installation to run from within Linux?
>> First, that's usually a bad thing to do. The existing installation
>> contains software, drivers and settings suitable for the real hardware.
> 
> Not for me, I've done it on two different machines using Acronis
> TrueImage.
> 
>> When you run it in the virtual machine, those software, drivers and
>> settings suddenly become invalid, as the virtual machine provides its
>> own simulated hardware, which is different from the real one. In the
> 
> True but it has not caused any issues for me.
> 

Just read about the following today and so I thought I'd pass it along 
just in case it's of use:

http://www.labnol.org/software/create-virtual-machine-of-existing-computer/10510/

propman wrote:

>> True but it has not caused any issues for me.
>> 
> 
> Just read about the following today and so I thought I'd pass it along
> just in case it's of use:
> 
> http://www.labnol.org/software/create-virtual-machine-of-existing-
computer/10510/

Well, thanks to both for the valuable info.

On Sat, 10 Oct 2009 09:49:33 +1300, Graham Vincent wrote:

> Hello.
> 
> I have a Fedora 11/Vista dual boot machine (x64 Intel core duo) and
> would like to be able to run the Vista OS as a virtual machine within
> the Linux environment. I have installed the virtualization applications
> but it only appears to be able to create a new image using the original
> installation media.
> 
> How can I get the existing installation to run from within Linux?
> 
> Thanks,
> 
> Graham

VMware Converter can create a virtual machine from your Vista system. You 
will have to switch to VMware Server from KVM. The fly in the ointment is 
that F11 uses a 2.6.30 kernel and VMware Server wants a 2.6.27 or earlier 
kernel. There is a patch available that will allow VMware Server to run 
on a 2.6.30 system, just Google for VMware Server 2.7.30. VMware Player 
has recently been updated, I don't know if it supports 2.6.30. Player 
can't create VMs, all it can do is run them. If your only goal is to run 
the Vista VM you created with Converter then VMware Player should work 
also.