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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list