Re: [ovirt-users] live migration with openvswitch
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> 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.