Failover Cluster WMI provider issue

[Lucian Petrut]

The Failover Cluster WMI provider is quite unreliable, especially in recent Windows Server 2016 versions.

After failovers, some valid WMI queries fail with "Invalid Property" errors, which really looks like a WMI provider bug. Event listeners are affected as well, for which reason we're missing VM failover events.

We should switch to the underlying C library, avoiding the WMI provider as much as possible. This way, we're going down a layer, increasing the reliability as well as performance of cluster related operations.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/607611
Committed: https://git.openstack.org/cgit/openstack/os-win/commit/?id=6c6955f9f23f3fabf71d06f0a52d6d770aedab2c
Submitter: Zuul
Branch: master

commit 6c6955f9f23f3fabf71d06f0a52d6d770aedab2c
Author: Lucian Petrut <email address hidden>
Date: Fri Sep 28 16:57:19 2018 +0300

    Limit Failover Cluster WMI provider usage

    The Failover Cluster WMI provider is quite unreliable, especially
    in recent Windows Server 2016 versions.

    After failovers, some valid WMI queries fail with "Invalid Property"
    errors, which really looks like a WMI provider bug. Event listeners
    are affected as well, for which reason we're missing VM failover events.

    This change refactors "clusterutils", switching to the underlying
    C library.

    The new failover event listener cannot provide the source of the
    migrated instances, so we're keeping the old one as well for backwards
    compatibility, for now.

    The only other places in which we're still using WMI are the methods
    that add or destroy VM cluster roles.

    The reason is that we'd have to explicitly create the the cluster
    resources and group, probably set some resource dependencies and
    properties. For now, it's easier/safer to just stick with the WMI
    method (which really shouldn't fail).

    Also, destroying VM cluster groups using clusapi's DestroyClusterGroup
    function behaves strange. VMs get recreated asyncronuously and put in
    suspended state, breaking everything. We're avoiding it for now.

    Closes-Bug: #1798069

    Change-Id: I63d1aa3a6f9fb12d08478eb41fe973b1582b540c

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-win 4.1.1 release.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/607861
Committed: https://git.openstack.org/cgit/openstack/compute-hyperv/commit/?id=feb4bae60fd86d107b1f6479bdf38c16d623398d
Submitter: Zuul
Branch: master

commit feb4bae60fd86d107b1f6479bdf38c16d623398d
Author: Lucian Petrut <email address hidden>
Date: Thu Oct 4 12:14:13 2018 +0300

    Switch to new instance failover listener

    We had a bunch of issues with the WMI based event listener, which
    appear to be bugs in the WMI provider.

    We've added a new listener that uses the underlying C library. The
    only issue is that this new listener cannot tell us the source of
    the migrated VMs, so we'll have to rely on the information from
    Nova.

    Closes-Bug: #1798069
    Depends-On: I63d1aa3a6f9fb12d08478eb41fe973b1582b540c

    Change-Id: I9e777351eca84274cafc3f04b6bc27c3f6b572ca

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/compute-hyperv 9.0.0.0rc1 release candidate.