feature suggestion: migration network

[Livnat Peer]

On 01/21/2013 12:58 PM, Dan Kenigsberg wrote:
> On Sun, Jan 20, 2013 at 09:29:43AM -0500, Simon Grinberg wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>> To: "Simon Grinberg" <simon at redhat.com>, masayag at redhat.com
>>> Cc: "Livnat Peer" <lpeer at redhat.com>, arch at ovirt.org
>>> Sent: Sunday, January 20, 2013 4:04:52 PM
>>> Subject: Re: feature suggestion: migration network
>>>
>>> On Sun, Jan 13, 2013 at 07:47:59AM -0500, Simon Grinberg wrote:
>>>
>>> <snip>
>>>
>>>> I think for the immediate terms the most compelling is the external
>>>> network provider use case, where you want to allow the external
>>>> network management to rout/shape the traffic per tenant, something
>>>> that will be hard to do if all is aggregated on the host.
>>>>  
>>>> But coming to think of it, I like more and more the idea of having
>>>> migration network as part of the VM configuration. It's both
>>>> simple to do now and later add logic on top if required, and VDSM
>>>> supports that already now.
>>>>
>>>> So:
>>>> 1. Have a default migration network per cluster (default is the
>>>> management network as before)
>>>> 2. This is the default migration network for all VMs created in
>>>> that cluster
>>>> 3. Allow in VM properties to override this (Tenant use case, and
>>>> supports the external network manager use case)
>>>> 4. Allow from the migration network to override as well.
>>>>
>>>> Simple, powerful, flexible, while the logic is not complicated
>>>> since the engine has nothing to decide - everything is
>>>> orchestrated by the admin while initial out of the box setup is
>>>> very simple (one migration network for all which is by default the
>>>> management network).
>>>>
>>>> Later you may apply policies on top of this.
>>>>
>>>> Thoughts?
>>>
>>> I'm not sure that multiple migration networks is an urgent necessity,
>>> but what you suggest seems simple indeed.
>>>
>>> Simple because each VM has exactly ONE choice for a migration
>>> network.
>>> The multiplicity is for separation, not for automatic redundancy. An
>>> admin may manually split his VMs among migration networks, but no
>>> scheduling logic is required from Engine. If the migration network is
>>> unavailable for some reason, no migration would take place.
>>>
>>> We should design the solution with N networks in mind, and at worse,
>>> if we
>>> feel that the UI is needlessly cluttered we can limit to N=1.
>>>
>>> If there are no objections let's do it this way:
>>> - add a new network role of migration network.
>>> - add a per-cluster property of defaultMigrationNetwork. Its factory
>>>   default is ovirtmgmt, for backward compatibility.
>>> - add a per-VM propery of migrationNetwork. If Null, the cluster
>>>   defaultMigrationNetwork would be used.
>>
>> +1 for the above
>>
>> I'll be happy if we also get the 4th item on my list which I should have phrased 
>> "Allow override from the migration dialogue as well, where the default in the drop box is the VM migration network, which in turn defaults to the cluster's migration network"
> 
> I am so sorry that I have to retract my own words. I do not see a use
> case for the migration networks that are not the
> defaultMigrationNetwork. They are not used anywhere. I wish I wrote down
> the following notes
> 
> First phase:
> - add a new network role of migration network. Each cluster has one, and
>   it is the default migration network for VMs on the cluster. Factory
>   default is that ovirtmgmt is the cluster migration network.
> 

+1, I think for first phase this is a simple and a quick win.
Nothing here seems to contradict the second phase.

> Second phase:
> - add a per-VM propery of migrationNetwork. If Null, the cluster
>   migrationNetwork would be used.
> 
> - let the user override the VM migration network in the migrate API and
>   in the GUI.
> 

Before implementing the second phase I would like to define better the
scheduling implications of the above (scheduling a VM, moving host to
maintenance etc.).
Personally I would wait for a concrete 'user' request for this.
I think the examples you gave above which are tenant related are
interesting but we don't have tenants in oVirt yet.
Until we have a use case we can utilize this API change for I would not
change the migration (engine-VDSM) API.


> Does this make sense to you, Simon?
>