From mboxrd@z Thu Jan  1 00:00:00 1970
From: Martin Kletzander <mkletzan@redhat.com>
Subject: Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt
 save/restore when migration not advertised
Date: Thu, 6 Oct 2016 11:43:07 +0200
Message-ID: <20161006094307.GN16414@wheatley>
References: <1475600547-1009-1-git-send-email-ian.jackson@eu.citrix.com>
 <1475600547-1009-3-git-send-email-ian.jackson@eu.citrix.com>
 <a8ab1458-e85c-37a4-c201-b8aeab39b161@suse.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4230591303119682842=="
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta6.messagelabs.com ([193.109.254.103])
 by lists.xenproject.org with esmtp (Exim 4.84_2)
 (envelope-from <mkletzan@redhat.com>) id 1bs5Cq-0005Kz-Ci
 for xen-devel@lists.xenproject.org; Thu, 06 Oct 2016 09:43:12 +0000
In-Reply-To: <a8ab1458-e85c-37a4-c201-b8aeab39b161@suse.com>
List-Unsubscribe: <https://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Jim Fehlig <jfehlig@suse.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, Julien Grall <julien.grall@arm.com>, Ian Jackson <ian.jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org


--===============4230591303119682842==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="7VkxxUl3xUvPtoxk"
Content-Disposition: inline


--7VkxxUl3xUvPtoxk
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline

On Wed, Oct 05, 2016 at 06:06:29PM -0600, Jim Fehlig wrote:
>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?
>

The thing is that it's not documented.  I can't even say "enough", it's
more like "at all".  You can have a look at it:

  https://libvirt.org/formatcaps.html

It doesn't even talk about <migration_features/>, just <migration/>, but
I guess that's the same thing.

Since offline migration (as in migrating a domain between hosts without
being running) is not that used in the code and talked about, I'm
guessing offline means save restore.  Looking at the history it was
added before the "offline" migration, so it probably means
save/restore.  To avoid confusion, I would suggest we add either
<offline/> or rather <save/> (the naming is not important) and document
what it means.  And then you can use it exactly how you'd like.  And
you'll be also sure it means what you need it to mean ;)  The patches
will be straigh-forward, let me know if I can help anyhow.

>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?
>

With that you could straight check for <save/> and <live/> ;)

Martin

--7VkxxUl3xUvPtoxk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJX9hyqAAoJEAgfwp8kF4bdrf0P/0x+F4tmqcSaCu7ERavxJadN
RQr/q5kmBXV+f0klIHSCflKi001B37FFmag6Dx/9VVp4V1K9lM95WOBVc0KsCZrk
J4fV6mbhuHVdN8ZVVX/TlRMsXXq6vfbAp1h+QSQZUlsC+wc8HA7yJ8z4aikgkl2S
3tf8PswllA3gtrFEvNJqStiMn+p0mQK+PkTG/PxsSVvi0uwb2lF1h2O58DS+HDdB
YaleObfSCdIqPKZH3aITgTYyef9lclyUA2CLJyfWFWfGFM+RpcLwIdQ725GKmhU/
oQVpvaC6UddbwrpGjovojr+XDFETYVdNzf0uozwju+XYX+7Ht2s8RsQX32Q9rlLg
31LlNWl/5Hkyp+Mg8RYuHjjEgtYU+n9UuoA4LMbSenGAr9w2lUGKjQwlAZYe9N/Y
90SJtnlLSddoyHY87aPaRVUK3fZMDQPdonjEb8ExPbOVHGabo2zSOZoTU1SjmBTZ
GLNjOrgLD8UGVEUGeEekuGgDAqJ4PAjMUj+9E3U3RgOQO55vtlrpXV8Rd9cCa8nR
xNlRXNKhjGQZ4zfhNIFDHpBVcScmKmkQyHuUkZAdr5UL4If97tCbfk66zijNi5J6
rDOOQXJn9xsGmdfV9APt8AZlim84/9Yot1GhXmsIeqNZVXYak1EX2CozIll04CxZ
vzvnzqvjLBNCZt+FhD3A
=UEvK
-----END PGP SIGNATURE-----

--7VkxxUl3xUvPtoxk--


--===============4230591303119682842==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============4230591303119682842==--