<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&#39;t see it happen that much really. But is there a reason for setting a limit? <br><br></div>I&#39;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">&lt;<a href="mailto:lpeer@redhat.com" target="_blank">lpeer@redhat.com</a>&gt;</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>
&gt; I&#39;d guess a &quot;use case&quot; would be the fact that at different customer<br>
&gt; sites I venture too I meet all kinds of setup.<br>
&gt;<br>
&gt; A very common setup is to split management(usually on a low-profile<br>
&gt; slower network without any fuss about it, just seperate from the core to<br>
&gt; ensure management access.<br>
&gt;<br>
&gt; And then, migrations of VMs and heavier workloads are usually put off<br>
&gt; into the faster core network.<br>
&gt;<br>
&gt;<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>
&gt;<br>
&gt; On Mon, Jan 21, 2013 at 1:18 PM, RK RK &lt;<a href="mailto:kanagaraj.rk@gmail.com">kanagaraj.rk@gmail.com</a><br>
</div><div class="im">&gt; &lt;mailto:<a href="mailto:kanagaraj.rk@gmail.com">kanagaraj.rk@gmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     On Sun, Jan 20, 2013 at 7:59 PM, Simon Grinberg &lt;<a href="mailto:simon@redhat.com">simon@redhat.com</a><br>
</div><div class="im">&gt;     &lt;mailto:<a href="mailto:simon@redhat.com">simon@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;         ----- Original Message -----<br>
&gt;         &gt; From: &quot;Dan Kenigsberg&quot; &lt;<a href="mailto:danken@redhat.com">danken@redhat.com</a><br>
</div><div class="im">&gt;         &lt;mailto:<a href="mailto:danken@redhat.com">danken@redhat.com</a>&gt;&gt;<br>
&gt;         &gt; To: &quot;Simon Grinberg&quot; &lt;<a href="mailto:simon@redhat.com">simon@redhat.com</a><br>
</div><div class="im">&gt;         &lt;mailto:<a href="mailto:simon@redhat.com">simon@redhat.com</a>&gt;&gt;, <a href="mailto:masayag@redhat.com">masayag@redhat.com</a><br>
&gt;         &lt;mailto:<a href="mailto:masayag@redhat.com">masayag@redhat.com</a>&gt;<br>
&gt;         &gt; Cc: &quot;Livnat Peer&quot; &lt;<a href="mailto:lpeer@redhat.com">lpeer@redhat.com</a><br>
</div><div><div class="h5">&gt;         &lt;mailto:<a href="mailto:lpeer@redhat.com">lpeer@redhat.com</a>&gt;&gt;, <a href="mailto:arch@ovirt.org">arch@ovirt.org</a> &lt;mailto:<a href="mailto:arch@ovirt.org">arch@ovirt.org</a>&gt;<br>

&gt;         &gt; Sent: Sunday, January 20, 2013 4:04:52 PM<br>
&gt;         &gt; Subject: Re: feature suggestion: migration network<br>
&gt;         &gt;<br>
&gt;         &gt; On Sun, Jan 13, 2013 at 07:47:59AM -0500, Simon Grinberg wrote:<br>
&gt;         &gt;<br>
&gt;         &gt; &lt;snip&gt;<br>
&gt;         &gt;<br>
&gt;         &gt; &gt; I think for the immediate terms the most compelling is the<br>
&gt;         external<br>
&gt;         &gt; &gt; network provider use case, where you want to allow the external<br>
&gt;         &gt; &gt; network management to rout/shape the traffic per tenant,<br>
&gt;         something<br>
&gt;         &gt; &gt; that will be hard to do if all is aggregated on the host.<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; But coming to think of it, I like more and more the idea of<br>
&gt;         having<br>
&gt;         &gt; &gt; migration network as part of the VM configuration. It&#39;s both<br>
&gt;         &gt; &gt; simple to do now and later add logic on top if required, and<br>
&gt;         VDSM<br>
&gt;         &gt; &gt; supports that already now.<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; So:<br>
&gt;         &gt; &gt; 1. Have a default migration network per cluster (default is the<br>
&gt;         &gt; &gt; management network as before)<br>
&gt;         &gt; &gt; 2. This is the default migration network for all VMs created in<br>
&gt;         &gt; &gt; that cluster<br>
&gt;         &gt; &gt; 3. Allow in VM properties to override this (Tenant use case, and<br>
&gt;         &gt; &gt; supports the external network manager use case)<br>
&gt;         &gt; &gt; 4. Allow from the migration network to override as well.<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; Simple, powerful, flexible, while the logic is not complicated<br>
&gt;         &gt; &gt; since the engine has nothing to decide - everything is<br>
&gt;         &gt; &gt; orchestrated by the admin while initial out of the box setup is<br>
&gt;         &gt; &gt; very simple (one migration network for all which is by<br>
&gt;         default the<br>
&gt;         &gt; &gt; management network).<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; Later you may apply policies on top of this.<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; Thoughts?<br>
&gt;         &gt;<br>
&gt;         &gt; I&#39;m not sure that multiple migration networks is an urgent<br>
&gt;         necessity,<br>
&gt;         &gt; but what you suggest seems simple indeed.<br>
&gt;         &gt;<br>
&gt;         &gt; Simple because each VM has exactly ONE choice for a migration<br>
&gt;         &gt; network.<br>
&gt;         &gt; The multiplicity is for separation, not for automatic<br>
&gt;         redundancy. An<br>
&gt;         &gt; admin may manually split his VMs among migration networks, but no<br>
&gt;         &gt; scheduling logic is required from Engine. If the migration<br>
&gt;         network is<br>
&gt;         &gt; unavailable for some reason, no migration would take place.<br>
&gt;         &gt;<br>
&gt;         &gt; We should design the solution with N networks in mind, and at<br>
&gt;         worse,<br>
&gt;         &gt; if we<br>
&gt;         &gt; feel that the UI is needlessly cluttered we can limit to N=1.<br>
&gt;         &gt;<br>
&gt;         &gt; If there are no objections let&#39;s do it this way:<br>
&gt;         &gt; - add a new network role of migration network.<br>
&gt;         &gt; - add a per-cluster property of defaultMigrationNetwork. Its<br>
&gt;         factory<br>
&gt;         &gt;   default is ovirtmgmt, for backward compatibility.<br>
&gt;         &gt; - add a per-VM propery of migrationNetwork. If Null, the cluster<br>
&gt;         &gt;   defaultMigrationNetwork would be used.<br>
&gt;<br>
&gt;         +1 for the above<br>
&gt;<br>
&gt;         I&#39;ll be happy if we also get the 4th item on my list which I<br>
&gt;         should have phrased<br>
&gt;         &quot;Allow override from the migration dialogue as well, where the<br>
&gt;         default in the drop box is the VM migration network, which in<br>
&gt;         turn defaults to the cluster&#39;s migration network&quot;<br>
&gt;<br>
&gt;<br>
&gt;         &gt;<br>
&gt;         &gt; Dan.<br>
&gt;         &gt;<br>
&gt;         _______________________________________________<br>
&gt;         Arch mailing list<br>
</div></div>&gt;         <a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a> &lt;mailto:<a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>&gt;<br>
<div class="im">&gt;         <a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     +1 for the fourth phrase as it will add more value<br>
&gt;<br>
&gt;     --<br>
&gt;<br>
&gt;     With Regards,<br>
&gt;     RK,<br>
</div>&gt;     <a href="tel:%2B91%209840483044" value="+919840483044">+91 9840483044</a> &lt;tel:%2B91%209840483044&gt;<br>
&gt;<br>
&gt;     _______________________________________________<br>
&gt;     Arch mailing list<br>
&gt;     <a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a> &lt;mailto:<a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>&gt;<br>
<div class="im HOEnZb">&gt;     <a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; /Alexander Rydekull<br>
&gt;<br>
&gt;<br>
</div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; Arch mailing list<br>
&gt; <a href="mailto:Arch@ovirt.org">Arch@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
&gt;<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>/Alexander Rydekull
</div>