Hmm, block-level copy-on-write? If qcow supports this out-of-the-box, then I
technically don't need any kind of UnionFS? Just someway to specify to Xen a
read-only image with a qcow2 image in a writable zone?
Going to dredge through some EU software patent I dug up from Microsoft.
Supposed to document the /MININT switch to the NT kernel that supposedly makes
Windows write all registry changes to volatile memory instead of to the
registry hives. It's mostly used in the WinPE environment, but it looks like
BartPE leverages it too. Seems I need more to it, though, than just modifying
boot.ini to pass it, as once I started to boot Windows from a read-only drive
mount (after discovering Xen/qemu don't properly honor the mode bit in the Xen
config for r or r/w, and even file-level permissions), Windows crashed with
UNMOUNTABLE_BOOT_VOLUME as its error. But it highlights the capability is
there....just not easy.
USB is out, unfortunately, too. For security reasons, we ban USB/Firewire
drives here, with the exception of CD Burners. Ditto on memory cards (SD, MMC,
etc..). I've got very narrow operating parameters to work in, which is why
this is proving to be quite a fun challenge.
Thanks!,
--J
________________________________________
From: Fajar A. Nugraha [fajar@xxxxxxxxx]
Sent: Friday, August 14, 2009 4:53 AM
To: Joshua Kinard
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?
On Fri, Aug 14, 2009 at 1:37 AM, Joshua
Kinard<joshua.kinard@xxxxxxxxxxxxx> wrote:
> Hmm, I didn't think of it that way.
>
> The way I read up on UnionFS and aufs' functionality, was they could
> essentially merge two files virtually,
Merge two directories together, to be exact. Not merge files.
> i.e., the kernel module would be able to look at the operation coming in and
> route it to the proper descriptor (i.e., read() --> /livecd/windows/winxp.img
> OR write() --> /tmp/winxp.img, with /tmp being in tmpfs). I guess it's not
> as granular as that it seems. Would be a neat trick, but I imagine it'd be
> complex as anything for a kernel module to have to keep track of which files
> have variants loaded in the writeable union area.
What you describe is essentially block-level copy-on-write, which is
what qcow or zfs does. Aufs/unionfs does this per file.
> As for the application, it's a complex network security scanner, made by eEye
> Digital Security, called "Retina". We just don't want to setup and baby sit
> Windows installations on our Unix networks strictly for this one app, so I
> figured if I can get it to run off of a CD, we can just park some diskless
> hardware in a closet and pull it out whenever we need to do network testing
> and such.
If it were me I'd simply setup a Windows domU on any server with
enough disk and RAM, make a "template" of the "good" installation
(preferably zfs or LVM snapshot), start it only when it's needed, shut
it down afterwards, and (if necessary) rollback to the "good"
template. That is assuming that all host/network tested reachable from
my datacenter (either with vlans or routing). No need to add the
complexity of a live DVD/USB.
If portability is a requirement, and you're absolutely sure you'll
always have VT-capable host handy, then using live USB is much
perefered than DVD due to performance and complexity reasons. But hey,
that's just me :D
Let us know if you find a solution that works.
--
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home