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,zWhat 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:[email protected] 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
