<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> 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: <blockquote cite="mid:4A659C50.5000803@redhat.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> On 07/20/2009 08:08 PM, Cole Robinson wrote: <blockquote cite="mid:4A64B28E.808@redhat.com" type="cite"> <pre wrap="">Daniel P. Berrange wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, Jul 20, 2009 at 01:11:29PM -0400, Cole Robinson wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, The attached patch adds a small wizard for cloning a VM. A screenshot of the overview: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://fedorapeople.org/%7Ecrobinso/virt-manager/clone-post/vmm-clone-overview.png">http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-overview.png</a> 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: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://fedorapeople.org/%7Ecrobinso/virt-manager/clone-post/vmm-clone-dropdown.png">http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-dropdown.png</a> This brings up a small dialog which allows changing the new disk path: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://fedorapeople.org/%7Ecrobinso/virt-manager/clone-post/vmm-clone-storage-details.png">http://fedorapeople.org/~crobinso/virt-manager/clone-post/vmm-clone-storage-details.png</a> 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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> </blockquote> 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 </body> </html>