Nodes in CentOS 8.3 and oVirt 4.4.3.12-1.el8 but not able to update cluster version
by Gianluca Cecchi
Hello,
my engine is 4.4.3.12-1.el8 and my 3 oVirt nodes (based on plain CentOS due
to megaraid_sas kernel module needed) have been updated, bringing them to
CentOS 8.3.
But if I try to put cluster into 4.5 I get the error:
"
Error while executing action: Cannot change Cluster Compatibility Version
to higher version when there are active Hosts with lower version.
-Please move Host ov300, ov301, ov200 with lower version to maintenance
first.
"
Do I have to wait until final 4.4.4 or what is the problem?
Does 4.5 gives anything more apart the second number... (joking..)?
On nodes:
Software
OS Version: RHEL - 8.3 - 1.2011.el8
OS Description: CentOS Linux 8
Kernel Version: 4.18.0 - 240.1.1.el8_3.x86_64
KVM Version: 4.2.0 - 34.module_el8.3.0+555+a55c8938
LIBVIRT Version: libvirt-6.0.0-28.module_el8.3.0+555+a55c8938
VDSM Version: vdsm-4.40.35.1-1.el8
SPICE Version: 0.14.3 - 3.el8
GlusterFS Version: [N/A]
CEPH Version: librbd1-12.2.7-9.el8
Open vSwitch Version: [N/A]
Nmstate Version: nmstate-0.3.6-2.el8
Kernel Features: MDS: (Vulnerable: Clear CPU buffers attempted, no
microcode; SMT vulnerable), L1TF: (Mitigation: PTE Inversion; VMX:
conditional cache flushes, SMT vulnerable), SRBDS: (Not affected),
MELTDOWN: (Mitigation: PTI), SPECTRE_V1: (Mitigation: usercopy/swapgs
barriers and __user pointer sanitization), SPECTRE_V2: (Mitigation: Full
generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB
filling), ITLB_MULTIHIT: (KVM: Mitigation: Split huge pages),
TSX_ASYNC_ABORT: (Not affected), SPEC_STORE_BYPASS: (Mitigation:
Speculative Store Bypass disabled via prctl and seccomp)
VNC Encryption: Disabled
FIPS mode enabled: Disabled
Gianluca
4 years
oVirt 4.4: Self-hosted engine deployment fails with backup restore from 4.3 engine
by Oliver Leinfelder
Hi there,
I'm a bit puzzled about an possible upgrade paths from a 4.3 cluster to
version 4.4 in a self-hosted engine environment.
My idea was:
Set up a new host with a clean ovirt node 4.4 installation, then deploy the
hosted engine on this with a restored backup from the production cluster
and go from there.
This however fails with the following error:
2020-05-27 00:17:08,886+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils
ansible_utils._process_output:103 {'msg': 'non-zero return code', 'cmd':
['engine-setup', '--accept-defaults',
'--config-append=/root/ovirt-engine-answers'], 'stdout': "[ INFO ] Stage:
Initializing\n[ INFO ] Stage: Environment setup\n C
onfiguration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf,
/etc/ovirt-engine-setup.conf.d/10-packaging.conf,
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf,
/root/ovirt-engine-answers\n Log file:
/var/log/ovirt-engine/setup/ovirt-engine-setup-20200527001657-fyeueu.log\n
Version: otop
i-1.9.1 (otopi-1.9.1-1.el8)\n[ INFO ] DNF Downloading 1 files, 0.00KB\n[
INFO ] DNF Downloaded CentOS-8 - AppStream\n[ INFO ] DNF Downloading 1
files, 0.00KB\n[ INFO ] DNF Downloaded CentOS-8 - Base\n[ INFO ] DNF
Downloading 1 files, 0.00KB\n
[...]
... anwsers from backup config follow ....
[...]
2020-05-27 00:17:12,396+0200 DEBUG otopi.context context._executeMethod:145
method exception
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
_executeMethod
method['method']()
File
"/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/misc.py",
line 403, in _closeup
r = ah.run()
File
"/usr/lib/python3.6/site-packages/ovirt_hosted_engine_setup/ansible_utils.py",
line 229, in run
raise RuntimeError(_('Failed executing ansible-playbook'))
Is this approach (restoring from 4.3) generally supposed to work? If not,
what is the appropriate upgrade path?
Thank you!
Regards
Oli
4 years
Deploy hosted engine from backup fails
by JCampos
Command to execute backup:
#engine-backup --mode=backup --file=backup1 --log=backup1.log
Command to restore backup:
#hosted-engine --deploy --restore-from-file=backup1
Error:
2020-12-09 22:26:25,679+0000 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:107 fatal: [localhost]: FAILED! => {"changed": false, "msg": "Available memory ( {'failed': False, 'changed': False, 'ansible_facts': {u'max_mem': u'33211'}}MB ) is less then the minimal requirement (4096MB). Be aware that 512MB is reserved for the host and cannot be allocated to the engine VM."}
Ovirt version:
4.3.10.4-1.el7
# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
Memory available:
#free -m
total used free shared buff/cache available
Mem: 64132 30478 494 145 33158 32961
Swap: 16383 0 16383
Is there a way to ignore this check?
4 years
Another illegal disk snapshot problem!
by Joseph Goldman
Hi List,
oVirt 4.3
I know there have been threads about this before - but I am unable to
find the exact scenario I am facing.
I have a VM with 3 snapshots - Active, and 2 dated ones (technically
created by vProtect)
After trying to do a fresh snapshot in the GUI it failed out and
marked one of the old snapshot disks as 'illegal' - then the other tried
to follow suit.
I tried 'unlocking' the entity using the unlock_entity.sh tool but any
action reverts them back to illegal.
Following previous advice - I can see the VDSM status is all showing
LEGAL:
image: 23710238-07c2-46f3-96c0-9061fe1c3e0d
- *c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1*
*status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type:
SPARSE, capacity: 107374182400, truesize: 18402942976**
*
- *a6d4533b-b0b0-475d-a436-26ce99a38d94**
** status: OK, voltype: INTERNAL, format: COW, legality:
LEGAL, type: SPARSE, capacity: 107374182400, truesize: 21521768448*
- 4b6f7ca1-b70d-4893-b473-d8d30138bb6b
status: OK, voltype: LEAF, format: COW, legality: LEGAL,
type: SPARSE, capacity: 107374182400, truesize: 12617457664
The 2 bold entries are the 'illegal' snapshots.
Looking in the DB see's:
select
image_guid,parentid
,imagestatus
,vm_snapshot_id
,volume_type
,volume_format
,active
from images
where image_group_id='23710238-07c2-46f3-96c0-9061fe1c3e0d';
image_guid | parentid |
imagestatus | vm_snapshot_id | volume_type | volume_format |
active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
4b6f7ca1-b70d-4893-b473-d8d30138bb6b |
a6d4533b-b0b0-475d-a436-26ce99a38d94 | 1 |
d5044ae5-dc48-4700-9e46-d61e676c73fc | 2 | 4 | t
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1 |
00000000-0000-0000-0000-000000000000 | 4 |
57337968-28da-4b03-ac40-134a347d8c11 | 2 | 5 | f
a6d4533b-b0b0-475d-a436-26ce99a38d94 |
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1 | 4 |
d2d82724-9fe7-452c-a114-f8d70b555520 | 2 | 4 | f
So from here previous advice has been to do things such as delete the
snapshot/disk etc but thats when they showed as illegal status. I also
notice the Active Image is not the same image that has a parentid of all
00000's so im not sure on the process of possibly deleting the other
snapshots and disks cleanly and/or safely.
Deleting or any tasks in the gui 100% fails and its at a point that if I
shut down the (critical) VM it will not come back on because of these
status'.
On top of this what is a good way to take a clean, manual backup of
current in use disk before I start playing with this in case worse comes
to worse I have to try build it as a new server (As at this point I
can't trust my vProtect backups)
Any help appreciated.
Thanks,
Joe
4 years
ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom
by 3c.monitor＠gruppofilippetti.it
Hi all.
I've deployed a VM from a corrupted template (it's disk is missing, but I've checked it later...).
My Software Version is:4.3
Now, I have an unmanaged VM in inventory and unable to remove it too.
It's reference is "locked image".
I've restarted ovirt-engine many times on self-hosted engine and hosts too, but no benefits.
So, what's now?
I've also consulted: https://access.redhat.com/solutions/396753
but still no results.
No tasks or items results to be "locked"...
Any other ideas?
Thanks a lot.
4 years
Re: difference between CPU server and client family
by Vinícius Ferrão
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77(a)gmail.com> wrote:
4 years
Turkey Standart Time
by ozmen62＠hotmail.com
Hi,
We've figured out there is no Turkish time zone on "Hardware Clock Time Offset" when we were trying sysprep
it causes some problems on GPO applyment, Outlook, Skype etc. connections in AD environment
Is there any cli options we can add this?
If you take this as an future request we'll appreciate
4 years
Re: Another illegal disk snapshot problem!
by Joseph Goldman
On top of this, looks like this redhat article may have the solution but
I cant access it, any help someone?
https://access.redhat.com/solutions/2852341
Thanks.
On 9/12/2020 10:51 pm, Joseph Goldman wrote:
> This looks to be the problem:
>
> 2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START
> merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d',
> u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID':
> u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID':
> u'e2540c6a-33c7-4ac7-b2a2-175cf51994c2'},
> baseVolUUID=u'c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1',
> topVolUUID=u'a6d4533b-b0b0-475d-a436-26ce99a38d94', bandwidth=u'0',
> jobUUID=u'ff193892-356b-4db8-b525-e543e8e69d6a')
> from=::ffff:192.168.5.10,56030,
> flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
> vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:48)
>
> 2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] FINISH merge
> return={'status': {'message': 'Drive image file could not be found',
> 'code': 13}} from=::ffff:192.168.5.10,56030,
> flow_id=c149117a-1080-424c-85d8-3de2103ac4ae,
> vmId=2a0df965-8434-4074-85cf-df12a69648e7 (api:54)
>
>
> Physical disk file does not appear to be there. Why would it still be
> in the
> On 8/12/2020 11:15 pm, Benny Zlotnik wrote:
>>> [root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR
>> grepping error is ok, but it does not show the reason for the failure,
>> which will probably be on the vdsm host (you can use flow_id
>> 9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
>> Need to see the underlying error causing: VDSGenericException:
>> VDSErrorException: Failed to SnapshotVDS, error =
>> Snapshot failed, code = 48
>>
>>> Using unlock_entity.sh -t all sets the status back to 1 (confirmed in
>>> DB) and then trying to create does not change it back to illegal, but
>>> trying to delete that snapshot fails and sets it back to 4.
>> I see, can you share the removal failure log (similar information as
>> requested above)
>>
>> regarding backup, I don't have a good answer, hopefully someone else
>> has suggestions
>> _______________________________________________
>> Users mailing list --users(a)ovirt.org
>> To unsubscribe send an email tousers-leave(a)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/MJ...
>
4 years
