[et-mgmt-tools] [PATCH][RFC][virtinst] Adding Cloning Feature(changing from libvirtML)
Kazuki Mizushima
mizushima.kazuk at jp.fujitsu.com
Tue May 15 00:31:12 UTC 2007
> 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.
Thank you for this information.
The patch which I attached does not yet depend on this change.
> That's a reasonable limitation to start off with - should be easy enough
> to fix it later.
O.K. I also think it is easy.
> 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.
This proposal is good for me.
First of all, I will try by this way next development.
Also how about is the below idea ?
・ virt-clone has "--nonsparse" args as same as virt-install.
A new sparse device file is made by lseek(os.path.getsize(soucefile or sourcedisk))
whenever the destination device that the user specified is not found and
the option "-- nosparse" is NOT specified, then destination device is copied.
A new normal device file that had all zeros is made by write('\x00')
Only when the destination device that the user specified is not found and
the option "-- nosparse" is specified, then destination device is copied.
> 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.
Ohh, it is certainly confusing. I agree and define the below.
Original guest -- source guest(domain)
Clone guest -- destination guest(domain)
So I take the '--original NAME| UUID' args and make '--name' compulsory.
> 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.
Thank you for commets.
I made it again referring to virt-install and retested.
Attached patches shows help below
---------------------------------------------------------------------------
# ./virt-clone --help
Usage: virt-clone [options]
Options:
-h, --help show this help message and exit
-o ORIGINAL_GUEST, --original=ORIGINAL_GUEST
Name or uuid for the original guest; The status must
be shut off
-n NEW_NAME, --name=NEW_NAME
New name for the clone guest
-u NEW_UUID, --uuid=NEW_UUID
New UUID for the clone guest; if none is given a
random UUID will be generated
-m NEW_MAC, --mac=NEW_MAC
New fixed MAC address for the clone guest; if none or
RANDOM is given a random address will be used
-f NEW_DISKFILE, --file=NEW_DISKFILE
New file to use as the disk image for the clone guest
-c CONNECT, --connect=CONNECT
Connect to hypervisor with URI
-d, --debug Print debugging information
Signed-off-by: Kazuki Mizushima <mizushima.kazuk at jp.fujitsu.com>
Thanks,
Kazuki Mizushima
-------------- next part --------------
A non-text attachment was scrubbed...
Name: virt-clone.patch
Type: application/octet-stream
Size: 6075 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20070515/8d047ef2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CloneManager.py.patch
Type: application/octet-stream
Size: 14912 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20070515/8d047ef2/attachment-0001.obj>
More information about the et-mgmt-tools
mailing list