On Thu, Feb 27, 2014 at 09:12:26AM +0100, Michal Skrivanek wrote:
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?
Should we maybe consider a dedicated "storage" network?
As far as I understand Nir, you are saying the same thing: it's better
to separate management, migration, and storage to separate networks, so
that one does not choke the other.
When we get host network QoS done (hopefully ovirt-3.5) we can do this
quite cheaply, over vlans.
Dan.