[virt-tools-list] RFC: virt-manager: VM clone wizard

[Michal Novotny]

Hi,
sorry, ccing the list since virt-tools-list is *not* setup to 
automatically reply to this list if not replying to all (but some lists 
do have default "Reply-To" header to the list so changing this to list 
itself should be good).

Thanks,
Michal

On 07/21/2009 12:45 PM, Michal Novotny wrote:
> On 07/20/2009 08:08 PM, Cole Robinson wrote:
>> Daniel P. Berrange wrote:
>>    
>>> On Mon, Jul 20, 2009 at 01:11:29PM -0400, Cole Robinson wrote:
>>>      
>>>> Hi all,
>>>>
>>>> The attached patch adds a small wizard for cloning a VM. A screenshot of
>>>> the overview:
>>>>
>>>> http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-overview.png
>>>>
>>>> The wizard will generate a new VM name (usually<orig-name>-clone), new
>>>> storage paths as required, and MAC addresses. Storage is marked as
>>>> one of:
>>>>
>>>> - Shared: Original and clone VM point to the same disk image
>>>> - Clone : Actually copy the original storage for use by the clone
>>>>
>>>> Storage like removable media (cdrom, floppy), readonly or shareable
>>>> disks will be 'Shared' by default.
>>>>
>>>> The storage drop down has a 'Details' choice:
>>>>
>>>> http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-dropdown.png
>>>>
>>>> This brings up a small dialog which allows changing the new disk path:
>>>>
>>>> http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-storage-details.png
>>>>
>>>> There is also a similar dialog for changing MAC addresses.
>>>>
>>>> If we can't clone storage (maybe lack of permissions, or remote
>>>> unmanaged storage, older libvirt), we still allow cloning the VM, but
>>>> force the offending disks into 'Shared' mode. In the case of sharing a
>>>> read/write disk, we give a clear warning that this may result in
>>>> overwriting the original image.
>>>>        
>>> IMHO, we should simply disallow that. Users would expect that
>>> cloning a guest is guarneteed to not impact the original. If
>>> we can't guarentee that, we should refuse to clone it. Swiching
>>> a private disk to shared mode is giving a user a loaded gun
>>> with no safety catch&  a touch sensitive trigger.
>>>
>>>      
>>
>> Are you saying we should disallow sharing any private disks, or only
>> ones that it appears we can't clone? I suppose any shareable disks
>> should be marked with<shareable/>  in the XML, but that currently isn't
>> obvious to the user, or easy via any of the tools atm.  The cases when a
>> user would actually want to share a r/w disk though are rare enough that
>> we should require the sharable flag, and deny the clone operation otherwise.
>>
>> - Cole
>>
>>    
Well, I don't know whether it's appropriate or just some off topic 
because this is not what's this about but I don't understand 
virt-manager/python-virtinst/libvirt much yet but when I was working on 
Xen (and virt-manager should support Xen) there was a duplicate check 
and it was all based on uname (physical disk path) and mode. So I think 
we should consider mode into that and disallow cloning (sharing) disk 
images that are write-exclusive etc... But we should make there an 
option to copy this one disk into another disk image (like in 
vmm-clone-storage) and put this one into XML configuration per new VM so 
I guess just giving the warning about sharing read/write disk is not a 
good way. We should consider whether the domain is running and when I 
did a duplicate check to Xen this disallows 2 concurrently running 
guests use the same disk image not to cause disk corruption so this 
should not be allowed so is really sharing read/write disk image a good 
option? At least Xen will disallow this with error message that the disk 
is already in use.

The readonly images, like mounted ISOs into VMs, should be shareable 
between all the guests because there's no risk of multiple write 
accesses and therefore a disk corruption of this one.

Also, cloning MAC addresses should have a check for duplicate MAC 
addresses not to have MAC conflicts there.

Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20090721/4dd8bd0c/attachment.htm>