On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <[email protected]> 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" > > > > > > Dan. > > > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > +1 for the fourth phrase as it will add more value -- With Regards, RK, +91 9840483044
_______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
