On Tue, Aug 11, 2009 at 9:24 PM, Joshua
Kinard<joshua.kinard@xxxxxxxxxxxxx> wrote:
> 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
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1430
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.
Regards,
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home