This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?

To: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?
From: Joshua Kinard <joshua.kinard@xxxxxxxxxxxxx>
Date: Tue, 18 Aug 2009 12:13:44 -0400
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Tue, 18 Aug 2009 09:23:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E9E9BAC7D3459C40BAA714735552E0E44CC4EF95E7@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <E9E9BAC7D3459C40BAA714735552E0E43A48958428@xxxxxxxxxxxxxxxxxxxxxxxx> <7207d96f0908092019p2e35d160wd4d9cd47a1ca4efe@xxxxxxxxxxxxxx> <E9E9BAC7D3459C40BAA714735552E0E43A4895842C@xxxxxxxxxxxxxxxxxxxxxxxx> <7207d96f0908111906w6c74d4cfq720d1f30b84e9e82@xxxxxxxxxxxxxx> <E9E9BAC7D3459C40BAA714735552E0E43A4EA6509E@xxxxxxxxxxxxxxxxxxxxxxxx> <7207d96f0908122249j7382f226p5b9ffa9913a457f6@xxxxxxxxxxxxxx> <E9E9BAC7D3459C40BAA714735552E0E43A4FE5DA09@xxxxxxxxxxxxxxxxxxxxxxxx>, <7207d96f0908140153k38ad8e8btd9c9244a26129150@xxxxxxxxxxxxxx>, <E9E9BAC7D3459C40BAA714735552E0E44CC4EF95E7@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcocvLWFZj+wvIyCTyqrVMix+ft5VwCg/2FIADakKKw=
Thread-topic: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?
Think I cracked it.  Don't even need to deal with qemu's qcow stuff (so far).  
Still more tests pending (including using read-only drive mounts).  But assume 
the following steps in a dom0:

- mkdir /windows
- cd /windows
- dd if=/dev/zero of=xp.img bs=1024k count=1 seek=7168
- touch xp.cfg
- nano xp.cfg
- <edit xp.cfg, setup as desired>
- xm create xp.cfg
- <install WinXP, patch, delete garbage, defrag, zero-out free space, then 
- xm list (verify domU is actually dead)

Now after this, xp.img will contain a baseline WinXP install.  In my specific 
case, I compacted everything down to ~2GB total installed (inside the domU that 
is) by using straight qemu-emulated devices (not the GPLPV stuff), no page file 
or hibernation, stripping nearly every misc utility, and a bunch of other 
stuff, but NO NTFS compression (for now, at least).


- dd if=/dev/zero of=xp_scratch.img bs=1024k count=1 seek=2048
- losetup /dev/loop0 xp.img
- losetup /dev/loop1 xp_scratch.img
- echo 0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 n 64 | 
dmsetup create xpcow

This maps our baseline WinXP image (xp.img) to /dev/loop0 and a scratch area to 
/dev/loop1 (I don't even know if this is needed just yet).  Needed because 
dmsetup only works with block devices.  Using dmsetup, a snapshot is created, 
so that all writes to loop0 get redirected to loop1, and creates a device, 

Edit xp.cfg to use phy:/dev/mapper/xpcow,hda,w, and boot Windows:
- xm create xp.cfg

In Windows, create a dummy file on the desktop or three, then shutdown.  
Re-start the domU and back at the desktop, we see that the newly-created files 
still exist, so shutdown again.  Now:

- dmsetup remove /dev/mapper/xpcow
- losetup -d /dev/loop1
- dd if=/dev/zero of=xp_scratch2.img bs=1024k count=1 seek=2048
- losetup /dev/loop1 xp_scratch2.img
- echo 0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 /dev/loop1 n 64 | 
dmsetup create xpcow
- xm create xp.cfg

Back at the desktop, the newly-created files are now gone!

I did it this way as a manual test, because I'm veryifying a few things:
a. Simulating the effect of creating the scratch image in a /tmpfs mount, while 
the baseline image will be on a physical, read-only medium.  By removing the 
mapped device and changing out the scratch file, I was seeing whether the XP 
image would indeed revert to the baseline state, to simulate a reboot in which 
/tmpfs is cleared.  Supposedly, the 'n' parameter to dmsetup does this anyways, 
but I wanted to be doubly sure.

b. Need to scriptify the whole mess, since the baseline image will already be 
pre-configured, the generation of the scratch image, setup of the loop devices, 
and the device-mapping will be on-the-fly when some future CD Image I put 
together boots up.

c. Avoids all the problems I see on Google about using blktap with qcow with 
gplpv and such.  I'm probably not grasping some of it, but I think those 
references are aiming for different uses.  So far, this setup mostly relies 
wholly on the Linux dom0 to piece everything together, leaving the WinXP domU 
utterly oblivious to what is going on.  And given Windows' nature, that's 
exactly what we want.

Performance isn't an issue for me in this, so I'm sure on a CD, this will be 
slower than running Oracle on an 8086 (pretend for a moment that this is 
actually possible), but if it works, and WinXP doesn't complain, then all is 

From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
[xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Joshua Kinard 
Sent: Monday, August 17, 2009 9:50 AM
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-users] Bootable LiveDVD w/ Xen that boots Windows Image?

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.



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.

Xen-users mailing list
Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>