[openstack-dev] [Quantum] VM live migration with respect to nova-quantum interaction
Irena Berezovsky
irenab at mellanox.com
Wed Jul 25 08:54:46 UTC 2012
Hi,
I am using Quantum not in scope of the OpenStack, but as a standalone service and provide 'nova like' orchestration (using QuntumClient).
I would like to raise several concerns regarding VM live migration flow from Quantum perspective.
My assumption was that Cloud Controller using Compute Service on source and destination Hosts will do the following:
Destination Host - pre migrate: call Quantum for new port creation and association to VM device
Source Host - post migrate: call Quantum for old port removal.
But I see that my assumption was wrong. Nova does not create new port in Quantum, the same port is used.
Is there any special reason why same port is used? I feel it quite conceptual decision what port should represent.
Current flow between Nova and Quantum seems to be like following:
Destination Host get VM network information from Quantum and configures the Host.
Source Host removes VM network configuration.
Quantum Agents do the provisioning part and update port state.
Looking at the open source plugins implementation (Linux Bridge), seems that there is possible bug that port status will be eventually set to DOWN in case source Host agent will run after destination Host Agent already set the port state to UP.
If other port is used for destination, there is no problem. Currently it is not possible in quantum to create second port for the VM, since there is a check for MAC uniqueness.
Maybe the other possible solution can be to use port update with status 'migrating' then it may possibly ignore DOWN update, if done by source Host.
Will appreciate any input regarding then live migration nova-quantum flow regarding both design and implementation.
My intention is mimic the nova flow in order to be aligned with general Quantum development.
Regards,
Irena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120725/a1e74e2c/attachment.html>
More information about the OpenStack-dev
mailing list