qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [virt-tools-list] Virt Tools Survey: What to do about v


From: Alexander Boström
Subject: Re: [Qemu-devel] [virt-tools-list] Virt Tools Survey: What to do about virt-clone
Date: Wed, 11 May 2011 21:03:44 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]