On 10/04/2016 11:02 AM, Ian Jackson wrote:
Currently, osstest wrongly thinks that ARM can do save/restore, because `virsh help' does mention the save command (on all architectures).
Additionally, check the virth capabilities xpath /capabilities/host/migration_features to try to see whether this host supports migration.
I am not sure if this is the right path to check. Perhaps /capabilities/host/migration_features/live is more correct, but this may be wrong if Xen comes to support save/restore on ARM, but not live migration (but perhaps libvirt cannot express this distinction in which case perhaps it's right after all).
Looking at the capabilities generation code again, I see that virCapabilitiesNew() takes 'offlineMigrate' and 'liveMigrate' parameters. I assume offline in this context means save, copy, restore. Martin, is that assumption correct? If so, I think the saverestore_check() below can look for /capabilities/host/migration_features. The migration check in 1/2 can look for /capabilities/host/migration_features/live. Is it fair to assume save/restore is available when live migration is supported? Regards, Jim
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> CC: Julien Grall <julien.grall@arm.com> CC: Jim Fehlig <jfehlig@suse.com> --- Osstest/Toolstack/libvirt.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm index b7db7af..250fe47 100644 --- a/Osstest/Toolstack/libvirt.pm +++ b/Osstest/Toolstack/libvirt.pm @@ -111,7 +111,9 @@ sub check_for_command($$) {
sub saverestore_check ($) { my ($self) = @_; - return check_for_command($self, "save"); + return + _check_capability($self, '/capabilities/host/migration_features') && + check_for_command($self, "save"); }
sub migrate ($$$$) {