<div dir="ltr"><div><div>I'd guess a "use case" would be the fact that at different customer sites I venture too I meet all kinds of setup.<br><br>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.<br>
<br></div>And then, migrations of VMs and heavier workloads are usually put off into the faster core network.<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 1:18 PM, RK RK <span dir="ltr"><<a href="mailto:kanagaraj.rk@gmail.com" target="_blank">kanagaraj.rk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <span dir="ltr"><<a href="mailto:simon@redhat.com" target="_blank">simon@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
----- Original Message -----<br>
> From: "Dan Kenigsberg" <<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>><br>
> To: "Simon Grinberg" <<a href="mailto:simon@redhat.com" target="_blank">simon@redhat.com</a>>, <a href="mailto:masayag@redhat.com" target="_blank">masayag@redhat.com</a><br>
> Cc: "Livnat Peer" <<a href="mailto:lpeer@redhat.com" target="_blank">lpeer@redhat.com</a>>, <a href="mailto:arch@ovirt.org" target="_blank">arch@ovirt.org</a><br>
> Sent: Sunday, January 20, 2013 4:04:52 PM<br>
> Subject: Re: feature suggestion: migration network<br>
><br>
> On Sun, Jan 13, 2013 at 07:47:59AM -0500, Simon Grinberg wrote:<br>
><br>
> <snip><br>
><br>
> > I think for the immediate terms the most compelling is the external<br>
> > network provider use case, where you want to allow the external<br>
> > network management to rout/shape the traffic per tenant, something<br>
> > that will be hard to do if all is aggregated on the host.<br>
> ><br>
> > But coming to think of it, I like more and more the idea of having<br>
> > migration network as part of the VM configuration. It's both<br>
> > simple to do now and later add logic on top if required, and VDSM<br>
> > supports that already now.<br>
> ><br>
> > So:<br>
> > 1. Have a default migration network per cluster (default is the<br>
> > management network as before)<br>
> > 2. This is the default migration network for all VMs created in<br>
> > that cluster<br>
> > 3. Allow in VM properties to override this (Tenant use case, and<br>
> > supports the external network manager use case)<br>
> > 4. Allow from the migration network to override as well.<br>
> ><br>
> > Simple, powerful, flexible, while the logic is not complicated<br>
> > since the engine has nothing to decide - everything is<br>
> > orchestrated by the admin while initial out of the box setup is<br>
> > very simple (one migration network for all which is by default the<br>
> > management network).<br>
> ><br>
> > Later you may apply policies on top of this.<br>
> ><br>
> > Thoughts?<br>
><br>
> I'm not sure that multiple migration networks is an urgent necessity,<br>
> but what you suggest seems simple indeed.<br>
><br>
> Simple because each VM has exactly ONE choice for a migration<br>
> network.<br>
> The multiplicity is for separation, not for automatic redundancy. An<br>
> admin may manually split his VMs among migration networks, but no<br>
> scheduling logic is required from Engine. If the migration network is<br>
> unavailable for some reason, no migration would take place.<br>
><br>
> We should design the solution with N networks in mind, and at worse,<br>
> if we<br>
> feel that the UI is needlessly cluttered we can limit to N=1.<br>
><br>
> If there are no objections let's do it this way:<br>
> - add a new network role of migration network.<br>
> - add a per-cluster property of defaultMigrationNetwork. Its factory<br>
> default is ovirtmgmt, for backward compatibility.<br>
> - add a per-VM propery of migrationNetwork. If Null, the cluster<br>
> defaultMigrationNetwork would be used.<br>
<br>
+1 for the above<br>
<br>
I'll be happy if we also get the 4th item on my list which I should have phrased<br>
"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"<br>
<br>
<br>
><br>
> Dan.<br>
><br>
_______________________________________________<br>
Arch mailing list<br>
<a href="mailto:Arch@ovirt.org" target="_blank">Arch@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
</blockquote></div><br><br><br></div></div>+1 for the fourth phrase as it will add more value<span class="HOEnZb"><font color="#888888"><br clear="all"><br>-- <br><br>With Regards,<br>RK,<br><a href="tel:%2B91%209840483044" value="+919840483044" target="_blank">+91 9840483044</a><br>
</font></span><br>_______________________________________________<br>
Arch mailing list<br>
<a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>/Alexander Rydekull
</div>