Yup, read more about the qcow stuff after digging around on Google some. Even
came across some of your messages on a thread or two about it. I'll probably
give this a shot and see what happens, though I think I'm going to try
combining this with the UnionFS (aufs specifically) stuff. I've read that
might work better, since I'll be able to keep the squashfs'ed WinXP qcow2 image
on the DVD itself and not have to offload it into RAM, but somehow create a r/w
qcow2 image in tmpfs, probably ntfs format it, and allow aufs to overlay that
somehow. Although, I'm not sure in what order to do that just yet. Once I
figure it out, scripting will be the easy part.
I also heard about the OpenSolaris approach, but I admit that I've only
tinkered with OpenSolaris a little bit. I have an experiment at home unrelated
to this project which will teach me a lot, though... Also not sure how much
different the processes are for generating a Xen LiveCD from an OpenSolaris
install would be using the Xen scripts, let alone configuring the ZFS bits and
plugging it all together. I grok Linux a lot easier for now.
As far as VirtualBox goes, I've played around with the OSE edition (that's all
Debian distributes in Lenny), and the problems with it are that A) It's a bit
aged (~1.6-something in Lenny), and B) I believe I need the Guest Additions in
order for WinXP to properly utilize the network driver presented to it by the
Vbox virtual layer, and that's not free. I also lack a Windows development
environment where I could compile that on my own. I also don't know of a
method to tackle the split need of storing the core OS image on a read-only
medium and a writable overlay into tmpfs using VBox disk images...not sure if
it'd appreciate that or not.
Hence, Xen.....which so far looks like it has all the tools I need. I just
have to figure out how to jam that square peg into the round hole :)
Thanks for the tips! (PS, I'm using Outlook OWA unfortunately, hence, no
quotation blocks, per my usual method on mailing lists).
From: Fajar A. Nugraha [fajar@xxxxxxxxx]
Sent: Tuesday, August 11, 2009 10:06 PM
To: Joshua Kinard
Subject: Re: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?
On Tue, Aug 11, 2009 at 9:24 PM, Joshua
> Hi Fajar,
> Is tap:qcow2 something that has to be done when installing the Windows domU,
> or is that configured when building the LiveCD?
More of Xen config than Windows. From Windows perspective, its normal
install as usual. From Xen perspective, first you create a base image,
install everything you want on it. Then you crate a new qcow from that
base image, and then change the domU config to use it. If everything
works, you should be able to automate the process (using custom
scripts) so that (for example) the qcow image is located in RAM, and
automatically created on every boot. That way on every boot you'd have
the same state of Windows as that on base image.
> I'll google around for some information, but if you've run into any pitfalls,
> quirks, or specific configs that work, I'd be curious to read about them.
Last time I check I ran into a problem similar to this
It's probably fixed now, but to tell the truth I lost interest in qcow.
For production purposes zfs' zvol can provide much better throughput,
simpler to set up and manage, and can save even more space compared to
qcow. Of course you'll need (open)solaris (for dom0 or iscsi server)
to use zfs :D
> I can't use the USB option, as our specialized application is mostly a system
> checking/validation tool, and so has to be pretty static to make sure that as
> we check various systems, nothing changes on the scanning system. The
> systems it does scan are all on stand-alone networks, and we want to avoid
> the tool from uneccesarily modifying them (I know it won't, but I'm the
> techie -- the ones requiring this don't understand it at that level).
Actually for your purpose I'd say using USB + virtualbox is a perfect
choice. The base image can be created as a snapshot, then after every
scan you can revert to that snapshot. Function-wise, this is the same
as using qcow with the qcow image located in RAM.
> We have other methods available if this idea doesn't pan out....it'll just
> mean additional hardware and Windows installs to maintain. But if this works
> out, it'll save us some headaches. VirtualBox is also out because of PUEL
> licensing getting in the way. Ditto for VMWare and pretty much any other
> commercialized VM solution. Free is better (even if it requires some elbow
> grease to put together).
Virtualbox has a GPL version too :D You might have to build it
manually. I think opensuse has virtualbox-ose prebuilt binary.
Xen-users mailing list