[openstack-dev] [nova] live migration in Mitaka
paul.carlton2 at hpe.com
Thu Oct 8 09:37:12 UTC 2015
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.
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
Bristol BS34 8QZ
Mobile: +44 (0)7768 994283
Email: mailto:paul.carlton2 at 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".
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4722 bytes
Desc: S/MIME Cryptographic Signature
More information about the OpenStack-dev