Bug 971395 - RFE: The ability to specify source address when migrating VMs
RFE: The ability to specify source address when migrating VMs
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.6
Unspecified Unspecified
low Severity low
: rc
: ---
Assigned To: Vlad Yasevich
Virtualization Bugs
network
: FutureFeature
Depends On:
Blocks: 971394
  Show dependency treegraph
 
Reported: 2013-06-06 08:21 EDT by Assaf Muller
Modified: 2013-07-11 17:20 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 971394
Environment:
Last Closed: 2013-07-11 17:20:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Assaf Muller 2013-06-06 08:21:24 EDT
+++ This bug was initially created as a clone of Bug #969054 +++

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:

--- Additional comment from Assaf Muller on 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.

--- Additional comment from Dan Kenigsberg on 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 2 Vlad Yasevich 2013-06-07 18:27:38 EDT
If the migration and ovrtmgmt networks are two distinct networks with 2 distinct subnets that the source address selection during migration will be depend on the address in the migration URI.  If the destination address is on the ovrtmgmt
network that network will be used.  In case of DNS where both addresses are
in DNS under the same name, you might see some round-robin effect as DNS by default will switch the order of returned addresses (you can see that using 'dig' tool).

As Daniel said in BZ 971394, this should be achieved with proper route table configuration.
Comment 3 Ronen Hod 2013-06-12 14:25:59 EDT
The natural way to control the routing of packets to a certain destination is by making changes to the routing tables.
I am not sure that I understand the use case and the problem.
Anyhow. Can you have two destination addresses (migration & mgt), and set up the routing tables on the source (and dst) such that every one of these destination addresses is routed through a different source NICs (subnet).
Let's look for a standard configuration based solution, and avoid writing specific code.
Comment 4 Vlad Yasevich 2013-07-11 17:20:15 EDT
The libvirt related bug is closed.  The proper way to solve this is through routing policy table.  Closing the bug.

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