[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Simone Tiraboschi]

On Tue, May 14, 2019 at 2:33 PM  wrote:

> Hi,
>
> thanks to both - downgrading did not work, there is too much that needs to
> be removed and the old repos are deprecated and only available via eus. So,
> I'll setup the three node first and try to import the old domain there.
>
> > Yes, for this specific case the best option is to use latest RHV-H from
> 4.2
> time.
>
> Is 4.3 and RHEL hosts also a good option, or is there something specific
> in 4.2 that makes 3.6 domains better to import/attach?
>

In 4.3 we completely removed the support for 3.6 and 4.0 datacenter/cluster
levels as for:
https://bugzilla.redhat.com/1655115


No way using 4.3 stuff (that's why we also removed --upgrade-appliance from
hosted-engine in 4.3).
Your only option now is to use 4.2 only repos with oVirt or RHV-H from 4.2
if on RHV.


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WS7SMHFKALCL74WOMNK6FBYH2ZPUMTZZ/
>


-- 

Simone Tiraboschi

He / Him / His

Principal Software Engineer

Red Hat 

stira...@redhat.com
@redhatjobs    redhatjobs
 @redhatjobs



___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KUQTOU52NPT4E4JITKHPO7MS34Y4J2QT/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[axel . thimm]

Hi,

thanks to both - downgrading did not work, there is too much that needs to be 
removed and the old repos are deprecated and only available via eus. So, I'll 
setup the three node first and try to import the old domain there.

> Yes, for this specific case the best option is to use latest RHV-H from 4.2
time.

Is 4.3 and RHEL hosts also a good option, or is there something specific in 4.2 
that makes 3.6 domains better to import/attach?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WS7SMHFKALCL74WOMNK6FBYH2ZPUMTZZ/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Simone Tiraboschi]

On Tue, May 14, 2019 at 12:25 PM Yedidyah Bar David  wrote:

> On Tue, May 14, 2019 at 12:25 PM  wrote:
> >
> > > I'd personally first try to fix the engine<->vdsm comm issue.
> >
> > I fully agree. I might then take exports of all VMs and do a fresh start
> over. I'm not sure the upgrade instructions work, as the upgrade for
> 3.6->4.0 already activates much newer content. For example the quoted
> --upgrade-appliance options does not even exist, probably because a later
> package removed it. One would have to manually versionlock the 4.0
> hypervisior packages.
> >
> > > How did you upgrade the host? yum update? Is is ovirt-node?
> >
> > Currently the state is as follows: engine is running on the 3.6 branch,
> all updates applied [1]. The hosting RHEL host is on the RHV4 branch with
> all updats in, but the gnutls mentioned [2].
> >
> > I managed to flag the host as in maintenance mode, so I could ask it to
> re-enroll the certs.
>
> Did you? Please do.
>
> > I can see from the hosts logs, that the ssh connection works, and the
> certs have been updated. But now I see in the host's vdsm log that the SSL
> connection is being dropped.
>
> This can also be because a 3.6 engine defaults xmlrpc and a new 4.3
> host talks only jsonrpc. Not sure, perhaps you can change the host (on
> engine side) to use json rpc and it would work, although a 4.3 host is
> definitely not supposed to support a 3.6 engine. If all you want is to
> export the VMs, I'd downgrade the host to 3.6.
>
> >
> > > If you are ok debugging/fixing yourself and only need the occasional
> > > tip, fine. Otherwise, please provide more details - exact versions of
> > > engine/vdsm, last version that worked, whether you can reinstall the
> > > host or need anything on it, etc.
> >
> > I'm infinitely grateful for any assistance! I didn't want to spam the
> list with my first mail. I hope I provided some better information now.
> Thanks!
> >
> > In the long run I will decommission this host. I need the VMs on it to
> migrate to a fresh 4.3 3 host hyperconverged setup which is yet to be
> built. Actually I am abusing one of the three nodes at the moment as a
> backup system for this failed upgrade, so I'm blocked with going forward
> with that setup as well. ... :(
>
> Another option you might attempt is to import the data domain directly
> from the new engine. Obviously, do this first on a test copy...
>
> Re [2]: I'll use this opportunity to clarify something which is not
> obvious, since you use RHV and not oVirt.
>
> There is a significant difference between oVirt and RHV regarding
> repos/channels. In oVirt, each minor version has its own repos, and
> users can choose freely which one they want. In RHV, this the same for
> the engine channels, but not for hosts. For hosts, there is only a
> single channel per each major version. So if you use RHV 4 host
> channel, you get latest. Older versions are still available there, but
> you have to play with yum to choose them, and in RHV this is
> considered not supported, other than using RHVH (RHV downstream of
> oVirt node) which can be used for specific cases (perhaps like yours,
> but not sure it would help).


Yes, for this specific case the best option is to use latest RHV-H from 4.2
time.


> This has the advantage, for RHV
> customers, of not having to add a new repo to get updates, and the
> disadvantage of not being able to stay on a specific minor version
> when upgrading.
>
> Good luck and best regards,
>
>
> >
> > [1]
> > [root@engine ~]# engine-upgrade-check
> > VERB: queue package rhevm-setup for update
> > VERB: Downloading: repomdtDvMe7tmp.xml (0%)
> > VERB: Downloading: repomdtDvMe7tmp.xml 3.4 k(100%)
> > VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db (0%)
> > VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db 1.2 M(100%)
> > VERB: Downloading: repomd__rFIUtmp.xml (0%)
> > VERB: Downloading: repomd__rFIUtmp.xml 3.4 k(100%)
> > VERB: Downloading: repomdXw2WPVtmp.xml (0%)
> > VERB: Downloading: repomdXw2WPVtmp.xml 4.0 k(100%)
> > VERB: Downloading: repomdF3AGBOtmp.xml (0%)
> > VERB: Downloading: repomdF3AGBOtmp.xml 3.5 k(100%)
> > VERB: Downloading: repomd9DvU9vtmp.xml (0%)
> > VERB: Downloading: repomd9DvU9vtmp.xml 3.4 k(100%)
> > VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db (0%)
> > VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db 851
> k(100%)
> > VERB: Building transaction
> > VERB: Empty transaction
> > VERB: Transaction Summary:
> > No upgrade
> >
> > [2]
> > # subscription-manager repos --list-enabled; yum check-update
> > +--+
> > Available Repositories in /etc/yum.repos.d/redhat.repo
> > +--+
> > Repo ID:   rhel-7-server-ansible-2-rpms
> > Repo Name: Red Hat Ansible Engine 2 RPMs for Red Hat Enterprise Linux 7
> Server
> > Repo URL:
> https://cdn.redhat.com/content/dist/rhel/server/7/7Server/$basearch/a
> >  

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Yedidyah Bar David]

On Tue, May 14, 2019 at 12:25 PM  wrote:
>
> > I'd personally first try to fix the engine<->vdsm comm issue.
>
> I fully agree. I might then take exports of all VMs and do a fresh start 
> over. I'm not sure the upgrade instructions work, as the upgrade for 3.6->4.0 
> already activates much newer content. For example the quoted 
> --upgrade-appliance options does not even exist, probably because a later 
> package removed it. One would have to manually versionlock the 4.0 
> hypervisior packages.
>
> > How did you upgrade the host? yum update? Is is ovirt-node?
>
> Currently the state is as follows: engine is running on the 3.6 branch, all 
> updates applied [1]. The hosting RHEL host is on the RHV4 branch with all 
> updats in, but the gnutls mentioned [2].
>
> I managed to flag the host as in maintenance mode, so I could ask it to 
> re-enroll the certs.

Did you? Please do.

> I can see from the hosts logs, that the ssh connection works, and the certs 
> have been updated. But now I see in the host's vdsm log that the SSL 
> connection is being dropped.

This can also be because a 3.6 engine defaults xmlrpc and a new 4.3
host talks only jsonrpc. Not sure, perhaps you can change the host (on
engine side) to use json rpc and it would work, although a 4.3 host is
definitely not supposed to support a 3.6 engine. If all you want is to
export the VMs, I'd downgrade the host to 3.6.

>
> > If you are ok debugging/fixing yourself and only need the occasional
> > tip, fine. Otherwise, please provide more details - exact versions of
> > engine/vdsm, last version that worked, whether you can reinstall the
> > host or need anything on it, etc.
>
> I'm infinitely grateful for any assistance! I didn't want to spam the list 
> with my first mail. I hope I provided some better information now. Thanks!
>
> In the long run I will decommission this host. I need the VMs on it to 
> migrate to a fresh 4.3 3 host hyperconverged setup which is yet to be built. 
> Actually I am abusing one of the three nodes at the moment as a backup system 
> for this failed upgrade, so I'm blocked with going forward with that setup as 
> well. ... :(

Another option you might attempt is to import the data domain directly
from the new engine. Obviously, do this first on a test copy...

Re [2]: I'll use this opportunity to clarify something which is not
obvious, since you use RHV and not oVirt.

There is a significant difference between oVirt and RHV regarding
repos/channels. In oVirt, each minor version has its own repos, and
users can choose freely which one they want. In RHV, this the same for
the engine channels, but not for hosts. For hosts, there is only a
single channel per each major version. So if you use RHV 4 host
channel, you get latest. Older versions are still available there, but
you have to play with yum to choose them, and in RHV this is
considered not supported, other than using RHVH (RHV downstream of
oVirt node) which can be used for specific cases (perhaps like yours,
but not sure it would help). This has the advantage, for RHV
customers, of not having to add a new repo to get updates, and the
disadvantage of not being able to stay on a specific minor version
when upgrading.

Good luck and best regards,


>
> [1]
> [root@engine ~]# engine-upgrade-check
> VERB: queue package rhevm-setup for update
> VERB: Downloading: repomdtDvMe7tmp.xml (0%)
> VERB: Downloading: repomdtDvMe7tmp.xml 3.4 k(100%)
> VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db (0%)
> VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db 1.2 M(100%)
> VERB: Downloading: repomd__rFIUtmp.xml (0%)
> VERB: Downloading: repomd__rFIUtmp.xml 3.4 k(100%)
> VERB: Downloading: repomdXw2WPVtmp.xml (0%)
> VERB: Downloading: repomdXw2WPVtmp.xml 4.0 k(100%)
> VERB: Downloading: repomdF3AGBOtmp.xml (0%)
> VERB: Downloading: repomdF3AGBOtmp.xml 3.5 k(100%)
> VERB: Downloading: repomd9DvU9vtmp.xml (0%)
> VERB: Downloading: repomd9DvU9vtmp.xml 3.4 k(100%)
> VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db (0%)
> VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db 851 k(100%)
> VERB: Building transaction
> VERB: Empty transaction
> VERB: Transaction Summary:
> No upgrade
>
> [2]
> # subscription-manager repos --list-enabled; yum check-update
> +--+
> Available Repositories in /etc/yum.repos.d/redhat.repo
> +--+
> Repo ID:   rhel-7-server-ansible-2-rpms
> Repo Name: Red Hat Ansible Engine 2 RPMs for Red Hat Enterprise Linux 7 Server
> Repo URL:  
> https://cdn.redhat.com/content/dist/rhel/server/7/7Server/$basearch/a
>nsible/2/os
> Enabled:   1
>
> Repo ID:   rhel-7-server-rhev-mgmt-agent-rpms
> Repo Name: Red Hat Enterprise Virtualization Management Agents for RHEL 7 
> (RPMs)
> Repo URL:  
> https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
>ch/rhev-mgmt-agent/3/os
> 

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[axel . thimm]

> I'd personally first try to fix the engine<->vdsm comm issue.

I fully agree. I might then take exports of all VMs and do a fresh start over. 
I'm not sure the upgrade instructions work, as the upgrade for 3.6->4.0 already 
activates much newer content. For example the quoted --upgrade-appliance 
options does not even exist, probably because a later package removed it. One 
would have to manually versionlock the 4.0 hypervisior packages.

> How did you upgrade the host? yum update? Is is ovirt-node?

Currently the state is as follows: engine is running on the 3.6 branch, all 
updates applied [1]. The hosting RHEL host is on the RHV4 branch with all 
updats in, but the gnutls mentioned [2].

I managed to flag the host as in maintenance mode, so I could ask it to 
re-enroll the certs. I can see from the hosts logs, that the ssh connection 
works, and the certs have been updated. But now I see in the host's vdsm log 
that the SSL connection is being dropped.

> If you are ok debugging/fixing yourself and only need the occasional
> tip, fine. Otherwise, please provide more details - exact versions of
> engine/vdsm, last version that worked, whether you can reinstall the
> host or need anything on it, etc.

I'm infinitely grateful for any assistance! I didn't want to spam the list with 
my first mail. I hope I provided some better information now. Thanks!

In the long run I will decommission this host. I need the VMs on it to migrate 
to a fresh 4.3 3 host hyperconverged setup which is yet to be built. Actually I 
am abusing one of the three nodes at the moment as a backup system for this 
failed upgrade, so I'm blocked with going forward with that setup as well. ... 
:(

[1]
[root@engine ~]# engine-upgrade-check
VERB: queue package rhevm-setup for update
VERB: Downloading: repomdtDvMe7tmp.xml (0%)
VERB: Downloading: repomdtDvMe7tmp.xml 3.4 k(100%)
VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db (0%)
VERB: Downloading: jb-eap-6-for-rhel-6-server-rpms/primary_db 1.2 M(100%)
VERB: Downloading: repomd__rFIUtmp.xml (0%)
VERB: Downloading: repomd__rFIUtmp.xml 3.4 k(100%)
VERB: Downloading: repomdXw2WPVtmp.xml (0%)
VERB: Downloading: repomdXw2WPVtmp.xml 4.0 k(100%)
VERB: Downloading: repomdF3AGBOtmp.xml (0%)
VERB: Downloading: repomdF3AGBOtmp.xml 3.5 k(100%)
VERB: Downloading: repomd9DvU9vtmp.xml (0%)
VERB: Downloading: repomd9DvU9vtmp.xml 3.4 k(100%)
VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db (0%)
VERB: Downloading: rhel-6-server-supplementary-rpms/primary_db 851 k(100%)
VERB: Building transaction
VERB: Empty transaction
VERB: Transaction Summary:
No upgrade

[2]
# subscription-manager repos --list-enabled; yum check-update
+--+
Available Repositories in /etc/yum.repos.d/redhat.repo
+--+
Repo ID:   rhel-7-server-ansible-2-rpms
Repo Name: Red Hat Ansible Engine 2 RPMs for Red Hat Enterprise Linux 7 Server
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/7/7Server/$basearch/a
   nsible/2/os
Enabled:   1

Repo ID:   rhel-7-server-rhev-mgmt-agent-rpms
Repo Name: Red Hat Enterprise Virtualization Management Agents for RHEL 7 (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
   ch/rhev-mgmt-agent/3/os
Enabled:   1

Repo ID:   rhel-7-server-rhv-4-mgmt-agent-rpms
Repo Name: Red Hat Virtualization 4 Management Agents for RHEL 7 (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
   ch/rhv-mgmt-agent/4/os
Enabled:   1

Repo ID:   rhel-7-server-rpms
Repo Name: Red Hat Enterprise Linux 7 Server (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
   ch/os
Enabled:   1

Repo ID:   rhel-7-server-optional-rpms
Repo Name: Red Hat Enterprise Linux 7 Server - Optional (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basear
   ch/optional/os
Enabled:   1

Loaded plugins: enabled_repos_upload, package_upload, product-id, search-
  : disabled-repos, subscription-manager, vdsmupgrade

gnutls.x86_64   
  3.3.29-9.el7_6
rhel-7-server-rpms
gnutls-dane.x86_64  
  3.3.29-9.el7_6
rhel-7-server-rpms
gnutls-utils.x86_64 
  3.3.29-9.el7_6
rhel-7-server-rpms
Uploading Enabled Repositories Report
Loaded plugins: product-id, subscription-manager
Unable to upload Enabled Repositories Report

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Yedidyah Bar David]

On Tue, May 14, 2019 at 11:10 AM  wrote:
>
> Hi,
>
> yes, the host seems to have been updated.
>
> vdsm-api-4.30.13-1.el7ev.noarch
> vdsm-http-4.30.13-1.el7ev.noarch
> vdsm-hook-vmfex-dev-4.30.13-1.el7ev.noarch
> vdsm-network-4.30.13-1.el7ev.x86_64
> vdsm-common-4.30.13-1.el7ev.noarch
> vdsm-yajsonrpc-4.30.13-1.el7ev.noarch
> vdsm-jsonrpc-4.30.13-1.el7ev.noarch
> vdsm-hook-ethtool-options-4.30.13-1.el7ev.noarch
> vdsm-hook-openstacknet-4.30.13-1.el7ev.noarch
> vdsm-hook-vhostmd-4.30.13-1.el7ev.noarch
> vdsm-client-4.30.13-1.el7ev.noarch
> vdsm-hook-fcoe-4.30.13-1.el7ev.noarch
> vdsm-python-4.30.13-1.el7ev.noarch
> vdsm-4.30.13-1.el7ev.x86_64
>
> I see some communication happening between the engine and the host's vdsmd on 
> port 54321, but it is encrypted. It does break off immediately, so I wonder 
> if this is an SSL issue. I already downgraded gnutls due to 
> https://bugzilla.redhat.com/show_bug.cgi?id=1648190
>
> The engine just complains on communication errors, e.g.
> 2019-05-14 09:30:56,275 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] 
> (DefaultQuartzScheduler_Worker-83) [] Command 
> 'GetCapabilitiesVDSCommand(HostName = hetzner-XX, 
> VdsIdAndVdsVDSCommandParam
> etersBase:{runAsync='true', hostId='2bc7bd41-aaa2-4973-95ab-402a0fe32daf', 
> vds='Host[hetzner-XX,2bc7bd41-aaa2-4973-95ab-402a0fe32daf]'})' execution 
> failed: VDSGenericException: VDSNetworkException: Message timeout which ca
> n be caused by communication issues
> 2019-05-14 09:30:56,275 ERROR 
> [org.ovirt.engine.core.vdsbroker.HostMonitoring] 
> (DefaultQuartzScheduler_Worker-83) [] Failure to refresh Vds runtime info: 
> VDSGenericException: VDSNetworkException: Message timeout which can be c
> aused by communication issues
> 2019-05-14 09:30:56,275 ERROR 
> [org.ovirt.engine.core.vdsbroker.HostMonitoring] 
> (DefaultQuartzScheduler_Worker-83) [] Exception: 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
> VDSGenericException: VDSNetworkExce
> ption: Message timeout which can be caused by communication issues
>
> Would trying
>
> hosted-engine --upgrade-appliance
>
> make any sense w/o restoring the communication on vdsm level?

Might not make sense at all, --upgrade-appliance is only for
el6/3.6->el7/4.0. Later upgrades you do inside the VM.

I'd personally first try to fix the engine<->vdsm comm issue.

How did you upgrade the host? yum update? Is is ovirt-node?

If you are ok debugging/fixing yourself and only need the occasional
tip, fine. Otherwise, please provide more details - exact versions of
engine/vdsm, last version that worked, whether you can reinstall the
host or need anything on it, etc.

Best regards,
--
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YKZJXBMJPYZQ2BLUQDJMXABE5GPTAIVE/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[axel . thimm]

Hi,

yes, the host seems to have been updated.

vdsm-api-4.30.13-1.el7ev.noarch
vdsm-http-4.30.13-1.el7ev.noarch
vdsm-hook-vmfex-dev-4.30.13-1.el7ev.noarch
vdsm-network-4.30.13-1.el7ev.x86_64
vdsm-common-4.30.13-1.el7ev.noarch
vdsm-yajsonrpc-4.30.13-1.el7ev.noarch
vdsm-jsonrpc-4.30.13-1.el7ev.noarch
vdsm-hook-ethtool-options-4.30.13-1.el7ev.noarch
vdsm-hook-openstacknet-4.30.13-1.el7ev.noarch
vdsm-hook-vhostmd-4.30.13-1.el7ev.noarch
vdsm-client-4.30.13-1.el7ev.noarch
vdsm-hook-fcoe-4.30.13-1.el7ev.noarch
vdsm-python-4.30.13-1.el7ev.noarch
vdsm-4.30.13-1.el7ev.x86_64

I see some communication happening between the engine and the host's vdsmd on 
port 54321, but it is encrypted. It does break off immediately, so I wonder if 
this is an SSL issue. I already downgraded gnutls due to 
https://bugzilla.redhat.com/show_bug.cgi?id=1648190

The engine just complains on communication errors, e.g.
2019-05-14 09:30:56,275 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] 
(DefaultQuartzScheduler_Worker-83) [] Command 
'GetCapabilitiesVDSCommand(HostName = hetzner-XX, VdsIdAndVdsVDSCommandParam
etersBase:{runAsync='true', hostId='2bc7bd41-aaa2-4973-95ab-402a0fe32daf', 
vds='Host[hetzner-XX,2bc7bd41-aaa2-4973-95ab-402a0fe32daf]'})' execution 
failed: VDSGenericException: VDSNetworkException: Message timeout which ca
n be caused by communication issues
2019-05-14 09:30:56,275 ERROR [org.ovirt.engine.core.vdsbroker.HostMonitoring] 
(DefaultQuartzScheduler_Worker-83) [] Failure to refresh Vds runtime info: 
VDSGenericException: VDSNetworkException: Message timeout which can be c
aused by communication issues
2019-05-14 09:30:56,275 ERROR [org.ovirt.engine.core.vdsbroker.HostMonitoring] 
(DefaultQuartzScheduler_Worker-83) [] Exception: 
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
VDSGenericException: VDSNetworkExce
ption: Message timeout which can be caused by communication issues

Would trying

hosted-engine --upgrade-appliance

make any sense w/o restoring the communication on vdsm level?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YZYR7DGCWECYBZTGMNZ2Q2HBMGRP6FPE/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Yedidyah Bar David]

On Tue, May 14, 2019 at 9:20 AM  wrote:
>
> Hi,
>
> update: I managed to get the old engine running (3.6), but it is not 
> communicating with the host. Do I need to downgrade the host and/or somehow 
> re-enroll it to the engine?

I didn't understand the current state of your host, but if it's
(partially? upgraded to) 4.2, then IIRC you need to downgrade. Also,
please provide more details, when you ask for help - what happens when
you try to activate it (if the ui allows that at all)? What errors do
you get in the ui and in the logs (engine and vdsm)? etc.

Thanks and best regards,
-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/57WTSDHSUPWVVDHI6LKLTDUMRK6IHZEO/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[axel . thimm]

Hi,

update: I managed to get the old engine running (3.6), but it is not 
communicating with the host. Do I need to downgrade the host and/or somehow 
re-enroll it to the engine?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5HCMZ6WJLUKJGREBFKVHVW2FEOC66VVH/

[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover

[Andreas Elvers]

If you can: restart your setup from scratch with at least 3 hosts. Really. If 
you don't face harsh consequences for doing so. It isn't just worth the hassle 
and pain. Use at least 3 hosts because: A node can corrupt due to many reasons. 
Natural causes, self inflicted ones. A corrupt node can only recover through 
re-installation. This is triggered by the engine with VMs safe on the other 
nodes. On a single node system how can this be possible with only a corrupted 
node at hand? If you really can only stick to a one host setup you could try 
Proxmox. They have a community edition. 

For multi host setups choose oVirt. It is just great.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NISRIS3ZGGBSSQTNOE4PF53HBROI7RQ5/