GNOME Bugzilla – Bug 710307
support cloning a vm
Last modified: 2016-09-20 08:16:03 UTC
(from Montreal summit session) Technically, this is probably equivalen to export+import, but it should be much quicker, and less heavy. For the name, we can just append/increment a number to the end of the current name, and let the user edit it after the fact. Cloning should be supported in addition to snapshots, since snapshots are stored inside the same image, and thus there is a risk of loosing all snapshots if the disk image gets corrupted. Cloning avoids this risk.
If providing a logical "clone VM" feature to the user, it should make sure that any unique data inside the VM is scrubbed / state reset. eg scrub SSH host keys, reset saved random state, run windows sysprep, etc. This scrubbing can all be done with the libguestfs virt-sysprep tool
(In reply to comment #1) > If providing a logical "clone VM" feature to the user, it should make sure that > any unique data inside the VM is scrubbed / state reset. eg scrub SSH host > keys, reset saved random state, run windows sysprep, etc. This scrubbing can > all be done with the libguestfs virt-sysprep tool Been trying to avoid libguestfs dependency so I'm not sure anymore if we want to support cloning. We could just go straight towards snapshots.
The thought behind this feature request was that cloning would be easy and good short-term fix for lack of snapshots support but seems neither of these are true.
I'm marking this as WONTFIX for now, assuming that baedert will be able to implement snapshot support pretty soon. We can reopen and reasses this if he hits a snag.
*** Bug 751226 has been marked as a duplicate of this bug. ***
(In reply to Daniel P. Berrange from comment #1) > If providing a logical "clone VM" feature to the user, it should make sure > that any unique data inside the VM is scrubbed / state reset. eg scrub SSH > host keys, reset saved random state, run windows sysprep, etc. This > scrubbing can all be done with the libguestfs virt-sysprep tool I don't think this should block the feature at all: The very nature of desktop virtualization means that we have no control over the guests. Some people might use it to virtualize a Windows machine, some others to virtualize an x86 Android machine and some others FreeBSD. There's no way we can ensure control over what goes in the guests, so we should assume that ultimately, if things don't quite work after cloning, it is _fine_ if the user has to do the tweaking himself. The alternative is way worse: having no cloning means that people have to install and customize, from scratch, repeatedly, every instance of the OS that they need available in their setup (usually a time consuming tasks given the amount of I/O involved in installing an OS, let alone putting the software and the configuration that it needs on top). At this point it is more time saving to just switch to another solution. If we can influence some guest OSes to behave properly and regenerate SSH keys or other tasks that we assume safe, that is fine by me, but from my POV the detriment in the user experience of not having this available is greater than the harm done when we can't be smart enough.
(In reply to Alberto Ruiz from comment #6) > (In reply to Daniel P. Berrange from comment #1) > > If providing a logical "clone VM" feature to the user, it should make sure > > that any unique data inside the VM is scrubbed / state reset. eg scrub SSH > > host keys, reset saved random state, run windows sysprep, etc. This > > scrubbing can all be done with the libguestfs virt-sysprep tool > > I don't think this should block the feature at all: > > The very nature of desktop virtualization means that we have no control over > the guests. That is not true. This is the reason we have agents in guests and all desktop virtualization software installs agents into their guest. Boxes installs at least spice-vdagent if express installed. I was thinking of also getting qemu agent into the guest but I didn't see them providing ready installer binaries for Windows. > The alternative is way worse: having no cloning means that people have to > install and customize, from scratch, repeatedly, every instance of the OS > that they need available in their setup (usually a time consuming tasks > given the amount of I/O involved in installing an OS, let alone putting the > software and the configuration that it needs on top). Ah ok. This feature was initially suggested mainly as a work around for snapshots but I guess there are valid good usecases independent of snapshots.
(In reply to Zeeshan Ali (Khattak) from comment #7) > (In reply to Alberto Ruiz from comment #6) > > (In reply to Daniel P. Berrange from comment #1) > > > If providing a logical "clone VM" feature to the user, it should make sure > > > that any unique data inside the VM is scrubbed / state reset. eg scrub SSH > > > host keys, reset saved random state, run windows sysprep, etc. This > > > scrubbing can all be done with the libguestfs virt-sysprep tool > > > > I don't think this should block the feature at all: > > > > The very nature of desktop virtualization means that we have no control over > > the guests. > > That is not true. This is the reason we have agents in guests and all > desktop virtualization software installs agents into their guest. Boxes > installs at least spice-vdagent if express installed. I was thinking of also > getting qemu agent into the guest but I didn't see them providing ready > installer binaries for Windows. There's no way we know in advance which OS and which versions of that OS the user ends up trying, of course we can try our best to support the common distros/OSes, but ultimately that's all we can do, our best. We have quite limited control on what ultimately goes inside the VM. Many people use VMs precisely to try OSes they wouldn't install on their machine otherwise. Obiously most common cases are Windows, Ubuntu and alternative versions of the OSes they already run (Fedora, Suse, RHEL, CentOS...). But there is a long tail of users wanting to virtualize other OSes like FreeBSD/FreeNAS, CoreOS, *BSD, SmartOS/Solaris... we have very limited influence on the infrastructure we can include by default in those projects. If anything we can try to come up with guest tools that support them, which is quite a lot of work. From my POV it is O.K. if we try our best to provide a seamless experience with OSes we can influence or hook into, but leave it up to the user to handle the OS they're managing if we can't possibly support them. Quite frankly, as I stated, the alternative harms Boxes more than it helps it all things considered. > > The alternative is way worse: having no cloning means that people have to > > install and customize, from scratch, repeatedly, every instance of the OS > > that they need available in their setup (usually a time consuming tasks > > given the amount of I/O involved in installing an OS, let alone putting the > > software and the configuration that it needs on top). > > > Ah ok. This feature was initially suggested mainly as a work around for > snapshots but I guess there are valid good usecases independent of snapshots.
*** Bug 764364 has been marked as a duplicate of this bug. ***
Done! Also fixed a few issues I found on the way. commit: e9e18ecbbfc666dd89cc32008c096b8f9a44a5b1 LibvirtSystemVMImporter -> LibvirtVMImporter Not only this class is agnostic to the type of libvirt connection the VM is being imported from, we'll be re-using this class in a following patch to import (rather clone) VMs from session libvirt connection. commit: e95c5397600561535dcf2f0ee0e4215d5c4ada28 LibvirtSystemMedia -> LibvirtMedia Renaming for exactly the same reason as the previous commit (LibvirtSystemVMImporter -> LibvirtVMImporter). commit: 313f5a8340296bd110e2da15a6044c7117eb90e5 actions-popover: Don't open under-import VMs If the VM is being imported, do not allow it to be launched from actions popover. We already don't allow it to be launched via mouse click. commit: f9c34011db4d2495119e348a552ad2ba6861fa75 actions-popover: No properties for under-import VM If the VM is being imported, do not allow user to go to it's properties. Hardly any option will work while importing so why bother. commit: 1205a2beca4d9275e9fb601009dde2b91ee7b6aa selectionbar: Don't open under-import VMs If the VM is being imported, do not allow it to be launched from selection mode. We already don't allow it to be launched via mouse click. commit: 061a45e4994345018503a6d6dcd83c8268dfc3f2 libvirt-machine: Notify changes to 'importing' property commit: 6e71b216add834003801b70b08bae0c0898db557 libvirt-machine: Mark under-import as un-saveable We can't really save machine that is under import, so let's not give that impression. commit: 72a36c7be100517b82438b3d1c9502f83dcb4137 machine: Add cloning API Add abstract method clone() and abstract property can_clone. Currently this is not implemented by any Machine subclass, i-e can_clone property is set to false by all subclasses. commit: 2e0f61af429eb93610b5d1099e8edd0c35a269d1 remote-machine: Implement cloning commit: ecbc5faf8679098ef255f87bcad3c2fbfc0c25b0 installed-media: Allow bypassing format check In certain cases (e.g the cloning code that will be added in a following patch), the media will already be in qcow2 format so there is no need to check for format of disk image. Moreoever, currently our disk images lack the file extension so our own code breaks on detecting it's type as we rely on file extensions for detection. commit: cee058a39dea029d8ca87e8aabae66661bbfab36 libvirt-broker: Ignore transient guestfs domains Boxes need not show these domains to users and users are not expected to interact with them. commit: c4703772f6f37bb5760791e040878d46d21d42ee vm-importer: Add protected virtual post_import_setup() Put all post import setup into a separate virtual protected method. We'll use this in a following patch when we add a new subclass of VMImporter to implement cloning of existing VMs. commit: 755ac35afa6f308ece50089668e2f3aff2c71c68 Add LibvirtVMCloner This subclass of LibvirtVMImporter will be handling the cloning of libvirt VMs. commit: c1fe670ea381ee421d6f7d3a3d089f7fb15016ac Add LibvirtClonedMedia Add a special subclass of LibvirtMedia that represents a media, that is being cloned. commit: 79b748d9611453e759819d52b25916951f9cd8bb libvirt-machine: Implement cloning commit: 5b4cfdaba656b4ac7f27b27b495fa72d87705c45 machine: can_delete prop now public settable commit: 9f53acb4959af593a46ce6f48568cb1dc139ebea actions-popover: Add option to clone boxes
*** Bug 766641 has been marked as a duplicate of this bug. ***