On 01/21/2013 02:26 PM, Alexander Rydekull wrote: > I'd guess a "use case" would be the fact that at different customer > sites I venture too I meet all kinds of setup. > > A very common setup is to split management(usually on a low-profile > slower network without any fuss about it, just seperate from the core to > ensure management access. > > And then, migrations of VMs and heavier workloads are usually put off > into the faster core network. > >
I think you are describing a use case for separating the migration network from the management network. I see a reason for providing that, for example the use case you described above. I am curious if there is a use case to have more than one migration network in a Cluser. Livnat > > On Mon, Jan 21, 2013 at 1:18 PM, RK RK <[email protected] > <mailto:[email protected]>> wrote: > > > > On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <[email protected] > <mailto:[email protected]>> wrote: > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected] > <mailto:[email protected]>> > > To: "Simon Grinberg" <[email protected] > <mailto:[email protected]>>, [email protected] > <mailto:[email protected]> > > Cc: "Livnat Peer" <[email protected] > <mailto:[email protected]>>, [email protected] <mailto:[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] <mailto:[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 <tel:%2B91%209840483044> > > _______________________________________________ > Arch mailing list > [email protected] <mailto:[email protected]> > http://lists.ovirt.org/mailman/listinfo/arch > > > > > -- > /Alexander Rydekull > > > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
