WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] Re: [Xen-devel] Re: Writing a tool for Shared Persistent Win

On Thu, Jun 28, 2007 at 12:18:47PM -0600, Jim Burnes wrote:
> 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

It is not possible to use  blktap with HVM guests - there was code which tried
to make it work, but its utterly broken[1]. In my spare time I'm trying to fix
it, but no ETA.

Dan.
[1] it is calling APIS in XenD which no longer exist & has a try..except
    block which silently catches & ignores the errors, so you never notice
    that it failed.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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