> On 16 Sep 2016, at 14:36, Michal Skrivanek <michal.skriva...@redhat.com>
>> On 15 Sep 2016, at 21:46, Edward Haas <eh...@redhat.com
>> <mailto:eh...@redhat.com>> wrote:
>> On Thu, Sep 15, 2016 at 1:30 PM, Michal Skrivanek
>> <michal.skriva...@redhat.com <mailto:michal.skriva...@redhat.com>> wrote:
>> > On 15 Sep 2016, at 10:11, Dan Kenigsberg <dan...@redhat.com
>> > <mailto:dan...@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 <eh...@redhat.com
>> >>> <mailto:eh...@redhat.com>> wrote:
>> >>> On Thu, Sep 8, 2016 at 11:27 AM, Pavel Levshin <l...@581.spb.su
>> >>> <mailto:l...@581.spb.su> <mailto:l...@581.spb.su
>> >>> <mailto:l...@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>
>> >>> <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.
> if OVS is the next great feature it should fit into the code accordingly.
> I.e. using hooks only when it’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)
> 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
> 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’t 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.
>> 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’s ok, whatever needs to be done. But then please make sure you’re not
> breaking existing features, at least again not without a plan(==bug) to fix
>> >> 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’s exactly the tracking I wanted to make sure exists. There’s
just no link in the gerrit commit itself so I didn’t find it (but I wasn’t
really looking hard either;-)
>> > 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+"
>> > 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.
> 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?
>> 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?
> supported in oVirt. Multiple graphics VM is a regular oVirt feature. The hook
> doesn’t 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.
>> 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.
> I’m 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’s a truly useless feature I’m sure libvirt would be
> happy to drop maintaining it
>> Users mailing list
>> Users@ovirt.org <mailto:Users@ovirt.org>
> Users mailing list
Users mailing list