feature suggestion: migration network

[Livnat Peer]

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
>