Re: [Kimchi-devel] [RFC] Guest cloning

On 10/14/2014 12:15 AM, Aline Manera wrote: > > On 10/10/2014 07:25 AM, Yu Xin Huo wrote: >> I am also thinking to add a centralized area in header to hold all >> asynchronous tasks. > > Hrm... Tasks are an internal concept (from development view). The > user doesn't know what they are. > It'd be good to have this feature to let user know what's going on in the kimchi and even more it'd be better to have a progress bar(UI) for each under task like guest clone/migrate. -Simon >> >> >> On 10/3/2014 2:05 AM, Crístian Viana wrote: >>> Hi everyone, >>> >>> I'm presenting here my proposal for the feature "Guest cloning" which >>> is expected to be implemented for Kimchi 1.4. >>> >>> >>> Description >>> >>> Cloning a guest means creating a new guest with a copy of the settings >>> and data of the original guest. All data described by its XML will be >>> copied completely, with the following exceptions: >>> >>> * name: the new guest will have an automatically generated name. >>> We can append "-clone<n>" to the original guest's name, where >>> <n> is related to the number of clones created from that guest. >>> For example, cloning a guest named "myfedora" will create a new >>> guest named "myfedora-clone1"; if another clone for that same >>> guest is requested, it will be named "myfedora-clone2". >>> * uuid: the new guest will have an automatically generated UUID. >>> We can create a random UUID for every cloned guest. >>> * devices/interface/mac: the new guest will have an automatically >>> generated MAC address for every network interface. We can >>> create random MAC addresses for every cloned guest. >>> * devices/disk: the new guest will have copies of the original >>> guest's disks. Depending on the storage pool type of each disk, >>> a different procedure may be used to copy that disk: >>> >>> * DIR, NFS, Logical: the disk file will be copied to a new >>> file with a modified name (e.g. "disk.img" -> >>> "disk-clone1.img") on the same storage pool. >>> * SCSI, iSCSI: the volume data will be copied as a new disk >>> file on the storage pool "default". >>> >>> >>> REST API >>> >>> Only one new REST command will be added. >>> >>> >>> Syntax >>> >>> POST /vms//<vm-name>//clone >>> >>> >>> Parameters: >>> >>> None. >>> >>> >>> Return: >>> >>> An asynchronous Task with "target_uri" containing >>> "/vms/</new-vm-name/>". >>> As expected with any Task, the cloning process can be tracked by >>> checking the corresponding task's status. >>> >>> >>> Discussion >>> >>> I think the most challenging part of this feature is how to deal with >>> different types of disks while not prompting the user with any input. >>> There are a lot of possibilities and a lot of things that can go wrong >>> during the disks copy but we still need to do whatever is easier for >>> the user. For example, do we really have to create the new disks in >>> the same storage pool as the original disk's? If that's not possible >>> (e.g. not available space), should we create them in another pool with >>> available space? Should we ask any input from the user (e.g. "Would you >>> like to create the new disk on the same storage pool or on a different >>> one?")? What about the *SCSI pool types, is it OK to copy the volume >>> data to a different storage pool (i.e. "default") like I'm proposing >>> here? I couldn't think of a way to add a new volume in an existing pool >>> of those types. How about making the *SCSI volumes shareable between >>> the original and the new VMs? I don't like that approach because then >>> both VMs will use the same disk, whatever is changed in one VM is also >>> changed in the other one, and that's not a clone for me, that's a >>> "hardlink". >>> >>> Any feedback is welcome! >>> >>> Best regards, >>> Crístian. >>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt(a)cn.ibm.com, Phone: 824549654