7:36 a.m.
--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(a)redhat.com>
wrote:
=20
=20
=20
On Thu, Sep 15, 2016 at 1:30 PM, Michal Skrivanek =
<michal.skrivanek(a)redhat.com
<mailto:michal.skrivanek@redhat.com>> =
wrote:
=20
> On 15 Sep 2016, at 10:11, Dan Kenigsberg <danken(a)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(a)redhat.com =
<mailto:ehaas@redhat.com>> wrote:
>>>
>>>
>>>
>>> On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk(a)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>>
>>
>> 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(a)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(a)redhat.com</a>&gt; =
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(a)redhat.com</a>&gt;</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(a)redhat.com</a>&gt; =
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(a)redhat.com</a>&gt; =
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(a)581.spb.su</a>
=
<mailto:<a href=3D"mailto:lpk@581.spb.su" =
class=3D"">lpk(a)581.spb.su</a>&gt;&gt; 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(a)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--