On 08/10/15 09:57, Daniel P. Berrange wrote:
On Wed, Oct 07, 2015 at 03:54:29PM -0600, Chris Friesen wrote:On 10/07/2015 03:14 AM, Daniel P. Berrange wrote:For suspended instances, the scenario is really the same as with completely offline instances. The only extra step is that you need to migrate the saved image state file, as well as the disk images. This is trivial once you have done the code for migrating disk images offline, since its "just one more file" to care about. Officially apps aren't supposed to know where libvirt keeps the managed save files, but I think it is fine for Nova to peek behind the scenes to get them. Alternatively I'd be happy to see an API added to libvirt to allow the managed save files to be uploaded & downloaded via a libvirt virStreamPtr object, in the same way we provide APIs to upload & download disk volumes. This would avoid the need to know explicitly about the file location for the managed save image.Assuming we were using libvirt with the storage pools API could we currently (with existing libvirt) migrate domains that have been suspended with virDomainSave()? Or is the only current option to have nova move the file over using passwordless access?If you used virDomainSave() instead of virDomainManagedSave() then you control the file location, so you could create a directory based storage pool and save the state into that directory, at which point you can use the storag pool APIs to upload/download that data. Regards, Daniel
I will update https://review.openstack.org/#/c/232053 which covers use of libvirt cold migration of non active instances to cover the use of virDomainSave() and thus allow migration of suspended instances. -- Paul Carlton Software Engineer Cloud Services Hewlett Packard BUK03:T242 Longdown Avenue Stoke Gifford Bristol BS34 8QZ Mobile: +44 (0)7768 994283 Email: mailto:paul.carlt...@hpe.com Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".
smime.p7s
Description: S/MIME Cryptographic Signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
