[Users] Disk Migration

[Michal Skrivanek]

On 28 Feb 2014, at 15:27, Nir Soffer wrote:

> ----- Original Message -----
>> From: "Michal Skrivanek" <mskrivan at redhat.com>
>> To: "Nir Soffer" <nsoffer at redhat.com>
>> Cc: dron at redhat.com, "Dan Kenigsberg" <danken at redhat.com>, "Maurice James" <midnightsteel at msn.com>, "Ofer Blaut"
>> <oblaut at redhat.com>, "Users at ovirt.org Users" <users at 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 at redhat.com> wrote:
>> 
>>> ----- Original Message -----
>>>> From: "Dafna Ron" <dron at redhat.com>
>>>> To: "Maurice James" <midnightsteel at msn.com>
>>>> Cc: "Ofer Blaut" <oblaut at redhat.com>, users at 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.

well, you saturate one or the other…still from the functional perspective it's better to not choke the management…so either use the migration network (and the migrations will compete with disk moves) or a separate network.
I'd be tempted to say that typically having too many different networks might be an overkill and difficult to set up/maintain

> 
>> 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?