edmond rodriguez on 26 Feb 2009 07:07:31 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Xp as a VM


Although my machine was pre-installed with no CD disks issued,  I was able to make an XP install CD:

http://www.howtohaven.com/system/createwindowssetupdisk.shtml 
Creating an install CD from installed XP 

http://www.macosxhints.com/article.php?story=20080416134218704&mode=print   
How to make an XP iso bootable with mkisofs. 

I booted and ran XP from my install iso file, and it worked in qemu/kqemu, including network. 

I finally, after learning about the -snapshot option, booted from my native install XP.  Trusting the snapshot option, and later opening only read access to /dev/hda (and running from my user account), I was able to boot a native XP (first LILO, then selecting XP).  (many cautions have to be considered before doing this, as I am sure many know ... probably a risky thing to do). 

The native boot seemed to work great,  booted, came up with a login screen, logged in.   BUT activation showed up, and I decided to try activating.   That continued great until it told me it could not connect to the server and tried to fix the network automatically.  Unable to do so, It told me to "check my network settings".    

Funny, how does one "check their network settings" if they are not allowed to continue without activation?!.   Perhaps a safe mode boot or something like that.  

I guess the network setting problems is related to an "already native installed XP".  But things seemed to be adapting rather well.  



----- Original Message ----
> From: brent timothy saner <brent.saner@gmail.com>
> To: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
> Sent: Sunday, February 8, 2009 4:01:55 PM
> Subject: Re: [PLUG] Xp as a VM
> 
> -----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+, 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

___________________________________________________________________________
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