Re: [Users] Disk Migration
On 28 Feb 2014, at 15:27, Nir Soffer wrote:
----- 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.
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?