[et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature (changing from libvirtML)

[Daniel P. Berrange]

On Thu, May 10, 2007 at 08:00:38PM +0900, Kazuki Mizushima wrote:
> Hi,
> 
> I've been planing to adding cloning feature.
> First, I tried to make the patch for libirt/virsh.
> 
> As a result of having disscussed in libirtML, it followed 
> that it is better to implement it in a higher module by 
> suggestion of Daniel Veillard and Dan Berrange with the following reasons.
> https://www.redhat.com/archives/libvir-list/2007-April/msg00151.html
> 
> I also agree. So I made patches again based on the opinion of two.
> There are two new files.
> 
> 1)CloneManager.py (The same directory as DistroManager.py in virtinst)
> This module is Cloning a virtual machine. This has One class named 
> "CloneDesign".
> The CloneDesign class is the design paper for cloning VM.
>  ?$B!&clone_name
>  ?$B!&clone_devices
>  ?$B!&clone_mac
>  ?$B!&guest_xml etc...
> CloneManager takes the CloneDesign Object and edits the XML acquired form 
> source VM according to the object. 
> 
> The outline processing that CloneDesign does is the following. 
>  a)Check existing source VM used lookupByName() when source VM name is 
>  setted.
>  b)Get the XML of source VM used XMLDesc() when source VM name is setted.
>  c)Get source devices size used Python API(getsize or "fdisk -s") for 
>  displaying cloning progress when source VM name is setted.
>  d)Check Shutoff status used dom.info()[0] when source VM name is setted.
>  e)Check NOT existing VM used lookupByName() when clone VM name is setted
> 
> The outline processing that CloneManager does is the following. 
>  a)Edit source VM XML according to taked CloneDesign object
>  b)Copying devices used Python API(Now read() and write())
>  c)Define the XML used conn.defineXML()

That's a good way you've implemented the XML changes using the in memory
nodes from libxml. It means that when we add extra info to the XML over
time, the clone tool should (mostly) handle it without changes (unless the
new info is some unique attribute to the VM).

A couple more bits of XML (potentially) need changing:

  - In the <graphics> tag, if the 'port' attribute is not already -1, then we
    need to set it to -1 - otherwise the VNC ports will clash.
  - In the <interface> tag, if there is a <target> element present, we need
    to remove it completely. The <target> element is very rarely used, but
    since it refers to the backend device name (ie to change from the default
    of vifN.M) we need to remove it otherwise backend devices will clash.
  - In the <console> tag, if there is a 'pty' attribute we need to remove it.
  - In the <interface> tag, if there is a <ip> element that needs removing.

That is basically all. Most important changes of MAC & UUID are already done.


> 2)virt-clone
>  This is user I/F script file handling CloneManager module in virtinst.
>  I also think it is simpler to have a separate tool for this purpose.
> 
> This revision is not able to supported for diffrerent "disk type".
> (e.g. From "file" to "block" or From "block" to "file".)

That's a reasonable limitation to start off with - should be easy enough
to fix it later.

> Now, I investigate sparse files copying.

There's no easy way to detect if a file is sparse - particularly in python.
I think the best option is to detect sequences of zeros. eg, if you are
reading the source file 4096  bytes at a time, check to see if that 4096
set of bytes are all zeros. If they are, then seek() forward 4096 bytes
instead of writing the set of zeros.

> 
> Attached patches shows outline below.
> ---------------------------------------------------------
> # ./virt-clone --help
> Usage: virt-clone [options]
> 
> Options:
>  -h, --help            show this help message and exit
>  -n NAME, --name=NAME  Name of the source guest instance; The status must be
>                        shutoff
>  -w CLONE_NAME, --new=CLONE_NAME
>                        Name of the clone guest instance; if none, adding
>                        fixed string _CLONE to source guest name

I think I'd swap these 2 around. Have  --name / -n  refer to the name of the
new VM to be created. And have  a  '--source NAME|UUID'  arg to specify
the original VM, based on its name or uuid. I'd also make --name compulsory
rather than appending _CLONE to the original name.

>  -m CLONE_MAC, --mac=CLONE_MAC
>                        Fixed MAC address for the clone guest; if none or
>                        RANDOM is given a random address will be used
>  -f CLONE_DISKFILE, --file=CLONE_DISKFILE
>                        File to use as the disk image for the clone guest
>                        instance

We should add a few more args here that we've already got with virt-install
In particular the --debug flag is very useful for debugging problems -eg
it will print out XML of new domain in virt-install.

To support QEMU/KVM, we should also have the --connect URI  flag, and pass
it down into the libvirt.open() call, rather than hardcoding a Xen connection.

Finally a --uuid arg too, to let people pre-define the UUID if needed.


With the  VNC port stripping & the  --connect URI arg to let it work with
QEMU+ KVM, I'd be happy to see this code included in the repo.

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  -=|