[ovirt-users] live migration with openvswitch

Dan Kenigsberg danken at redhat.com
Thu Sep 15 08:11:17 UTC 2016


On Wed, Sep 14, 2016 at 03:04:14PM +0200, Michal Skrivanek wrote:
> 
> > On 09 Sep 2016, at 13:09, Edward Haas <ehaas at redhat.com> wrote:
> > 
> > 
> > 
> > On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk at 581.spb.su <mailto:lpk at 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.





More information about the Users mailing list