Xen users - Apr 2009 - Windows XP HVM on qcow diskfile and snapshots

Dom0: CentOS 5.2 i386, with gitco Xen 3.3.1 i386.

I have successfully managed to setup a Windows XP HVM guest domain, starting 
from a qcow disk image I was using with plain qemu so far. Even without GPLV 
drivers, there''s already a noticeable speed increase. Yay!

As a next step, for several reasons I would like to have my base disk image 
immutable.

I have tried two different approaches, but both failed:
* Enable the ''snapshot=1'' configuration parameter in my hvm
config file. This
doesn''t seem to have any effect on my system (or maybe I misunderstand
the
option). All modifications to the disk image (like creating a new directory) 
are preserved after a complete shutdown of the guest and the recreating it.

* Created a copy-on-write disk image, based on my original image with
qemu-img create -b <original image> -fmt qcow <new image>
and changed the blockdevice line in my config file to
disk = [ ''tap:qcow:<new image>,hda,w'',
'',hdc:cdrom,r'' ]

However, this configuration won''t boot. To be exact, the guest aborts
very
shortly after the bios hard drive discovery. So I presume the copy-on-write 
disk image is somehow not working.

Any hints on what goes wrong here ?

Some more info on my system:
xm info
host                   : aragorn.vialila.lan
release                : 2.6.18-92.1.22.el5.centos.plusxen
version                : #1 SMP Wed Dec 17 12:11:57 EST 2008
machine                : i686
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2211
hw_caps                : 
178bfbff:ebd3fbff:00000000:00000010:00002001:00000000:0000001f:00000000
virt_caps              : hvm
total_memory           : 8191
free_memory            : 1026
node_to_cpu            : node0:0-3
node_to_memory         : node0:1026
xen_major              : 3
xen_minor              : 3
xen_extra              : .1
xen_caps               : xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xf5800000
xen_changeset          : unavailable
cc_compiler            : gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
cc_compile_by          : root
cc_compile_domain      : gitco.tld
cc_compile_date        : Tue Jan 20 23:35:28 CET 2009
xend_config_format     : 4

Below is my current hvm config file:
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
    arch_libdir = ''lib64''
else:
    arch_libdir = ''lib''
/var/lib/xen/images/WinXPViaLila.qcow'')
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 512
name = "WinXPViaLila"
acpi=0
vif = [ ''type=ioemu, mac=00:16:3e:4a:33:c6, bridge=xenbr0'' ]
disk = [
''tap:qcow:/var/lib/xen/images/WinXP-noacpi.qcow,hda,w'',
'',hdc:cdrom,r'' ]
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
snapshot=1
sdl=1
opengl=1
vnc=0
vnclisten="0.0.0.0"
vncdisplay=100
vncpasswd=''''
serial=''pty''
monitor=1
soundhw=''sb16''
usb=1
usbdevice=''tablet''

-- 
Kobalt W.I.T.
Web & Information Technology
Brusselsesteenweg 152
1850 Grimbergen

Tel  : +32 479 339 655
Email: info@kobaltwit.be


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

On Sat, Apr 11, 2009 at 9:10 PM, Geert Janssens <info@kobaltwit.be>
wrote:
> Dom0: CentOS 5.2 i386, with gitco Xen 3.3.1 i386.
>
> I have successfully managed to setup a Windows XP HVM guest domain,
starting
> from a qcow disk image I was using with plain qemu so far. Even without
GPLV
> drivers, there''s already a noticeable speed increase. Yay!
>
Last time I check, tap:qcow does not work when using Windows with
GPLPV or HVM Linux with PV drivers.

The only other alternative that I know of, with acceptable performance
and space allocation flexibility, is to bring in Opensolaris with zfs
volume, either as dom0 or as iscsi server.

Regards,

Fajar

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

On Sat, 11 Apr 2009 16:10:21 +0200
Geert Janssens <info@kobaltwit.be> wrote:
> * Created a copy-on-write disk image, based on my original image with
> qemu-img create -b <original image> -fmt qcow <new image>
> and changed the blockdevice line in my config file to
> disk = [ ''tap:qcow:<new image>,hda,w'',
'',hdc:cdrom,r'' ]
> 
> However, this configuration won''t boot. To be exact, the guest
aborts
> very shortly after the bios hard drive discovery. So I presume the
> copy-on-write disk image is somehow not working.
> 
> Any hints on what goes wrong here ?
I have the same problem with a freshly created qcow2 image using the
qemu-img-xen tool.  The original qcow2 image works perfectly with
tap:qcow2, but attempting to use it as a base for a new image halts the
boot immediately.  The xend.log file don''t show any errors, it only
points me to the VM-specific log, which just stops dead.

Perhaps this functionality isn''t supported?

Brian Conway

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

On Saturday 11 April 2009, Fajar A. Nugraha wrote:
> On Sat, Apr 11, 2009 at 9:10 PM, Geert Janssens <info@kobaltwit.be>
wrote:
> > Dom0: CentOS 5.2 i386, with gitco Xen 3.3.1 i386.
> ...
> Last time I check, tap:qcow does not work when using Windows with
> GPLPV or HVM Linux with PV drivers.
>
> The only other alternative that I know of, with acceptable performance
> and space allocation flexibility, is to bring in Opensolaris with zfs
> volume, either as dom0 or as iscsi server.
>
> Regards,
>
> Fajar
And on Sunday 12 April 2009, Brian Conway wrote:
> On Sat, 11 Apr 2009 16:10:21 +0200
>
> Geert Janssens <info@kobaltwit.be> wrote:
> > * Created a copy-on-write disk image, based on my original image with
> > qemu-img create -b <original image> -fmt qcow <new image>
> > and changed the blockdevice line in my config file to
> > disk = [ ''tap:qcow:<new image>,hda,w'',
'',hdc:cdrom,r'' ]
> >
> > However, this configuration won''t boot. To be exact, the
guest aborts
> > very shortly after the bios hard drive discovery. So I presume the
> > copy-on-write disk image is somehow not working.
> >
> > Any hints on what goes wrong here ?
>
> I have the same problem with a freshly created qcow2 image using the
> qemu-img-xen tool.  The original qcow2 image works perfectly with
> tap:qcow2, but attempting to use it as a base for a new image halts the
> boot immediately.  The xend.log file don''t show any errors, it
only
> points me to the VM-specific log, which just stops dead.
>
> Perhaps this functionality isn''t supported?
>
> Brian Conway
Thanks both Brian and Fajar for your replies.

Unfortunately, iscsi or zfs are no options for now.

But I am now considering another approach:
My dom0 runs lvm. So I might convert the qcow disk image to an lvm partition 
and use that as the block device for my XP domU.
LVM has got snapshotting capabilities as well. So I would have one base WinXP 
partition (like a base qcow disk image). The idea is to run updates first on a 
snapshot of this LVM, to check if there are no issues.

Of course this new idea comes with another set of questions:

1. Would such a setup make sense ?
2. What performance could I expect from the lvm based setup compared to qcow 
based disk images (better or worse indications suffice) ? Most of what I read 
on the list suggests that lvm should be faster.
3. Do the GPLV drivers work with an LVM based block device ? And also on a 
snapshot ?

Thank you,

Geert
-- 
Kobalt W.I.T.
Web & Information Technology
Brusselsesteenweg 152
1850 Grimbergen

Tel  : +32 479 339 655
Email: info@kobaltwit.be


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