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" <[email protected]> >>> To: "Simon Grinberg" <[email protected]>, [email protected] >>> Cc: "Livnat Peer" <[email protected]>, [email protected] >>> 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? > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
