3:27 a.m.
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
6:09 a.m.
On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk(a)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
(note that you'll need to restart vdsm service for this to take affect)
Thanks,
Edy.
8:04 a.m.
--Apple-Mail=_64EAE2EA-54FD-4B60-ABD8-5D680ED66E32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 09 Sep 2016, at 13:09, Edward Haas <ehaas(a)redhat.com>
wrote:
=20
=20
=20
On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <lpk(a)581.spb.su =
<mailto:lpk@581.spb.su>> wrote:
Hi.
=20
I'm trying to learn Ovirt 4 and have a problem with it.
=20
My cluster consists of 3 nodes. I use Openvswitch for network =
connectivity. I
have a HostedEngine and one additional VM in the =
cluster.
=20
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.
=20
How this is supposed to work?
=20
--
Pavel Levshin
=20
=20
=20
Hi Pavel,
=20
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>
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
Do we have a bug/plan to improve it?
Thanks,
michal
=20
(note that you'll need to restart vdsm service for this to take =
affect)
=20
Thanks,
Edy.
=20
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--Apple-Mail=_64EAE2EA-54FD-4B60-ABD8-5D680ED66E32
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 09 Sep 2016, at 13:09, 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 8, 2016 at
11:27 AM, =
Pavel Levshin <span dir=3D"ltr" class=3D""><<a
target=3D"_blank" =
href=3D"mailto:lpk@581.spb.su"
class=3D"">lpk(a)581.spb.su</a>&gt;</span> =
wrote:<br class=3D""><blockquote style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" =
class=3D"gmail_quote">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""></blockquote><div class=3D""><br
class=3D""></div><div =
class=3D"">Hi Pavel,<br class=3D""><br
class=3D""></div><div class=3D"">VM=
migration is supported on the master branch, however it has not been =
ported to 4.0 =
yet.</div></div></div></div></div></blockquote></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"">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" =
class=3D"">https://gerrit.ovirt.org/#/c/59645</a><br =
class=3D""></div></div></div></div></div></blockquote><div><br
=
class=3D""></div>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). </div><div>Do we have a bug/plan to improve =
it?</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</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"">(note that you'll need to restart vdsm service for this to =
take affect)<br class=3D""><br
class=3D""></div></div>Thanks,<br =
class=3D""></div><div class=3D"gmail_extra">Edy.<br
class=3D""><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=_64EAE2EA-54FD-4B60-ABD8-5D680ED66E32--
3:11 a.m.
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.
5:30 a.m.
On 15 Sep 2016, at 10:11, Dan Kenigsberg <danken(a)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> 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.
doesn’t it prevent seamless virti-viewer console connection?
also the “TODO” in the code about multiple graphics is worrying (we fully support it and
are considering to make it a default)
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.
Thanks,
michal
2:46 p.m.
On Thu, Sep 15, 2016 at 1:30 PM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
> On 15 Sep 2016, at 10:11, Dan Kenigsberg <danken(a)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> 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).
What is horrible exactly?
It's not too late to propose other solutions.
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.
> 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.
doesn’t it prevent seamless virti-viewer console connection?
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.
also the “TODO” in the code about multiple graphics is worrying (we fully
support it and are considering to make it a default)
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?
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.
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.
Thaks,
Edy.
Thanks,
michal
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--
7:41 a.m.
--Apple-Mail=_11E505BE-B750-42AD-BBAB-F0AA4EA225FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 16 Sep 2016, at 14:36, Michal Skrivanek =
<michal.skrivanek(a)redhat.com> wrote:
=20
=20
> On 15 Sep 2016, at 21:46, Edward Haas <ehaas(a)redhat.com =
<mailto:ehaas@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.
=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 =
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
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
>=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
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.
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
> >
> > 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 =
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+"
=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 =
the correct IP it should bind to, now vdsm resolves it.
=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
=
plan to fix it.
=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 =
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(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
=20
_______________________________________________
Users mailing list
Users(a)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(a)redhat.com</a>&gt;
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(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
=
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(a)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<... =
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(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=_11E505BE-B750-42AD-BBAB-F0AA4EA225FB--
2:29 a.m.
Michal Skrivanek <michal.skrivanek(a)redhat.com> writes:
> > 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 “buggy” engine? There were changes in parameters, most of these issues
are not relevant anymore since we ditched <3.6 though.
Again it’s 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+"
I think Edward means the problem when there is no display (and
migration) network set for a cluster in Engine. This may happen due to
a former bug in Engine db scripts. Vdsm apparently falls back on
ovirtmgmt in most cases so the problem is typically unnoticed. But when
you look for displayNetwork explicitly in Vdsm, it's not there.
The bug may affect 4.0 installations until a db upgrade fix is created
and backported.
2799
days inactive
2810
days old
8 comments
5 participants
participants (5)
-
Dan Kenigsberg -
Edward Haas -
Michal Skrivanek -
Milan Zamazal -
Pavel Levshin