Re: [ovirt-users] live migration with openvswitch

On 15 Sep 2016, at 10:11, Dan Kenigsberg <danken(a)redhat.com&gt; wrote: On Wed, Sep 14, 2016 at 03:04:14PM +0200, Michal Skrivanek wrote: > >> On 09 Sep 2016, at 13:09, Edward Haas <ehaas(a)redhat.com&gt; wrote: >> >> >> >> On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk(a)581.spb.su <mailto:lpk@581.spb.su>> wrote: >> Hi. >> >> I'm trying to learn Ovirt 4 and have a problem with it. >> >> My cluster consists of 3 nodes. I use Openvswitch for network connectivity. I have a HostedEngine and one additional VM in the cluster. >> >> 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. >> >> How this is supposed to work? >> >> -- >> Pavel Levshin >> >> >> >> Hi Pavel, >> >> VM migration is supported on the master branch, however it has not been ported to 4.0 yet. > >> You can either build VDSM from source (from master branch) or try to apply this patch on what you have: >> https://gerrit.ovirt.org/#/c/59645 <https://gerrit.ovirt.org/#/c/59645> > > That’s quite a horrible solution right now. I certainly would not like to see it in 4.0 (given the hacks around display). > Do we have a bug/plan to improve it? We have Bug 1362495 - [OVS] - Add support for live migration to track that. I'm afraid that we are not yet ready to backport it to 4.0 - we found out that as it is, it break migration for vmfex and external network providers; it also breaks when a buggy Engine db does not send a displayNetwork. But we plan to fix these issues quite soon. The hacks arround display are an actual imporovement. For "legacy" switchType, we maintain an on-host libvirt-side database of all networks only to keep libvirt happy. Having a database copy has all the known troubles of mismatches and being out of sync. For "ovs" switchType, we do not (we don't use a bridge, but a port group so there's no natural way to define our network in libvirt). Modifying the listening address on destination is the flexible and quick way to do it - I wish we had the libvirt migrate hook years ago.