I've volunteered for the task of fixing virt-clone[0]. There are a number of bugs which need to be addressed. Unfortunately the current virt-clone is broken-by-design since it cannot make changes inside the guest.
[0] http://linux.die.net/man/1/virt-clone
The bugs boil down to what Microsoft calls "sysprepping" the clone, which is to say, removing its existing identity, hostname, ssh host keys, persistent network rules, host SID and workgroup name (for Windows). It's helpful for Linux guests to remove some of this stuff[1] -- it will make the cloning process smoother. For Windows it's absolutely required[2].
[1] https://rwmj.wordpress.com/2010/09/24/tip-my-procedure-for-cloning-a-fedora-... [2] http://technet.microsoft.com/en-us/library/cc721940%28WS.10%29.aspx
All that virt-clone can do now is to copy the guest and make some simple changes to the libvirt XML (eg. giving it a new MAC address). It doesn't even address the sysprepping problem.
The problem with sysprepping is that it's hard to do, and it's different for every operating system. I've summarized some of the techniques below. Worse than that, for some OSes there are different levels of sysprepping that an administrator might want; also see below.
So I'd like feedback from "virt-clone next generation" users:
(a) Is cloning guests useful for you or not? Often or infrequently?
(b) Do you currently use virt-clone to clone guests?
(c) Do you have a homebrew method to clone guests? What does it do?
(d) Do you use another tool to clone guests? (And how is it?)
(e) When you clone a guest, do you "sysprep" it or would you like to? (Using the term "sysprep" generically here, I mean any sort of reinitialization for Linux or Windows guests).
(f) How do you feel about a multi-step process?
virt-clone -> virt-sysprep -> virt-resize (for example)
(g) Have you had other problems with cloning guests?
(h) What have I missed out in this analysis? What other features have you missed in virt-clone?
Sysprepping Windows -------------------
This is a complex, manual process. We do some steps to automate it in RHEV. It's best to read Microsoft's online documentation at [2][3][4].
[3] http://support.microsoft.com/kb/302577 [4] http://blogs.technet.com/b/megand/archive/2005/01/20/357570.aspx
Fedora ------
In theory you can just write a file /.unconfigured in the root, and Fedora will go through the firstboot process at next boot (it will reset timezone, root password, netconfig, keyboard, authentication).
Some admins will *not* want all of these things to be reset, and will want either a lesser degree of unconfiguration, or will want to control each thing manually.
I'm not totally convinced that this hasn't been broken by systemd introduction in Fedora 15.
general Linux -------------
See [1].
Rich.
On Tue, 10 May 2011 12:56:30 +0100 Richard W.M. Jones wrote:
(c) Do you have a homebrew method to clone guests? What does it do?
I'm in the middle of devising a home brew clone script strictly for a Windows XP machine KVM I sometimes need extra copies of.
I have a readonly qcow2 image I use as a backing file for making new qcow2 images for the clones. I've manually changed the computer name and default screen background and gotten diffs showing the registry changes made (there are a fantastic number of them, which was hard to believe).
I'm about try try using the virt-win-reg tool on one of the new qcow2 images to modify the registry and give the machine a new identity before I boot it (but I haven't quite gotten around try trying it yet).
On 05/10/11 - 12:56:30PM, Richard W.M. Jones wrote:
Sysprepping Windows
This is a complex, manual process. We do some steps to automate it in RHEV. It's best to read Microsoft's online documentation at [2][3][4].
[3] http://support.microsoft.com/kb/302577 [4] http://blogs.technet.com/b/megand/archive/2005/01/20/357570.aspx
Note that Oz[1] can do some of this. There is a side-branch of Oz called "win2k8customize" that has some of this sysprepping functionality built-in. It's not on master at the moment because it requires something of a hacked-up tool called "winexe", but we are in the process of finding a replacement for "winexe" at the moment.
Hi,
(a) Is cloning guests useful for you or not? Often or infrequently?
I'm almost never do that.
Usually I use qcow2 copy-on-write images for testing, so I can easily rollback stuff by just zapping and re-creating the copy-on-write image.
When I need a fresh VM I install one. Have kickstart in place for RHEL/Fedora guests. Also a custom windows xp install cd which autoinstalls via unattended.txt, so I don't have to babysit the installs. Includes sp3 and some extra drivers (e1000, virtio-net, ...) too.
cheers, Gerd
On tis, 2011-05-10 at 12:56 +0100, Richard W.M. Jones wrote:
Fedora
In theory you can just write a file /.unconfigured in the root, and
Perhaps this could also be triggered by a change in the system UUID (see dmidecode). Store the UUID in a file during kickstart/firstboot and check it at every boot. If it changed then the disk was either moved or cloned to new hardware (physical or virtual doesn't really matter), so perhaps the system could ask for a root password and after confirmation start the re-setup process.
Some admins will *not* want all of these things to be reset, and will want either a lesser degree of unconfiguration, or will want to control each thing manually.
Yeah, it's rather analogous to kickstart.
I think every guest OS needs to have support for this internally because it gets too complicated to do it from the outside but it should be possible to trigger the process and control it using the virt tools.
The OS needs to back out some changes from the system and then redo part of the kickstart/firstboot. (The division between Anaconda and Firstboot seems a bit arbitrary, so I'm treating them as one thing here.)
Stuff that can happen at boot after cloning:
1. (If virt-clone triggered the boot, skip this step.) Ask the admin if this is a clone or a move. If it's a move, exit and continue with the normal boot. Otherwise, ask for the root password.
2. Eradicate as thoroughly as possible any host-private data. This can be Smolt ID, Spacewalk, RHN data, SSH key pairs, Kerberos keys, Puppet registration, reset the hostname to localhost.localdomain and so on.
3. Forget about any hardware that doesn't seem to exist anymore (so eth0 is removed from udev and the configuration is deleted from NM).
4. At this point it should be possible to shut down, thereby creating a clean slate template.
5. Re-run some parts of kickstart/firstboot. This should be scriptable and virt-clone should be able to provide this info. * Network config. * (Hash of) the root password, bootloader password. * Smolt, Kerberos hostkey, Spacewalk, RHN, Puppet... * %post script.
/abo
On 05/10/2011 12:56 PM, Richard W.M. Jones wrote:
So I'd like feedback from "virt-clone next generation" users:
(a) Is cloning guests useful for you or not? Often or infrequently?
Yes, I use it often, at work (Linux SysAdmin) and during Fedora testing cycle (Alpha, Beta, RC etc...).
(b) Do you currently use virt-clone to clone guests?
Yes, until bug rhbz#667509 appears.
(c) Do you have a homebrew method to clone guests? What does it do?
Yes, it a small shell script, that copy the guest image, create a new guest with virt-install --import ...
(d) Do you use another tool to clone guests? (And how is it?)
No.
(e) When you clone a guest, do you "sysprep" it or would you like to? (Using the term "sysprep" generically here, I mean any sort of reinitialization for Linux or Windows guests).
No.
(f) How do you feel about a multi-step process?
virt-clone -> virt-sysprep -> virt-resize (for example)
If virt-{clone,sysprep,resize} are separate tool then it very good idea otherwise (ie: one monolithic app) it's over-engineered.
(g) Have you had other problems with cloning guests?
Yes, bug rhbz#667509
(h) What have I missed out in this analysis? What other features have you missed in virt-clone?
PS. AFAIK, cloning on VMware does not touch the inside of the guest
-
Alexander Boström -
Athmane Madjoudj -
Chris Lalancette -
Gerd Hoffmann -
Richard W.M. Jones -
Tom Horsley