<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 1:30 PM, Michal Skrivanek <span dir="ltr"><<a href="mailto:michal.skrivanek@redhat.com" target="_blank">michal.skrivanek@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="HOEnZb"><div class="h5"><br>
> On 15 Sep 2016, at 10:11, Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>> wrote:<br>
><br>
> On Wed, Sep 14, 2016 at 03:04:14PM +0200, Michal Skrivanek wrote:<br>
>><br>
>>> On 09 Sep 2016, at 13:09, Edward Haas <<a href="mailto:ehaas@redhat.com">ehaas@redhat.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <<a href="mailto:lpk@581.spb.su">lpk@581.spb.su</a> <mailto:<a href="mailto:lpk@581.spb.su">lpk@581.spb.su</a>>> wrote:<br>
>>> Hi.<br>
>>><br>
>>> I'm trying to learn Ovirt 4 and have a problem with it.<br>
>>><br>
>>> My cluster consists of 3 nodes. I use Openvswitch for network connectivity. I have a HostedEngine and one additional VM in the cluster.<br>
>>><br>
>>> When I try to migrate the VM to another node, it fails. From vdsm and libvirtd logs I see that proper network interface on destination node cannot be found. Libvirt tries to find Openvswitch bridge with name like "vdsmbr_AOYiPtcT". It exists on source node, but it is unique on every node, because it contains random part. Additionally, it changes on every reboot.<br>
>>><br>
>>> How this is supposed to work?<br>
>>><br>
>>> --<br>
>>> Pavel Levshin<br>
>>><br>
>>><br>
>>><br>
>>> Hi Pavel,<br>
>>><br>
>>> VM migration is supported on the master branch, however it has not been ported to 4.0 yet.<br>
>><br>
>>> You can either build VDSM from source (from master branch) or try to apply this patch on what you have:<br>
>>> <a href="https://gerrit.ovirt.org/#/c/59645" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>59645</a> <<a href="https://gerrit.ovirt.org/#/c/59645" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>59645</a>><br>
>><br>
>> That’s quite a horrible solution right now. I certainly would not like to see it in 4.0 (given the hacks around display).<br></div></div></blockquote><div><br></div><div>What is horrible exactly?<br></div><div>It's not too late to propose other solutions.<br><br></div><div>Display uses libvirt to resolve a network name to an IP address for it to bound to. But that works only for linux bridges.<br></div><div>That is limiting, especially now that we do not have a Linux bridge, but something else.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> Do we have a bug/plan to improve it?<br>
><br>
> We have Bug 1362495 - [OVS] - Add support for live migration<br>
> to track that.<br>
><br>
> I'm afraid that we are not yet ready to backport it to 4.0 - we found<br>
> out that as it is, it break migration for vmfex and external network<br>
> providers; it also breaks when a buggy Engine db does not send a<br>
> displayNetwork. But we plan to fix these issues quite soon.<br>
><br>
> The hacks arround display are an actual imporovement. For "legacy"<br>
> switchType, we maintain an on-host libvirt-side database of all networks<br>
> only to keep libvirt happy. Having a database copy has all the known<br>
> troubles of mismatches and being out of sync. For "ovs" switchType, we<br>
> do not (we don't use a bridge, but a port group so there's no natural<br>
> way to define our network in libvirt). Modifying the listening address<br>
> on destination is the flexible and quick way to do it - I wish we had<br>
> the libvirt migrate hook years ago.<br>
<br>
</div></div>doesn’t it prevent seamless virti-viewer console connection?<br></blockquote><div><br></div><div>The end result is the same, we listen on the address of a specific network.<br></div><div>Previously it contained a network name and libvirt converted it to the correct IP it should bind to, now vdsm resolves it.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
also the “TODO” in the code about multiple graphics is worrying (we fully support it and are considering to make it a default)<br></blockquote><div><br></div><div>Supported where? virt networking code in VDSM which creates an interface for domxml does not support it at the moment.<br></div><div>Or am I missing something?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we have an idea of what API would work well? we should raise or contribute that to libvirt. Surely it takes time but it is the only way how to improve the code eventually.<br></blockquote><div><br></div><div>If using libvirt can allow us to drop some persisted data and logic from vdsm, then it makes sense, but I do not think this is the case.<br></div><div>As it stands today, depending on libvirt persisted data is limiting us, at least in the networking area. I also do not see the advantage of using it as a DB.<br><br></div><div>Thaks,<br></div><div>Edy.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
michal<br>
<br>
</blockquote></div><br></div></div>