Bug 969054 - Cannot use migration network on a source host with multiple NICs
Cannot use migration network on a source host with multiple NICs
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.3.0
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Assaf Muller
network
:
Depends On: 971394
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-30 10:47 EDT by Assaf Muller
Modified: 2016-02-10 14:53 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 971394 (view as bug list)
Environment:
Last Closed: 2013-07-14 10:49:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Assaf Muller 2013-05-30 10:47:45 EDT
Description of problem:
When migrating a VM and opting to use the new migration network, if the source host has multiple NICs and the destination host is on a different subnet, then the socket will be created with a random source address / NIC. The source host will see that the destination host is on a different subnet and forward towards the default gateway. If the host has multiple gateways, we wish to specify the source address to that of the migration network, so the correct NIC will be chosen.

If the hosts are on the same subnet there is no issue.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Setup 2 hosts on different subnets
2. Configure the source host with 2 NICs
3. One NIC with ovirtmgmt, connected to 1 gateway
4. Second NIC with migration network, connected to a different gateway
5. Migrate the VM

Actual results:
The migration will occur over either the migration network, or the ovirtmgmt network. The network used is random.

Expected results:
The migration network should always be used.

Additional info:
Comment 1 Assaf Muller 2013-06-02 03:15:04 EDT
Proposed Solution:
We need the ability to specify the source address when setting up the migration socket. Currently QEMU and Libvirt don't support this feature.
Comment 3 Dan Kenigsberg 2013-06-04 08:10:16 EDT
The cleanest implementation for this issue requires some work on upstream qemu and libvirt, as qemu does expose the ability to set the source address of migration traffic (from qmp-commands.hx):

 migrate
 -------

 Migrate to URI.

 Arguments:

 - "blk": block migration, full disk copy (json-bool, optional)
 - "inc": incremental disk copy (json-bool, optional)
 - "uri": Destination URI (json-string)


Another alternative would be to set a special destination routing before migration starts. I believe that this alternative would prove fragile, and that it should not be taken before we see a proven need for cross-subnet migration.
Comment 4 Assaf Muller 2013-07-14 10:49:28 EDT
Closed:
The recommended configuration is to perform migrations between hosts on layer 2. Migration between hosts that are on different subnets doesn't perform so well. Therefor, it is assumed that the migration network is present on all hosts in the cluster.

This makes this bug not a bug. Even if both hosts have multiple NICs, since it is assumed that they're on the same subnet, then both hosts have the migration network and are connected via layer 2. The source host will get the destination IP address of the destination host from the engine, and the source IP will be chosen automatically to be the local interface that's in the migration network.

Note You need to log in before you can comment on or make changes to this bug.