--Apple-Mail=_1A16F9DC-3DA2-4E26-8C67-DA21F8E373C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8
On 15 Sep 2016, at 21:46, Edward Haas <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.
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 = 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) 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 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.
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
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.
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. 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+"
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 the = correct IP it should bind to, now vdsm resolves it.
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 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?
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 = plan to fix it.
=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.
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 Thanks, michal
=20 Thaks, Edy. =20 =20 Thanks, michal =20 =20 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--Apple-Mail=_1A16F9DC-3DA2-4E26-8C67-DA21F8E373C5 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 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><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=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 = 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><br class=3D""></div><div>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>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>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><br class=3D""></div><div><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><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><br = class=3D""></div><div><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""> ><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><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>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><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><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><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><br = class=3D""></div><div>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>Again, that might be ok temporarily with a clear = documentation and a plan to fix it.</div></div><div><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><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><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><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"">http://lists.ovirt.org/mailman/listinfo/users<br = class=3D""></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_1A16F9DC-3DA2-4E26-8C67-DA21F8E373C5--