[Libvir] [PATCH][RFC] Adding Cloning Feature

[Daniel P. Berrange]

On Tue, Apr 24, 2007 at 10:57:09PM +0900, Kazuki Mizushima wrote:
> Hi all,
> 
> I've been planing to adding cloning feature.
> Then, I tried to make the patch in the following way. 
> 
> 1)Get the XML used virDomainGetXMLDesc
> 2)Delete <uuid>, <mac> node element
>   This intened to automatically generated.
> 3)Changing <name>, <source dev> string node element
> 4)Fork "dd" process
> 5)Define XML used virDomainDefineXML

While this works ok in simple cases, I'm not sure it neccessarily scales
upto handle the more complex cases easily enough. With this prototype the
user only has the option of specifying new device names. Conceivably the
user could want to specify a whole lot more 'new' parameters - eg change
the VNC port if it was not previously auto-allocated, specify a new MAC
address (for any/all NICs), specify a UUID, etc. 

If using LVM for the backing store, instead of dd'ing the disk they could
simply take a (writable) snapshot of the disk - this could even be done 
while the source VM was active (assuming use of a journalling FS inside
the guest).  If doing a flat copy of the disks, it will also be important
to provide progress feedback to the user - when initially allocating guests
it takes a good 30-60 seconds per GB of disk to be allocated - cloning an
existing guest will be longer because instead of just writing zero's you
are reading & writing data.

> 
> This feature is just a first revision, 
> because I make this patch within current libvirt API limitation.
> Also Remote Cloining is Limited.
> But if we can libvirtd for feature, it will be enhance remote cloning
> based on this pach
> (as http://libvirt.org/remote.html#Remote_libvirtd_configuration)
> 
> Finally, to have to communicate with the demon remotely as libvirt library, 
> actually I want to put down to new libvirt API (e.g. virDomainClone).

For remote support, we'd really need to have some basic storage management
APIs to let us allocate new 'chunks' of storage for the virtual disks.

> Could you hear your comments about this ?

I think cloning should be kept separate from the main libvirt API because
there are simply too many different ways to approach it, depending on your
application use-cases. The way I like to look at it, is that we've just got
several different ways to 'install' a guest

  1. Traditional installation media (eg CDROM, HTTP kickstart)
  2. Boot a LiveCD which can install itself to disk
  3. Create from a VM 'template', possibly cloning some base disk
  4. Cloning an existing provisioned VM

Now virt-install currently deals with the first option, and there is some
work going on to experiment with making it do options 2 & 3 too. So I think
that it'd be worth trying to add some form of cloning capability to virt-install
too.

Thinking how it might work..

Currently to install from HTTP you might do

   virt-install
      --name myvm
      --ram 500
      --mac 54:24:52:23:55:43
      --vnc
      --vncunused
      --url  http://download.fedora.redhat.com/pub/fedora/linux/core/6/x86_64/os/
      --filesize 5
      --file /var/lib/xen/images/myvm.img

So, how might it work with cloning ? Basically install of the --url arg to point
to an install source, we'd allow  '--clone VMNAME' to point to an existing virtual
machine. The main config would be determined by the settings of that VM, with the
command line args being used to override specific bits. As a bare minimum
example one would do

   virt-install
      --name othervm
      --clone myvm
      --file /var/lib/xen/images/othervm.img

But for a more complex case one could use all the various args

  virt-install
     --name othervm
     --clone myvm
     --uuid 2452:ef23:ee3e:2232:442424252525ffe
     --vncport 5902
     --mac 42:55:23:66:23:44
     --file /var/lib/xen/images/myvm.img
     --file /var/lib/xen/images/myvmdata.img


Now without prototyping it, I'm not sure how much code re-use we'd get within
virt-install, so it may turn out that it is simpler to just have a separate
tool called  virt-clone for this purpose. In either case I reckon we could
distribute this as part of the main  virtinst codebase, so it is still easy 
for us to access the functionality from virt-manager.

Regards,
Dan.
-- 
|=- 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  -=|