← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1614063] Re: live migration doesn't use the correct interface to transfer the data

 

Confirmed that it is a bug. Libvirt correctly uses
live_migration_inbound_addr, but QEMU still defaults to the hostname of
the other side instead of provided IP address.

** Changed in: nova
       Status: Invalid => Confirmed

** Changed in: nova
   Importance: Undecided => Medium

** Tags added: live-migration

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1614063

Title:
  live migration doesn't use the correct interface to transfer the data

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  My compute nodes are attached to several networks (storage, admin,
  etc). For each network I have a real or a virtual interface with an IP
  assigned. The DNS is properly configured, so I can `ping node1`, or
  `ping storage.node1`, and is resolving to the correct IP.

  I want to use the second network to transfer the data so:

  * Setup libvirtd to listen into the correct interface (checked with
  netstat)

  * Configure nova.conf live_migration_uri

  * Monitor interfaces and do nova live-migration

  The migration works correctly, is doing what I think is a PEER2PEER
  migration type, but the data is transfered via the normal interface.

  I can replicate it doing a live migration via virsh.

  After more checks I discover that if I do not use the --migrate-uri
  parameter, libvirt will ask to the other node the hostname to build
  this migrage_uri parameter. The hostname resolve via the slow
  interface.

  Using the --migrate-uri and the --listen-address (for the -incoming
  parameter) works at libvirt level. So we need somehow inject this
  paramer in migrateToURIx in the libvirt nova driver.

  I have a patch (attached - WIP) that address this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1614063/+subscriptions


References