|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steven Phillips wrote:
> I understood the original poster wanted to use his installed
> WinXP as both a VM and a native os alternately. My understanding was
> that he wanted to bounce between using the same install as a vm and as a
> "boot into" os. The problem was making any changes persistant, whether
> made in the vm or in the native "boot into".
> That would be the Enterprise Edition of WinXP that doesn't deactivate
> due to hardware changes?
> Steve
>
just to clear up some confusion/theorizing here- i've done some
experimentation on this. :)
also this thread is getting a little stale, so i want to hopefully give
a bit of a conclusion to it.
CROSS-HARDWARE COMPATIBILITY
works fine for linux guests/installs, provided you have the
modules/beefy kernel. ubuntu, fedora (or whatever they're calling the
desktop version), SuSE in its various incarnatons, and debian should all
be okay right off the bat since they do hardware recognition and try to
automagically load apropos modules (of which you get a ton pre-compiled
with the default install).
however, windows xp has a habit of sticking to a certain IDE/SATA driver
and other core-specific drivers once the second half of the install
completes. there's a way around this to allow an install to boot from
any hardware (grey legality so i won't go into details on-list, but a
summary is to say you tell the registry to accept ALL drivers instead of
just the one registered).
so if the windows install would boot at ALL on the virtual platform, you
may or may not face that hurdle (sometimes you get lucky. i think the
OEM Pro versions of XP play the most nicely with this).
DIFFERENT DISK ACCESS
the BIGGEST hurdle is the disk access. if the install and the vm are on
the same machine and there's only one disk of limited size, give up now.
however, if you have 2 or more partitions and the disk is beefy enough
(or, IDEALLY, you have two different disks, XP and FOO, FOO being the
size XP+<host OS>, that will make this easier), you're closer.
DIFFERENT DISK TYPES
there is no way, really, to mount a physical volume as a hard disk in a
hypervisor ("the thing that makes the VMs go"), even if it was a Type1
("bare-metal").you'd need a seriously hacked-up driver that bypassed the
host OS, i suppose, which (not a software engineer) i'm not even sure is
entirely possible. the hypervisor would, essentially, need to be its own
OS.the closest thing i know of is the version of VMware that installs a
hacked up customized version of RHEL, iirc. i think it's VMWare ESX but
i can't even recall the name since they have so many iterations.
WORKAROUNDS
okay. so basically, all this to say that what the OP wants is impossible.
but you can come sort of close to at least duplicating the install into
an image that MAY be able to be booted by the hypervisor.
the only way to come remotely close of what is wanted is:
use dd output piped over ssh, netcat, etc. to transfer an image of the
xp install INTO a virtual disk THROUGH the hypervisor- boot the iso of a
livecd and mount the virtual disk and dd onto that from within the
livecd (really, "liveISO"). restart the vm, reconfiguring the hypervisor
to boot that virtual disk.
there are tools to make a virtual image into a dd disk image, usually
respective to the hypervisor (i know both vmware and virtualbox at the
LEAST offer this).
aside from seamless integration, it's just simply not possible. you'd be
better off doing what brian stempin said (he's a BIG virtualization
geek; if there were a way, he'd be the first to tell you), in that you
just sync over (or mount and make available as shares via the
hypervisor) the documents you need. due to limitations of windows'
registry and so forth that he also mentioned, though, the
installation/sharing of software is also a big no-no.
you CAN modify a UUID manually in windows or otherwise, but it's a pain
in the neck and sometimes risky.
in summary, you need to find another solution for what you want to do. :)
hope this cleared some stuff up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmPSEMACgkQ8u2Zh4MtlQoTIgCgrcHyNpASUxR7hDZG8GK1e9zJ
KlEAn3hhFRRAAPhoDLxdk0qlW0h6gWtm
=4+FK
-----END PGP SIGNATURE-----
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|