Webrev: http://cr.opensolaris.org/~johnlev/migration-dry-run/
The basic approach is that we add a new server command 'dryrun' to xend. This uses a similar path to normal migration. However, for dryrun, we run the hotplug scripts ourselves, using a private xenstore area so we don't affect anyone else. Since xend runs as 'xvm', we need a small suid wrapper to help us do this[1] (as 'xvm_control' owners can write to xenstore, we should not be providing any privilege escalation by doing this). (Darren, could you have a look at this?) Note that the device checks don't catch cases where the same path, but different file, exist on both machines (like /foo/bar/root.img). Without some kind of device ID checking, which seems difficult, we can't solve this problem. As well as device checks, we also have a simplistic check for memory usage and CPU vendor. Both can be refined later, but I think these will do for now. One unresolved issue: should we always do a dry-run check before a real migration? It would involve a reasonably expensive device setup/teardown before the real device setup, but without it, you can kill your domU: if a backend device isn't present, the migration completes "successfully" before the remote host notices the device is borked. The simple alternative is to ask users to use --dryrun instead. If there's any suggestions for other things we need to check, let me know. regards john [1] we can later use this to directly start stuff from qemu-dm _______________________________________________ xen-discuss mailing list [email protected]
