feature suggestion: migration network

[RK RK]

On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <simon at redhat.com> 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"
>
>
> >
> > Dan.
> >
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>



+1 for the fourth phrase as it will add more value

-- 

With Regards,
RK,
+91 9840483044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130121/c2b9c2c0/attachment.html>