Re: [libvirt] [PATCH v2 1/2] migration: Introduce <migration> element for cdrom and floppy
On Mon, Oct 03, 2011 at 04:07:23PM +0200, Michal Privoznik wrote:
This element says what to do with cdrom (or floppy) on migration.
Currently, only one attribute is supported: 'optional'. It accepts
'require', 'optional' and 'drop' values. Setting a cdrom to be
required means migration will fail if destination cannot access
source under the same path. Setting to optional means, if destination
cannot access disk source, it simply gets free()'d/ejected.
Finally, setting to drop will simply cause cdrom to be dropped
regardless of path being accessible or not.
I'm not convinced of the need for 'drop'. If an app knows that
it never wants the CDROM regardless of whether it exists, then
it can just eject the media itself.
This functionality is important for users, whose machines get buggy.
So they decide to save as much as possible and migrate the machine
even they won't be able to access (readonly) cdrom on destination.
If we think this is a reasonable thing todo upon migration, then
there is a reasonable argument to be made that we should support
this functionality upon restore from saved state, and revert to
snapshot. And once you're doing that, why not also allow it for
initial VM bootup too ?
In other words having an attribute named 'migration' is likely
not the right way to model this. I'd think perhaps we should
have a parameter 'on_missing' (not a huge fan of this name,
suggestions welcome) which takes three values:
- mandatory - fail if missing for any reason (the default)
- requisite - fail if missing on boot up, drop if missing on migrate/restore/revert
- optional - drop if missing at any start attempt.
Next, if we're going to automagically change the guest configuration
during any phase of startup, we need to emit an async event so that
the management application can find out that we had a failure.
The harder bit is actually figuring out whether the disk exists
or not. libvirtd cannot simply use virFileExists(), since this
fails horribly on root squashing NFS servers. At a minimum we
need to run this from a process with a uid/gid matching what we
will eventually run QEMU as. Ideally we would want to run under
the same cgroups configuration, and the same SELinux config as
the guest will run as, to maximise our chances of avoiding
false negatives.
Finally, CDROM/Floppy devices are not unique in this respect. There
have also been request todo something similar with networking. ie
if the guest is configured for bridge=br0, and br0 does not exist,
then re-configure the guest to have a no-op networking backend (ie
just the gust device, with no host connection). Or if VEPA setup
fails, re-configure the guest to have no-op networking. We'd also
need to make it possible to re-configure host networking for a
guest device on the fly, using virDomainDeviceUpdate, to let an
admin re-connect the guest to a new host network once the problem
has been resolved.
No matter which device we're touching, the change in config should
be visible in the live guest XML, but the persistent XML should
preserve the original configuration.
I'm happy if you just do the CDROM/Floppy stuff for a first cut of
the patches, as long as the XML design we have is applicable to
a future patch to support this for network devices too.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|