Open Stack

I'd be happy to take this on in Mitaka

On 07/10/15 10:14, Daniel P. Berrange wrote:
> On Tue, Oct 06, 2015 at 11:43:52AM -0600, Chris Friesen wrote:
>> On 10/06/2015 11:27 AM, Paul Carlton wrote:
>>>
>>> On 06/10/15 17:30, Chris Friesen wrote:
>>>> On 10/06/2015 08:11 AM, Daniel P. Berrange wrote:
>>>>> On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote:
>>>>>> https://review.openstack.org/#/c/85048/ was raised to address the
>>>>>> migration of instances that are not running but people did not warm to
>>>>>> the idea of bringing a stopped/suspended instance to a paused state to
>>>>>> migrate it.  Is there any work in progress to get libvirt enhanced to
>>>>>> perform the migration of non active virtual machines?
>>>>> Libvirt can "migrate" the configuration of an inactive VM, but does
>>>>> not plan todo anything related to storage migration. OpenStack could
>>>>> already solve this itself by using libvirt storage pool APIs to
>>>>> copy storage volumes across, but the storage pool worked in Nova
>>>>> is stalled
>>>>>
>>>>> https://review.openstack.org/#/q/status:abandoned+project:openstack/nova+branch:master+topic:bp/use-libvirt-storage-pools,n,z
>>>>>
>>>> What is the libvirt API to migrate a paused/suspended VM? Currently nova uses
>>>> dom.managedSave(), so it doesn't know what file libvirt used to save the
>>>> state.  Can libvirt migrate that file transparently?
>>>>
>>>> I had thought we might switch to virDomainSave() and then use the cold
>>>> migration framework, but that requires passwordless ssh.  If there's a way to
>>>> get libvirt to handle it internally via the storage pool API then that would
>>>> be better.
>>
>>> So my reading of this is the issue could be addressed in Mitaka by
>>> implementing
>>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-libvirt-storage-pools.html
>>>
>>> and
>>> https://review.openstack.org/#/c/126979/4/specs/kilo/approved/migrate-libvirt-volumes.rst
>>>
>>>
>>> is there any prospect of this being progressed?
>> Paul, that would avoid the need for cold migrations to use passwordless ssh
>> between nodes.  However, I think there may be additional work to handle
>> migrating paused/suspended instances--still waiting for Daniel to address
>> that bit.
> Migrating paused VMs should "just work" - certainly at the libvirt/QEMU
> level there's no distinction between a paused & running VM wrt migration.
> I know that historically Nova has blocked migration if the VM is paused
> and I recall patches to remove that pointless restriction. I can't
> remember if they ever merged.
>
> 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.
>
> Regards,
> Daniel

-- 
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.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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4722 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/41b2b0ce/attachment-0001.bin>