[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]