[Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image

["Jim Burnes" <jvburnes@xxxxxxxxx>]

Anthony (and anyone else listening),

I've installed Centos 5, Xen 3.1 (from the Xensource RPMs) and installed a base Windows image to an LVM to test.

The installation wen't fairly well and I resolved various issues like getting the VMs to render to VNC displays properly.

I even used LVM snapshotting to do some quick copy-on-write tests.  In that configuration I've had up to 7 Windows VMs running at the same time, on separate IPs, writing to LVM copy-on-write snapshots.  The only problem is that LVM cow snapshots consume too much main memory.

So I proceeded to my final test which was to replace the LVM storage with QCOW storage and see how many Windows VMs I could run concurrently.  (I'm trying for 12).

The only cow tool I had was qcow-create, so I downloaded the qemu RPMs and installed them.

I used img2qcow to convert my installed Windows LVM image to the qcow base image.
I used qcow-img to create a copy-on-write snapshot of the base image.
I tried to boot with this as the new storage type by specifiying:

disk = [ 'tap:qcow:/var/lib/xen/image/winflp.img,hda1,w', 'file:/var/lib/xen/install/winflp.iso,hdc:cdrom,r']

(and other variations, by using 'hda' instead of 'hda1', using 'tap:aio' instead of 'tap:qcow')

But everytime I try to start the vm by 'xm create' it seems to create the VM and the VM immediately exits, leaving hardly any trace of even booting.  I tried booting directly to hard drive C: and I tried booting to the CDROM.  Booting to the CDROM worked fine but reported no attached hard drive.

The only thing I see is a trace in the xend.log file which indicates that xend (or the VM) is attempting to generate some sort of hotplug event for tap.  Then the whole VM shuts down.

Is there something I need to do before tap:qcow works?

I suspect, but am having a hard time proving that either:

(1) My version of Xen 3.1 doesn't support tap:qcow or
(2) My XenSource kernel doesn't contain tap support or
(3 I'm loosing my mind

Any ideas that anyone has would be greatly appreciated.

Regards,

Jim Burnes

On 6/21/07, Anthony Liguori < anthony@xxxxxxxxxxxxx> wrote:

Jim Burnes wrote:
>
> On Jun 21, 2007, at 2:39 PM, Anthony Liguori wrote:
>
>> Jim Burnes wrote:
>>>> If you start with a single image, and then create "COW" files using
>>>> the qcow format, then you can have a shared base image.
>>>>
>>>
>>> Let me make sure I understand your answer.   COW files are sparse
>>> storage for the QEMU environment (which tools you use for Xen).
>>>
>>> We want a static filesystem image that represents a snapshot of a
>>> Windows XP system right after boot.  When we activate that image we
>>> want to perform a few housekeeping issues (like set the MAC and
>>> re-DHCP etc), but we also want to make sure that any writes to the
>>> image are redirected to an overlay writable file system.  In other
>>> words we want a single shared image of the OS itself with all writes
>>> going to the COW / shadow image of that specific VM.
>>
>> COW == Copy On Write.  It's a separate file that only stores the data
>> that has been written since the cow was created.
>>
>
> Excellent.  This is exactly what we need.  I know this is tedious, but
> just to make absolutely certain (and I'll check the documentation),
> you're saying that:
>
> 1. I can create a COW file and associate it with my C: volume.

Not quite.  You can install Windows to a disk image (drive letters like
C: are individual partitions within a drive).  You then create a cow
file that uses that original disk image as a base.
> 2. All subsequent writes to C: after the COW creation go to the COW file

All subsequent writes to the drive will go to the COW file after COW
creation.

> 3. All updates stored in the COW will be read back exactly as if they
> were on the original C: volume

Yes.

> 4. After VM shutdown, we can attach to the COW image using NBD
> (network block device) for R/O access

With the appropriate tools, yes.

> 5. We can reset the shared volume back to zero by simply truncating
> the associated COW file.

Delete and create or:

rm winimg001-cow.img
qemu-img create -f qcow -b win-base.img winimg001-cow.img

That all happens very quickly.

Regards,

Anthony Liguori

> If this works, it will be great.
>
>> You really shouldn't worry about disk fragmentation but that's a
>> whole other thread :-)
>>
>
> Yeah, I'm always trying to pre-optimize everything 8-)
>
> In any case, that can be fixed by using the correct file system.
>
> Thanks, Anthony...
>
> Jim Burnes
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel