feature suggestion: migration network

[Alexander Rydekull]

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.



On Mon, Jan 21, 2013 at 1:18 PM, RK RK <kanagaraj.rk at gmail.com> wrote:

>
>
> 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
>
> _______________________________________________
> 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/304419bc/attachment.html>