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

[Daniel P. Berrange]

On Mon, Jul 20, 2009 at 02:08:14PM -0400, 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.

If it isn't marked <sharable> or <readonly>, and we can't clone it, then
we should simply stop the whole clone attempt. It is just too dangerous
to pretend we can do anything else in that situation - we should focus
on addressing the reason for the failure to clone the disk data instead.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|