feature suggestion: migration network
Alexander Rydekull
rydekull at gmail.com
Mon Jan 21 16:17:37 UTC 2013
Yes, I was, sorry if that wasnt clear. The only use case for having
additional, that I could see right now for that. Is...
Someone have two different clusters and want to migrate inbetween them, and
temporarily connect them up.
Well, i don't see it happen that much really. But is there a reason for
setting a limit?
I'll ponder the subject some more to see if I can find more use cases.
On Mon, Jan 21, 2013 at 2:56 PM, Livnat Peer <lpeer at redhat.com> wrote:
> 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 <kanagaraj.rk at gmail.com
> > <mailto:kanagaraj.rk at gmail.com>> wrote:
> >
> >
> >
> > On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <simon at redhat.com
> > <mailto:simon at redhat.com>> wrote:
> >
> >
> >
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com
> > <mailto:danken at redhat.com>>
> > > To: "Simon Grinberg" <simon at redhat.com
> > <mailto:simon at redhat.com>>, masayag at redhat.com
> > <mailto:masayag at redhat.com>
> > > Cc: "Livnat Peer" <lpeer at redhat.com
> > <mailto:lpeer at redhat.com>>, arch at ovirt.org <mailto:
> 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 <mailto: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 <tel:%2B91%209840483044>
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org <mailto:Arch at ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> >
> >
> >
> > --
> > /Alexander Rydekull
> >
> >
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
>
>
--
/Alexander Rydekull
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20130121/078ad8f1/attachment.html>
More information about the Arch
mailing list