On 16 Sep 2016, at 14:36, Michal Skrivanek = <michal.skrivanek@redhat.com> wrote: =20 =20
On 15 Sep 2016, at 21:46, Edward Haas <ehaas@redhat.com = <mailto:ehaas@redhat.com>> wrote: =20 =20 =20 On Thu, Sep 15, 2016 at 1:30 PM, Michal Skrivanek = <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> = wrote: =20
On 15 Sep 2016, at 10:11, Dan Kenigsberg <danken@redhat.com = <mailto:danken@redhat.com>> wrote:
On Wed, Sep 14, 2016 at 03:04:14PM +0200, Michal Skrivanek wrote:
On 09 Sep 2016, at 13:09, Edward Haas <ehaas@redhat.com =
<mailto:ehaas@redhat.com>> wrote:
On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk@581.spb.su =
<mailto:lpk@581.spb.su> <mailto:lpk@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. =46rom = 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> <https://gerrit.ovirt.org/#/c/59645 = <https://gerrit.ovirt.org/#/c/59645>>
That=E2=80=99s quite a horrible solution right now. I certainly = would not like to see it in 4.0 (given the hacks around display). =20 What is horrible exactly? It's not too late to propose other solutions. =20 if OVS is the next great feature it should fit into the code = accordingly. I.e. using hooks only when it=E2=80=99s absolutely = necessary and as a temporary measure only until the respective proper = RFEs are implemented and available. E.g. when there is a libvirt support = missing we can add a qemu command line parameter ourselves bypassing =
--Apple-Mail=_11E505BE-B750-42AD-BBAB-F0AA4EA225FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 libvirt but we always should have a clear plan (i.e. a bug) to move away = from there as soon as the support is there(requested back then when we = went with the hack)
=20 Display uses libvirt to resolve a network name to an IP address for = it to bound to. But that works only for linux bridges. That is limiting, especially now that we do not have a Linux bridge, = but something else. =20
=20 Such things should be reviewed as soon as we get to a similar area, so = while modifying libvirt-hook.sh we can see the original reason for the = hook is not valid anymore as everything is addressed and the hacky code = should have been removed It was easy to see that because there is a clear comment about = dependent bugs and issues (though missed by all the reviewers, = unfortunately!) Your new code doesn=E2=80=99t have anything like that and I have no = idea what kind of API or behavior we actually need, whether appropriate = requests has been filed on e.g. libvirt. That makes it very hard to = revisit in the future by the next random person. =20 that=E2=80=99s ok, whatever needs to be done. But then please make = sure you=E2=80=99re not breaking existing features, at least again not = without a plan(=3D=3Dbug) to fix it. =20
=20
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. =20 which =E2=80=9Cbuggy=E2=80=9D engine? There were changes in =
Again it=E2=80=99s ok as long as it is clearly mentioned like "3.6 = engine sends it in such and such parameter, we can drop it once we = support 4.0+" =20
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. =20 doesn=E2=80=99t it prevent seamless virti-viewer console connection? =20 The end result is the same, we listen on the address of a specific = network. Previously it contained a network name and libvirt converted it to =
=20 so did we request libvirt to be able to do that itself or requested an = API to do that cleanly without mangling xml on the fly? =20
=20 also the =E2=80=9CTODO=E2=80=9D in the code about multiple graphics = is worrying (we fully support it and are considering to make it a = default) =20 Supported where? virt networking code in VDSM which creates an = interface for domxml does not support it at the moment. Or am I missing something? =20 supported in oVirt. Multiple graphics VM is a regular oVirt feature. = The hook doesn=E2=80=99t handle it correctly hence I suppose the = migration would not really work correctly for these VMs. Again, that might be ok temporarily with a clear documentation and a =
=20
=20 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. =20 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. 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. =20 I=E2=80=99m not saying you should depend on libvirt data. But you = should let libvirt community know if it is a useless feature, use a = clean way how not to use that feature(if it gets in your way), ideally = discuss and propose how such a feature can be improved so oVirt and all = other virtualization projects can benefit from that. If it=E2=80=99s a =
oh, and yes, that=E2=80=99s exactly the tracking I wanted to make sure = exists. There=E2=80=99s just no link in the gerrit commit itself so I = didn=E2=80=99t find it (but I wasn=E2=80=99t really looking hard = either;-) Thanks, michal parameters, most of these issues are not relevant anymore since we = ditched <3.6 though. the correct IP it should bind to, now vdsm resolves it. plan to fix it. truly useless feature I=E2=80=99m sure libvirt would be happy to drop = maintaining it
=20 Thanks, michal =20
=20 Thaks, Edy. =20 =20 Thanks, michal =20 =20 _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users =20
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--Apple-Mail=_11E505BE-B750-42AD-BBAB-F0AA4EA225FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 16 Sep 2016, at 14:36, Michal Skrivanek <<a = href=3D"mailto:michal.skrivanek@redhat.com" = class=3D"">michal.skrivanek@redhat.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><meta = http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" = class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space;" class=3D""><br = class=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 15 Sep 2016, at 21:46, Edward Haas <<a = href=3D"mailto:ehaas@redhat.com" class=3D"">ehaas@redhat.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><br class=3D""><div class=3D"gmail_extra"><br = class=3D""><div class=3D"gmail_quote">On Thu, Sep 15, 2016 at 1:30 PM, = Michal Skrivanek <span dir=3D"ltr" class=3D""><<a = href=3D"mailto:michal.skrivanek@redhat.com" target=3D"_blank" = class=3D"">michal.skrivanek@redhat.com</a>></span> wrote:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = class=3D"HOEnZb"><div class=3D"h5"><br class=3D""> > On 15 Sep 2016, at 10:11, Dan Kenigsberg <<a = href=3D"mailto:danken@redhat.com" class=3D"">danken@redhat.com</a>> = wrote:<br class=3D""> ><br class=3D""> > On Wed, Sep 14, 2016 at 03:04:14PM +0200, Michal Skrivanek = wrote:<br class=3D""> >><br class=3D""> >>> On 09 Sep 2016, at 13:09, Edward Haas <<a = href=3D"mailto:ehaas@redhat.com" class=3D"">ehaas@redhat.com</a>> = wrote:<br class=3D""> >>><br class=3D""> >>><br class=3D""> >>><br class=3D""> >>> On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <<a = href=3D"mailto:lpk@581.spb.su" class=3D"">lpk@581.spb.su</a> = <mailto:<a href=3D"mailto:lpk@581.spb.su" = class=3D"">lpk@581.spb.su</a>>> wrote:<br class=3D""> >>> Hi.<br class=3D""> >>><br class=3D""> >>> I'm trying to learn Ovirt 4 and have a problem with it.<br = class=3D""> >>><br class=3D""> >>> My cluster consists of 3 nodes. I use Openvswitch for = network connectivity. I have a HostedEngine and one additional VM in the = cluster.<br class=3D""> >>><br class=3D""> >>> When I try to migrate the VM to another node, it fails. = =46rom 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 class=3D""> >>><br class=3D""> >>> How this is supposed to work?<br class=3D""> >>><br class=3D""> >>> --<br class=3D""> >>> Pavel Levshin<br class=3D""> >>><br class=3D""> >>><br class=3D""> >>><br class=3D""> >>> Hi Pavel,<br class=3D""> >>><br class=3D""> >>> VM migration is supported on the master branch, however it = has not been ported to 4.0 yet.<br class=3D""> >><br class=3D""> >>> You can either build VDSM from source (from master branch) = or try to apply this patch on what you have:<br class=3D""> >>> <a href=3D"https://gerrit.ovirt.org/#/c/59645" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://gerrit.ovirt.org/#/c/<wbr class=3D"">59645</a> <<a = href=3D"https://gerrit.ovirt.org/#/c/59645" rel=3D"noreferrer" = target=3D"_blank" class=3D"">https://gerrit.ovirt.org/#/c/<wbr = class=3D"">59645</a>><br class=3D""> >><br class=3D""> >> That=E2=80=99s quite a horrible solution right now. I certainly = would not like to see it in 4.0 (given the hacks around display).<br = class=3D""></div></div></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">What is horrible exactly?<br = class=3D""></div><div class=3D"">It's not too late to propose other = solutions.<br class=3D""></div></div></div></div></div></blockquote><div = class=3D""><br class=3D""></div>if OVS is the next great feature it = should fit into the code accordingly. I.e. using hooks only when it=E2=80=99= s absolutely necessary and as a temporary measure only until the = respective proper RFEs are implemented and available. E.g. when there is = a libvirt support missing we can add a qemu command line parameter = ourselves bypassing libvirt but we always should have a clear plan (i.e. = a bug) to move away from there as soon as the support is there(requested = back then when we went with the hack)</div><div class=3D""><br = class=3D""></div><div class=3D"">Such things should be reviewed as soon = as we get to a similar area, so while modifying libvirt-hook.sh we can = see the original reason for the hook is not valid anymore as everything = is addressed and the hacky code should have been removed</div><div = class=3D"">It was easy to see that because there is a clear comment = about dependent bugs and issues (though missed by all the reviewers, = unfortunately!)</div><div class=3D"">Your new code doesn=E2=80=99t have = anything like that and I have no idea what kind of API or behavior we = actually need, whether appropriate requests has been filed on e.g. = libvirt. That makes it very hard to revisit in the future by the next = random person.</div><div class=3D""><br class=3D""></div><div = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><div class=3D""><br class=3D""></div><div = class=3D"">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 = class=3D""></div><div class=3D"">That is limiting, especially now that = we do not have a Linux bridge, but something else.<br = class=3D""></div></div></div></div></div></blockquote><div class=3D""><br = class=3D""></div>that=E2=80=99s ok, whatever needs to be done. But then = please make sure you=E2=80=99re not breaking existing features, at least = again not without a plan(=3D=3Dbug) to fix it.</div><div class=3D""><br = class=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><div= class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><div class=3D""><br class=3D""></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"> >> Do we have a bug/plan to improve it?<br class=3D""> ><br class=3D""> > We have Bug 1362495 - [OVS] - Add support for live migration<br = class=3D""> > to track that.<br = class=3D""></div></div></blockquote></div></div></div></div></blockquote><= /div></div></div></blockquote><div><br class=3D""></div>oh, and yes, = that=E2=80=99s exactly the tracking I wanted to make sure exists. = There=E2=80=99s just no link in the gerrit commit itself so I didn=E2=80=99= t find it (but I wasn=E2=80=99t really looking hard = either;-)</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><div = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = class=3D"HOEnZb"><div class=3D"h5"> ><br class=3D""> > I'm afraid that we are not yet ready to backport it to 4.0 - we = found<br class=3D""> > out that as it is, it break migration for vmfex and external = network<br class=3D""> > providers; it also breaks when a buggy Engine db does not send a<br = class=3D""> > displayNetwork. But we plan to fix these issues quite soon.<br = class=3D""></div></div></blockquote></div></div></div></div></blockquote><= div class=3D""><br class=3D""></div>which =E2=80=9Cbuggy=E2=80=9D = engine? There were changes in parameters, most of these issues are not = relevant anymore since we ditched <3.6 though.</div><div = class=3D"">Again it=E2=80=99s ok as long as it is clearly mentioned like = "3.6 engine sends it in such and such parameter, we can drop it once we = support 4.0+"</div><div class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"> ><br class=3D""> > The hacks arround display are an actual imporovement. For = "legacy"<br class=3D""> > switchType, we maintain an on-host libvirt-side database of all = networks<br class=3D""> > only to keep libvirt happy. Having a database copy has all the = known<br class=3D""> > troubles of mismatches and being out of sync. For "ovs" switchType, = we<br class=3D""> > do not (we don't use a bridge, but a port group so there's no = natural<br class=3D""> > way to define our network in libvirt). Modifying the listening = address<br class=3D""> > on destination is the flexible and quick way to do it - I wish we = had<br class=3D""> > the libvirt migrate hook years ago.<br class=3D""> <br class=3D""> </div></div>doesn=E2=80=99t it prevent seamless virti-viewer console = connection?<br class=3D""></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">The end result is the same, we listen = on the address of a specific network.<br class=3D""></div><div = class=3D"">Previously it contained a network name and libvirt converted = it to the correct IP it should bind to, now vdsm resolves it.<br = class=3D""></div></div></div></div></div></blockquote><div class=3D""><br = class=3D""></div>so did we request libvirt to be able to do that itself = or requested an API to do that cleanly without mangling xml on the = fly?</div><div class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> also the =E2=80=9CTODO=E2=80=9D in the code about multiple graphics is = worrying (we fully support it and are considering to make it a = default)<br class=3D""></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">Supported where? virt networking code = in VDSM which creates an interface for domxml does not support it at the = moment.<br class=3D""></div><div class=3D"">Or am I missing = something?<br class=3D""></div></div></div></div></div></blockquote><div = class=3D""><br class=3D""></div><div class=3D"">supported in oVirt. = Multiple graphics VM is a regular oVirt feature. The hook doesn=E2=80=99t = handle it correctly hence I suppose the migration would not really work = correctly for these VMs.</div><div class=3D"">Again, that might be ok = temporarily with a clear documentation and a plan to fix = it.</div></div><div class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"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 class=3D""></blockquote><div = class=3D""><br class=3D""></div><div class=3D"">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 class=3D""></div><div = class=3D"">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 = class=3D""></div></div></div></div></div></blockquote><div class=3D""><br = class=3D""></div>I=E2=80=99m not saying you should depend on libvirt = data. But you should let libvirt community know if it is a useless = feature, use a clean way how not to use that feature(if it gets in your = way), ideally discuss and propose how such a feature can be improved so = oVirt and all other virtualization projects can benefit from that. If = it=E2=80=99s a truly useless feature I=E2=80=99m sure libvirt would be = happy to drop maintaining it</div><div class=3D""><br = class=3D""></div><div class=3D"">Thanks,</div><div = class=3D"">michal</div><div class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br = class=3D""></div><div class=3D"">Thaks,<br class=3D""></div><div = class=3D"">Edy.<br class=3D""></div><div = class=3D""> </div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br class=3D""> Thanks,<br class=3D""> michal<br class=3D""> <br class=3D""> </blockquote></div><br class=3D""></div></div> _______________________________________________<br class=3D"">Users = mailing list<br class=3D""><a href=3D"mailto:Users@ovirt.org" = class=3D"">Users@ovirt.org</a><br class=3D""><a = href=3D"http://lists.ovirt.org/mailman/listinfo/users" = class=3D"">http://lists.ovirt.org/mailman/listinfo/users</a><br = class=3D""></div></blockquote></div><br = class=3D""></div>_______________________________________________<br = class=3D"">Users mailing list<br class=3D""><a = href=3D"mailto:Users@ovirt.org" class=3D"">Users@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/users<br = class=3D""></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_11E505BE-B750-42AD-BBAB-F0AA4EA225FB--