[ovirt-users] Re: upgrade VM cluster compatibility version
ah, found it. Thank you very much! On Tue, Apr 14, 2020 at 5:42 PM wrote: > When you edit the bm, show advanced options, then under system and > advanced options. > > See the attached screenshot. > > > > Eric Evans > > Digital Data Services LLC. > > 304.660.9080 > > > > *From:* Bill James > *Sent:* Tuesday, April 14, 2020 6:52 PM > *To:* users > *Subject:* [ovirt-users] upgrade VM cluster compatibility version > > > > I'm trying to upgrade my cluster to 4.3. Currently its running > 4.2.8.2-1.el7. > > But the cluster compatibility version is 3.6. > > I try to change that and it says I need to edit the VM. > > > https://www.ovirt.org/documentation/upgrade-guide/chap-Post-Upgrade_Tasks.html > > > > says: > > *Important:* An error message may warn that some virtual machines and > templates are incorrectly configured. To fix this error, edit each virtual > machine manually. The *Edit Virtual Machine* window provides additional > validations and warnings that show what to correct. Sometimes the issue is > automatically corrected and the virtual machine’s configuration just needs > to be saved again. After editing each virtual machine, you will be able to > change the cluster compatibility version. > > > > > > I edit the VM and there are no errors or warnings. I see no way to change > the cluster compatibility level on a VM. > > How do I change the Custom Compatibility Version?? > > > > > -- > > > > This email, its contents and attachments contain information from J2 > Global, Inc. and/or its affiliates which may be privileged, confidential or > otherwise protected from disclosure. The information is intended to be for > the addressee(s) only. If you are not an addressee, any disclosure, copy, > distribution or use of the contents of this message is prohibited. If you > have received this email in error, please notify the sender by reply email > and delete the original message and any copies. > > > -- This email, its contents and attachments contain information from J2 Global, Inc. and/or its affiliates which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this email in error, please notify the sender by reply email and delete the original message and any copies. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7PFP5PHO5RTUU656YFMP2QCHU4NA7OGN/
[ovirt-users] Re: upgrade VM cluster compatibility version
When you edit the bm, show advanced options, then under system and advanced options. See the attached screenshot. Eric Evans Digital Data Services LLC. 304.660.9080 From: Bill James Sent: Tuesday, April 14, 2020 6:52 PM To: users Subject: [ovirt-users] upgrade VM cluster compatibility version I'm trying to upgrade my cluster to 4.3. Currently its running 4.2.8.2-1.el7. But the cluster compatibility version is 3.6. I try to change that and it says I need to edit the VM. https://www.ovirt.org/documentation/upgrade-guide/chap-Post-Upgrade_Tasks.html says: Important: An error message may warn that some virtual machines and templates are incorrectly configured. To fix this error, edit each virtual machine manually. The Edit Virtual Machine window provides additional validations and warnings that show what to correct. Sometimes the issue is automatically corrected and the virtual machine’s configuration just needs to be saved again. After editing each virtual machine, you will be able to change the cluster compatibility version. I edit the VM and there are no errors or warnings. I see no way to change the cluster compatibility level on a VM. How do I change the Custom Compatibility Version?? _ This email, its contents and attachments contain information from J2 Global, Inc. and/or its affiliates which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this email in error, please notify the sender by reply email and delete the original message and any copies. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7FVO4AVRRVRGME44QQKP6T2NZZMDECLX/
[ovirt-users] upgrade VM cluster compatibility version
I'm trying to upgrade my cluster to 4.3. Currently its running 4.2.8.2-1.el7. But the cluster compatibility version is 3.6. I try to change that and it says I need to edit the VM. https://www.ovirt.org/documentation/upgrade-guide/chap-Post-Upgrade_Tasks.html says: *Important:* An error message may warn that some virtual machines and templates are incorrectly configured. To fix this error, edit each virtual machine manually. The *Edit Virtual Machine* window provides additional validations and warnings that show what to correct. Sometimes the issue is automatically corrected and the virtual machine’s configuration just needs to be saved again. After editing each virtual machine, you will be able to change the cluster compatibility version. I edit the VM and there are no errors or warnings. I see no way to change the cluster compatibility level on a VM. How do I change the Custom Compatibility Version?? -- This email, its contents and attachments contain information from J2 Global, Inc. and/or its affiliates which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this email in error, please notify the sender by reply email and delete the original message and any copies. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/LDZIZW6LZPQG7WANSTOG34WN246ZKEMC/
[ovirt-users] Re: Get OAuth token locally without password?
You can access the API with a local user account by using saslpasswd then use those credentials for the cron job. You can point to a user account in crontab by putting the username before the script path. I'm just not sure how to have the password automatically called for authentication. Eric Evans Digital Data Services LLC. 304.660.9080 -Original Message- From: Chris Adams Sent: Tuesday, April 14, 2020 11:21 AM To: users@ovirt.org Subject: [ovirt-users] Get OAuth token locally without password? I'm working on a cron job to run on the engine to do some tasks via the API. Is there a way I can get an API OAuth token created without actually storing a password? For example, some script that can be run to directly create a session in the database and return the token. Obviously this _can_ be done, it's a matter of knowing the right bits to do (so basically wondering if that has already been written). I only have internal users, so no external authentication store available. -- Chris Adams ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWQH2JZ72H4XXOURHOYQH3HGQRDSDKPH/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/T3XMSPNVQQKNWXEMMM5COIDF3L7PYYAB/
[ovirt-users] Re: ovirt-engine unresponsive - how to rescue?
On April 14, 2020 6:17:17 PM GMT+03:00, Shareef Jalloq
wrote:
>Hmmm, we're not using ipv6. Is that the issue?
>
>On Tue, Apr 14, 2020 at 3:56 PM Strahil Nikolov
>wrote:
>
>> On April 14, 2020 1:27:24 PM GMT+03:00, Shareef Jalloq <
>> shar...@jalloq.co.uk> wrote:
>> >Right, I've given up on recovering the HE so want to try and
>redeploy
>> >it.
>> >There doesn't seem to be enough information to debug why the
>> >broker/agent
>> >won't start cleanly.
>> >
>> >In running 'hosted-engine --deploy', I'm seeing the following error
>in
>> >the
>> >setup validation phase:
>> >
>> >2020-04-14 09:46:08,922+ DEBUG otopi.plugins.otopi.dialog.human
>> >dialog.__logString:204 DIALOG:SEND Please provide
>the
>> >hostname of this host on the management network
>> >[ovirt-node-00.phoelex.com]:
>> >
>> >
>> >2020-04-14 09:46:12,831+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge
>> >hostname.getResolvedAddresses:432
>> >getResolvedAddresses: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
>> >
>> >2020-04-14 09:46:12,832+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge
>> >hostname._validateFQDNresolvability:289 ovirt-node-00.phoelex.com
>> >resolves
>> >to: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
>> >
>> >2020-04-14 09:46:12,832+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
>> >execute:
>> >['/usr/bin/dig', '+noall', '+answer', 'ovirt-node-00.phoelex.com',
>> >'ANY'],
>> >executable='None', cwd='None', env=None
>> >
>> >2020-04-14 09:46:12,871+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
>> >execute-result: ['/usr/bin/dig', '+noall', '+answer', '
>> >ovirt-node-00.phoelex.com', 'ANY'], rc=0
>> >
>> >2020-04-14 09:46:12,872+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.execute:921
>> >execute-output: ['/usr/bin/dig', '+noall', '+answer', '
>> >ovirt-node-00.phoelex.com', 'ANY'] stdout:
>> >
>> >ovirt-node-00.phoelex.com. 86400 IN A 192.168.1.61
>> >
>> >
>> >2020-04-14 09:46:12,872+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.execute:926
>> >execute-output: ['/usr/bin/dig', '+noall', '+answer', '
>> >ovirt-node-00.phoelex.com', 'ANY'] stderr:
>> >
>> >
>> >
>> >2020-04-14 09:46:12,872+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
>> >execute:
>> >('/usr/sbin/ip', 'addr'), executable='None', cwd='None', env=None
>> >
>> >2020-04-14 09:46:12,876+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
>> >execute-result: ('/usr/sbin/ip', 'addr'), rc=0
>> >
>> >2020-04-14 09:46:12,876+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.execute:921
>> >execute-output: ('/usr/sbin/ip', 'addr') stdout:
>> >
>> >1: lo: mtu 65536 qdisc noqueue state UNKNOWN
>> >group
>> >default qlen 1000
>> >
>> >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> >
>> >inet 127.0.0.1/8 scope host lo
>> >
>> > valid_lft forever preferred_lft forever
>> >
>> >inet6 ::1/128 scope host
>> >
>> > valid_lft forever preferred_lft forever
>> >
>> >2: eno1: mtu 1500 qdisc mq master
>> >ovirtmgmt state UP group default qlen 1000
>> >
>> >link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
>> >
>> >3: eno2: mtu 1500 qdisc mq state
>> >DOWN
>> >group default qlen 1000
>> >
>> >link/ether ac:1f:6b:bc:32:6b brd ff:ff:ff:ff:ff:ff
>> >
>> >4: ovs-system: mtu 1500 qdisc noop state DOWN
>> >group
>> >default qlen 1000
>> >
>> >link/ether 02:e6:e2:80:93:8d brd ff:ff:ff:ff:ff:ff
>> >
>> >5: br-int: mtu 1500 qdisc noop state DOWN
>group
>> >default qlen 1000
>> >
>> >link/ether 8a:26:44:50:ee:4a brd ff:ff:ff:ff:ff:ff
>> >
>> >21: ovirtmgmt: mtu 1500 qdisc
>noqueue
>> >state UP group default qlen 1000
>> >
>> >link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
>> >
>> >inet 192.168.1.61/24 brd 192.168.1.255 scope global ovirtmgmt
>> >
>> > valid_lft forever preferred_lft forever
>> >
>> >inet6 fe80::ae1f:6bff:febc:326a/64 scope link
>> >
>> > valid_lft forever preferred_lft forever
>> >
>> >22: ;vdsmdummy;: mtu 1500 qdisc noop state
>DOWN
>> >group
>> >default qlen 1000
>> >
>> >link/ether 3a:02:7b:7d:b3:2a brd ff:ff:ff:ff:ff:ff
>> >
>> >
>> >2020-04-14 09:46:12,876+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge plugin.execute:926
>> >execute-output: ('/usr/sbin/ip', 'addr') stderr:
>> >
>> >
>> >
>> >2020-04-14 09:46:12,877+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge
>> >hostname.getLocalAddresses:251
>> >addresses: [u'192.168.1.61', u'fe80::ae1f:6bff:febc:326a']
>> >
>> >2020-04-14 09:46:12,877+ DEBUG
>> >otopi.plugins.gr_he_common.network.bridge hostname.test_hostname:464
>> >test_hostname exception
>> >
>> >Traceback (most recent call last):
>> >
>> >File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py",
>> >line
>> >460, in test_hostname
>> >
>> >not_local_text,
>> >
>> >File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/h
[ovirt-users] Get OAuth token locally without password?
I'm working on a cron job to run on the engine to do some tasks via the API. Is there a way I can get an API OAuth token created without actually storing a password? For example, some script that can be run to directly create a session in the database and return the token. Obviously this _can_ be done, it's a matter of knowing the right bits to do (so basically wondering if that has already been written). I only have internal users, so no external authentication store available. -- Chris Adams ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWQH2JZ72H4XXOURHOYQH3HGQRDSDKPH/
[ovirt-users] Re: ovirt-engine unresponsive - how to rescue?
Hmmm, we're not using ipv6. Is that the issue?
On Tue, Apr 14, 2020 at 3:56 PM Strahil Nikolov
wrote:
> On April 14, 2020 1:27:24 PM GMT+03:00, Shareef Jalloq <
> shar...@jalloq.co.uk> wrote:
> >Right, I've given up on recovering the HE so want to try and redeploy
> >it.
> >There doesn't seem to be enough information to debug why the
> >broker/agent
> >won't start cleanly.
> >
> >In running 'hosted-engine --deploy', I'm seeing the following error in
> >the
> >setup validation phase:
> >
> >2020-04-14 09:46:08,922+ DEBUG otopi.plugins.otopi.dialog.human
> >dialog.__logString:204 DIALOG:SEND Please provide the
> >hostname of this host on the management network
> >[ovirt-node-00.phoelex.com]:
> >
> >
> >2020-04-14 09:46:12,831+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge
> >hostname.getResolvedAddresses:432
> >getResolvedAddresses: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
> >
> >2020-04-14 09:46:12,832+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge
> >hostname._validateFQDNresolvability:289 ovirt-node-00.phoelex.com
> >resolves
> >to: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
> >
> >2020-04-14 09:46:12,832+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
> >execute:
> >['/usr/bin/dig', '+noall', '+answer', 'ovirt-node-00.phoelex.com',
> >'ANY'],
> >executable='None', cwd='None', env=None
> >
> >2020-04-14 09:46:12,871+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
> >execute-result: ['/usr/bin/dig', '+noall', '+answer', '
> >ovirt-node-00.phoelex.com', 'ANY'], rc=0
> >
> >2020-04-14 09:46:12,872+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.execute:921
> >execute-output: ['/usr/bin/dig', '+noall', '+answer', '
> >ovirt-node-00.phoelex.com', 'ANY'] stdout:
> >
> >ovirt-node-00.phoelex.com. 86400 IN A 192.168.1.61
> >
> >
> >2020-04-14 09:46:12,872+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.execute:926
> >execute-output: ['/usr/bin/dig', '+noall', '+answer', '
> >ovirt-node-00.phoelex.com', 'ANY'] stderr:
> >
> >
> >
> >2020-04-14 09:46:12,872+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
> >execute:
> >('/usr/sbin/ip', 'addr'), executable='None', cwd='None', env=None
> >
> >2020-04-14 09:46:12,876+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
> >execute-result: ('/usr/sbin/ip', 'addr'), rc=0
> >
> >2020-04-14 09:46:12,876+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.execute:921
> >execute-output: ('/usr/sbin/ip', 'addr') stdout:
> >
> >1: lo: mtu 65536 qdisc noqueue state UNKNOWN
> >group
> >default qlen 1000
> >
> >link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >
> >inet 127.0.0.1/8 scope host lo
> >
> > valid_lft forever preferred_lft forever
> >
> >inet6 ::1/128 scope host
> >
> > valid_lft forever preferred_lft forever
> >
> >2: eno1: mtu 1500 qdisc mq master
> >ovirtmgmt state UP group default qlen 1000
> >
> >link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
> >
> >3: eno2: mtu 1500 qdisc mq state
> >DOWN
> >group default qlen 1000
> >
> >link/ether ac:1f:6b:bc:32:6b brd ff:ff:ff:ff:ff:ff
> >
> >4: ovs-system: mtu 1500 qdisc noop state DOWN
> >group
> >default qlen 1000
> >
> >link/ether 02:e6:e2:80:93:8d brd ff:ff:ff:ff:ff:ff
> >
> >5: br-int: mtu 1500 qdisc noop state DOWN group
> >default qlen 1000
> >
> >link/ether 8a:26:44:50:ee:4a brd ff:ff:ff:ff:ff:ff
> >
> >21: ovirtmgmt: mtu 1500 qdisc noqueue
> >state UP group default qlen 1000
> >
> >link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
> >
> >inet 192.168.1.61/24 brd 192.168.1.255 scope global ovirtmgmt
> >
> > valid_lft forever preferred_lft forever
> >
> >inet6 fe80::ae1f:6bff:febc:326a/64 scope link
> >
> > valid_lft forever preferred_lft forever
> >
> >22: ;vdsmdummy;: mtu 1500 qdisc noop state DOWN
> >group
> >default qlen 1000
> >
> >link/ether 3a:02:7b:7d:b3:2a brd ff:ff:ff:ff:ff:ff
> >
> >
> >2020-04-14 09:46:12,876+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge plugin.execute:926
> >execute-output: ('/usr/sbin/ip', 'addr') stderr:
> >
> >
> >
> >2020-04-14 09:46:12,877+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge
> >hostname.getLocalAddresses:251
> >addresses: [u'192.168.1.61', u'fe80::ae1f:6bff:febc:326a']
> >
> >2020-04-14 09:46:12,877+ DEBUG
> >otopi.plugins.gr_he_common.network.bridge hostname.test_hostname:464
> >test_hostname exception
> >
> >Traceback (most recent call last):
> >
> >File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py",
> >line
> >460, in test_hostname
> >
> >not_local_text,
> >
> >File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py",
> >line
> >342, in _validateFQDNresolvability
> >
> >addresses=resolvedAddressesAsString
> >
> >RuntimeError: ovirt-node-00.phoelex.com resolves to 64:ff9b::c0a8:13d
> >192.168.1.61 and not all of them can b
[ovirt-users] Re: ovirt-engine unresponsive - how to rescue?
On April 14, 2020 1:27:24 PM GMT+03:00, Shareef Jalloq
wrote:
>Right, I've given up on recovering the HE so want to try and redeploy
>it.
>There doesn't seem to be enough information to debug why the
>broker/agent
>won't start cleanly.
>
>In running 'hosted-engine --deploy', I'm seeing the following error in
>the
>setup validation phase:
>
>2020-04-14 09:46:08,922+ DEBUG otopi.plugins.otopi.dialog.human
>dialog.__logString:204 DIALOG:SEND Please provide the
>hostname of this host on the management network
>[ovirt-node-00.phoelex.com]:
>
>
>2020-04-14 09:46:12,831+ DEBUG
>otopi.plugins.gr_he_common.network.bridge
>hostname.getResolvedAddresses:432
>getResolvedAddresses: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
>
>2020-04-14 09:46:12,832+ DEBUG
>otopi.plugins.gr_he_common.network.bridge
>hostname._validateFQDNresolvability:289 ovirt-node-00.phoelex.com
>resolves
>to: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
>
>2020-04-14 09:46:12,832+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
>execute:
>['/usr/bin/dig', '+noall', '+answer', 'ovirt-node-00.phoelex.com',
>'ANY'],
>executable='None', cwd='None', env=None
>
>2020-04-14 09:46:12,871+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
>execute-result: ['/usr/bin/dig', '+noall', '+answer', '
>ovirt-node-00.phoelex.com', 'ANY'], rc=0
>
>2020-04-14 09:46:12,872+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.execute:921
>execute-output: ['/usr/bin/dig', '+noall', '+answer', '
>ovirt-node-00.phoelex.com', 'ANY'] stdout:
>
>ovirt-node-00.phoelex.com. 86400 IN A 192.168.1.61
>
>
>2020-04-14 09:46:12,872+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.execute:926
>execute-output: ['/usr/bin/dig', '+noall', '+answer', '
>ovirt-node-00.phoelex.com', 'ANY'] stderr:
>
>
>
>2020-04-14 09:46:12,872+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813
>execute:
>('/usr/sbin/ip', 'addr'), executable='None', cwd='None', env=None
>
>2020-04-14 09:46:12,876+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
>execute-result: ('/usr/sbin/ip', 'addr'), rc=0
>
>2020-04-14 09:46:12,876+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.execute:921
>execute-output: ('/usr/sbin/ip', 'addr') stdout:
>
>1: lo: mtu 65536 qdisc noqueue state UNKNOWN
>group
>default qlen 1000
>
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>
>inet 127.0.0.1/8 scope host lo
>
> valid_lft forever preferred_lft forever
>
>inet6 ::1/128 scope host
>
> valid_lft forever preferred_lft forever
>
>2: eno1: mtu 1500 qdisc mq master
>ovirtmgmt state UP group default qlen 1000
>
>link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
>
>3: eno2: mtu 1500 qdisc mq state
>DOWN
>group default qlen 1000
>
>link/ether ac:1f:6b:bc:32:6b brd ff:ff:ff:ff:ff:ff
>
>4: ovs-system: mtu 1500 qdisc noop state DOWN
>group
>default qlen 1000
>
>link/ether 02:e6:e2:80:93:8d brd ff:ff:ff:ff:ff:ff
>
>5: br-int: mtu 1500 qdisc noop state DOWN group
>default qlen 1000
>
>link/ether 8a:26:44:50:ee:4a brd ff:ff:ff:ff:ff:ff
>
>21: ovirtmgmt: mtu 1500 qdisc noqueue
>state UP group default qlen 1000
>
>link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
>
>inet 192.168.1.61/24 brd 192.168.1.255 scope global ovirtmgmt
>
> valid_lft forever preferred_lft forever
>
>inet6 fe80::ae1f:6bff:febc:326a/64 scope link
>
> valid_lft forever preferred_lft forever
>
>22: ;vdsmdummy;: mtu 1500 qdisc noop state DOWN
>group
>default qlen 1000
>
>link/ether 3a:02:7b:7d:b3:2a brd ff:ff:ff:ff:ff:ff
>
>
>2020-04-14 09:46:12,876+ DEBUG
>otopi.plugins.gr_he_common.network.bridge plugin.execute:926
>execute-output: ('/usr/sbin/ip', 'addr') stderr:
>
>
>
>2020-04-14 09:46:12,877+ DEBUG
>otopi.plugins.gr_he_common.network.bridge
>hostname.getLocalAddresses:251
>addresses: [u'192.168.1.61', u'fe80::ae1f:6bff:febc:326a']
>
>2020-04-14 09:46:12,877+ DEBUG
>otopi.plugins.gr_he_common.network.bridge hostname.test_hostname:464
>test_hostname exception
>
>Traceback (most recent call last):
>
>File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py",
>line
>460, in test_hostname
>
>not_local_text,
>
>File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py",
>line
>342, in _validateFQDNresolvability
>
>addresses=resolvedAddressesAsString
>
>RuntimeError: ovirt-node-00.phoelex.com resolves to 64:ff9b::c0a8:13d
>192.168.1.61 and not all of them can be mapped to non loopback devices
>on
>this host
>
>2020-04-14 09:46:12,884+ ERROR
>otopi.plugins.gr_he_common.network.bridge dialog.queryEnvKey:120 Host
>name
>is not valid: ovirt-node-00.phoelex.com resolves to 64:ff9b::c0a8:13d
>192.168.1.61 and not all of them can be mapped to non loopback devices
>on
>this host
>
>The node I'm running on has an IP address of .61 and resolves
>correctly.
>
>On Fri, Apr 10, 2020 at 12:55 PM Sharee
[ovirt-users] Re: ovirt-engine unresponsive - how to rescue?
Right, I've given up on recovering the HE so want to try and redeploy it.
There doesn't seem to be enough information to debug why the broker/agent
won't start cleanly.
In running 'hosted-engine --deploy', I'm seeing the following error in the
setup validation phase:
2020-04-14 09:46:08,922+ DEBUG otopi.plugins.otopi.dialog.human
dialog.__logString:204 DIALOG:SEND Please provide the
hostname of this host on the management network [ovirt-node-00.phoelex.com]:
2020-04-14 09:46:12,831+ DEBUG
otopi.plugins.gr_he_common.network.bridge hostname.getResolvedAddresses:432
getResolvedAddresses: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
2020-04-14 09:46:12,832+ DEBUG
otopi.plugins.gr_he_common.network.bridge
hostname._validateFQDNresolvability:289 ovirt-node-00.phoelex.com resolves
to: set(['64:ff9b::c0a8:13d', '192.168.1.61'])
2020-04-14 09:46:12,832+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813 execute:
['/usr/bin/dig', '+noall', '+answer', 'ovirt-node-00.phoelex.com', 'ANY'],
executable='None', cwd='None', env=None
2020-04-14 09:46:12,871+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
execute-result: ['/usr/bin/dig', '+noall', '+answer', '
ovirt-node-00.phoelex.com', 'ANY'], rc=0
2020-04-14 09:46:12,872+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.execute:921
execute-output: ['/usr/bin/dig', '+noall', '+answer', '
ovirt-node-00.phoelex.com', 'ANY'] stdout:
ovirt-node-00.phoelex.com. 86400 IN A 192.168.1.61
2020-04-14 09:46:12,872+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.execute:926
execute-output: ['/usr/bin/dig', '+noall', '+answer', '
ovirt-node-00.phoelex.com', 'ANY'] stderr:
2020-04-14 09:46:12,872+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:813 execute:
('/usr/sbin/ip', 'addr'), executable='None', cwd='None', env=None
2020-04-14 09:46:12,876+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.executeRaw:863
execute-result: ('/usr/sbin/ip', 'addr'), rc=0
2020-04-14 09:46:12,876+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.execute:921
execute-output: ('/usr/sbin/ip', 'addr') stdout:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: mtu 1500 qdisc mq master
ovirtmgmt state UP group default qlen 1000
link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
3: eno2: mtu 1500 qdisc mq state DOWN
group default qlen 1000
link/ether ac:1f:6b:bc:32:6b brd ff:ff:ff:ff:ff:ff
4: ovs-system: mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 02:e6:e2:80:93:8d brd ff:ff:ff:ff:ff:ff
5: br-int: mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 8a:26:44:50:ee:4a brd ff:ff:ff:ff:ff:ff
21: ovirtmgmt: mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether ac:1f:6b:bc:32:6a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.61/24 brd 192.168.1.255 scope global ovirtmgmt
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:febc:326a/64 scope link
valid_lft forever preferred_lft forever
22: ;vdsmdummy;: mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 3a:02:7b:7d:b3:2a brd ff:ff:ff:ff:ff:ff
2020-04-14 09:46:12,876+ DEBUG
otopi.plugins.gr_he_common.network.bridge plugin.execute:926
execute-output: ('/usr/sbin/ip', 'addr') stderr:
2020-04-14 09:46:12,877+ DEBUG
otopi.plugins.gr_he_common.network.bridge hostname.getLocalAddresses:251
addresses: [u'192.168.1.61', u'fe80::ae1f:6bff:febc:326a']
2020-04-14 09:46:12,877+ DEBUG
otopi.plugins.gr_he_common.network.bridge hostname.test_hostname:464
test_hostname exception
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py", line
460, in test_hostname
not_local_text,
File "/usr/lib/python2.7/site-packages/ovirt_setup_lib/hostname.py", line
342, in _validateFQDNresolvability
addresses=resolvedAddressesAsString
RuntimeError: ovirt-node-00.phoelex.com resolves to 64:ff9b::c0a8:13d
192.168.1.61 and not all of them can be mapped to non loopback devices on
this host
2020-04-14 09:46:12,884+ ERROR
otopi.plugins.gr_he_common.network.bridge dialog.queryEnvKey:120 Host name
is not valid: ovirt-node-00.phoelex.com resolves to 64:ff9b::c0a8:13d
192.168.1.61 and not all of them can be mapped to non loopback devices on
this host
The node I'm running on has an IP address of .61 and resolves correctly.
On Fri, Apr 10, 2020 at 12:55 PM Shareef Jalloq
wrote:
> Where should I be checking if there are any files/folder not owned by
> vdsm:kvm? I checked on the mount the HA sits on and it's fine.
>
> How would I go about checking vdsm can access those images? If I run
