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 :| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
