<div dir="ltr"><div><div><div>Yes, I was, sorry if that wasnt clear. The only use case for having additional, that I could see right now for that. Is...<br><br></div>Someone have two different clusters and want to migrate inbetween them, and temporarily connect them up.<br>
</div>Well, i don't see it happen that much really. But is there a reason for setting a limit? <br><br></div>I'll ponder the subject some more to see if I can find more use cases.<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 2:56 PM, Livnat Peer <span dir="ltr"><<a href="mailto:lpeer@redhat.com" target="_blank">lpeer@redhat.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="im">On 01/21/2013 02:26 PM, Alexander Rydekull wrote:<br>
> I'd guess a "use case" would be the fact that at different customer<br>
> 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<br>
> slower network without any fuss about it, just seperate from the core to<br>
> ensure management access.<br>
><br>
> And then, migrations of VMs and heavier workloads are usually put off<br>
> into the faster core network.<br>
><br>
><br>
<br>
</div>I think you are describing a use case for separating the migration<br>
network from the management network.<br>
I see a reason for providing that, for example the use case you<br>
described above.<br>
I am curious if there is a use case to have more than one migration<br>
network in a Cluser.<br>
<br>
Livnat<br>
<div class="im"><br>
<br>
<br>
><br>
> On Mon, Jan 21, 2013 at 1:18 PM, RK RK <<a href="mailto:kanagaraj.rk@gmail.com">kanagaraj.rk@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:kanagaraj.rk@gmail.com">kanagaraj.rk@gmail.com</a>>> wrote:<br>
><br>
><br>
><br>
> On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg <<a href="mailto:simon@redhat.com">simon@redhat.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:simon@redhat.com">simon@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Dan Kenigsberg" <<a href="mailto:danken@redhat.com">danken@redhat.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:danken@redhat.com">danken@redhat.com</a>>><br>
> > To: "Simon Grinberg" <<a href="mailto:simon@redhat.com">simon@redhat.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:simon@redhat.com">simon@redhat.com</a>>>, <a href="mailto:masayag@redhat.com">masayag@redhat.com</a><br>
> <mailto:<a href="mailto:masayag@redhat.com">masayag@redhat.com</a>><br>
> > Cc: "Livnat Peer" <<a href="mailto:lpeer@redhat.com">lpeer@redhat.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:lpeer@redhat.com">lpeer@redhat.com</a>>>, <a href="mailto:arch@ovirt.org">arch@ovirt.org</a> <mailto:<a href="mailto:arch@ovirt.org">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<br>
> external<br>
> > > network provider use case, where you want to allow the external<br>
> > > network management to rout/shape the traffic per tenant,<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> redundancy. An<br>
> > admin may manually split his VMs among migration networks, but no<br>
> > scheduling logic is required from Engine. If the migration<br>
> 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<br>
> 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<br>
> 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<br>
> should have phrased<br>
> "Allow override from the migration dialogue as well, where the<br>
> default in the drop box is the VM migration network, which in<br>
> turn defaults to the cluster's migration network"<br>
><br>
><br>
> ><br>
> > Dan.<br>
> ><br>
> _______________________________________________<br>
> Arch mailing list<br>
</div></div>> <a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a> <mailto:<a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>><br>
<div class="im">> <a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
><br>
><br>
><br>
><br>
> +1 for the fourth phrase as it will add more value<br>
><br>
> --<br>
><br>
> With Regards,<br>
> RK,<br>
</div>> <a href="tel:%2B91%209840483044" value="+919840483044">+91 9840483044</a> <tel:%2B91%209840483044><br>
><br>
> _______________________________________________<br>
> Arch mailing list<br>
> <a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a> <mailto:<a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>><br>
<div class="im HOEnZb">> <a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
><br>
><br>
><br>
><br>
> --<br>
> /Alexander Rydekull<br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>/Alexander Rydekull
</div>