----- Original Message -----
From: "Michal Skrivanek" <mskrivan(a)redhat.com>
To: "Nir Soffer" <nsoffer(a)redhat.com>
Cc: dron(a)redhat.com, "Dan Kenigsberg" <danken(a)redhat.com>, "Maurice
James" <midnightsteel(a)msn.com>, "Ofer Blaut"
<oblaut(a)redhat.com>, "Users(a)ovirt.org Users" <users(a)ovirt.org>
Sent: Thursday, February 27, 2014 10:12:26 AM
Subject: Re: [Users] Disk Migration
On Feb 27, 2014, at 08:15 , Nir Soffer <nsoffer(a)redhat.com> wrote:
> ----- Original Message -----
>> From: "Dafna Ron" <dron(a)redhat.com>
>> To: "Maurice James" <midnightsteel(a)msn.com>
>> Cc: "Ofer Blaut" <oblaut(a)redhat.com>, users(a)ovirt.org
>> Sent: Wednesday, February 26, 2014 7:34:11 PM
>> Subject: Re: [Users] Disk Migration
>>
>> On 02/26/2014 05:24 PM, Maurice James wrote:
>>> I have a specific interface set up for migrations. Why do disk
>>> migrations not use the interface that I have set for migrations? Is
>>> that by design? Shouldnt it use the interfaces that I have set aside
>>> for migrations? VM migrations work as they should but not disk migrations
>>
>> I don't think that you can configure interface for disk migration.
>> Disk migration is actually copy of information from the original disk to
>> a new disk created on a new domain + delete of the original disk once
>> that is done.
>> it's not actually a migration and so I am not sure you can actually
>> configure an interface for that.
>> adding ofer - perhpas he has a solution or it's possible and I am not
>> aware of it.
>
> I guess that *not* using the migration network for storage operation is
> the expected behavior, to make migration faster and safer.
>
> Michal, Dan, can you elaborate on this?
with storage offloading it's probably not going to be significant, however
today it likely is.
Nir, why would not using migration network make it better? Won't we have the
same problem as before without migration network at all, i.e. choking the
management channel?
Gigs of data sent of the same netowrk used for migarations would make migration
slower when the network is saturated.
Should we maybe consider a dedicated "storage" network?
This can be setup now in 3.4.
Sergey, can you explain how this is configured now in 3.4?