GlusterFS+Virt
by antony.parkin＠graidtech.com
Hi,
Could somebody comment on storage options i.e Gluster or Ceph and when to use each one?
Looking for an architecture which is fully redundant, both at the hypervisor level and at the storage level so needs to include data replication.
thx
1 year
VDSM certs expired, manual renewal not working
by cen
Hi
Our VDSM certs have expired, both hosts are unassigned and can't be put
into maintenance from UI.
vdsm-client is not working, times out even with --insecure flag. Does
host and port need to be specified when run locally or should defaults work?
Error in console events is: Get Host Capabilities Failed: PKIX path
validation failed...
I followed a RHV guide for this exact situation and generated new vdsm
certificate using the ovirt-engine CA.
The new cert seems identical to the old one, everything matches (algos,
extensions, CA, CN, SAN etc) just new date.
After restarting libvirtd and vdsmd on the host with new cert in place
the host is still not reachable.
However, error message is now slightly different:
get Host Capabilities failed: Received fatal error: certificate_expired
Cert was replaced in the following locations:
/etc/pki/vdsm/certs/vdsmcert.pem
/etc/pki/vdsm/libvirt-spice/server-cert.pem
/etc/pki/libvirt/clientcert.pem
Is there another location missing? What else can I try?
All help appreciated in advance
1 year
ovirt 4.5.4 install failure
by Selçuk N
Hello all,
I tried to install ovirt 4.5.4 on ovirt node install.
*hosted-engine --deploy*
After this step installation is stuck.
*[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Wait for the host to be
up]*
I checked the log file and details below.
Apr 20 22:10:18 ovirt3 ansible-async_wrapper.py[41856]: 41857 still running
(85405)
Apr 20 22:10:19 ovirt3 python3[51367]: ansible-ovirt_host_info Invoked with
pattern=name=ovirt3.44c.net auth={'token':
'eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOTXdyenhDY284eERxZVlLaFRhWG5xblVpV0lFNDVBM2VmRzhXdndTaDVBIn0.eyJleHAiOjE2ODIwMzQzNzgsImlhdCI6MTY4MjAxNzA5OCwianRpIjoiODdjNDAwZTItNDZiMS00NmY1LTk2MWMtMWJhMDA3MDAxOGQxIiwiaXNzIjoiaHR0cHM6Ly9lbmcuNDRjLm5ldC9vdmlydC1lbmdpbmUtYXV0aC9yZWFsbXMvb3ZpcnQtaW50ZXJuYWwiLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiZmFiMDNmM2UtODVmZS00YjQ5LWE5ZWItZTExODRjOTYzYzdjIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoib3ZpcnQtZW5naW5lLWludGVybmFsIiwic2Vzc2lvbl9zdGF0ZSI6IjYwOWJiMmMxLTJkNTItNDc4Zi1hYzg2LWMyMjVlNTVmYTMwNyIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9lbmcuNDRjLm5ldCJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiZGVmYXVsdC1yb2xlcy1vdmlydC1pbnRlcm5hbCIsIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6Im92aXJ0LWFwcC1hcGkgZW1haWwgb3ZpcnQtZXh0PXRva2VuLWluZm86YXV0aHotc2VhcmNoIG92aXJ0LWV4dD10b2tlbi1pbmZvOnZhbGlkYXRlIG92aXJ0LWV4dD10b2tlbi1pbmZvOnB1YmxpYy1hdXRoei1zZWFyY2ggcHJvZmlsZSBvdmlydC1leHQ9dG9rZW46cGFzc3dvcmQtYWNjZXNzIiwic2lkIjoiNjA5YmIyYzEtMmQ1Mi00NzhmLWFjODYtYzIyNWU1NWZhMzA3IiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJncm91cHMiOlsiL292aXJ0LWFkbWluaXN0cmF0b3IiXSwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW5Ab3ZpcnQiLCJlbWFpbCI6ImFkbWluQGxvY2FsaG9zdCJ9.e47PgAtt_Sj-_4IQ8OIQynAV_AvrOfzalhwi1VJapCQB_sdQqxd0jIH7JGVM1a4TGEJb6E5ffTXBocqQabe5pBPIv4kqsgU1iadyTjjDjZ1elECnahPf6lrze-8hEO92GKFOepGLQ-iu7gRilAknvaXhoc309G1hyQvnP4Q-syffw6Eoo4RmgnLnztnPzsxBtGgkZrzAwFfTNDtdS2uj5lvzzAEIfvDPRFTjJhYwKXSx2hC1lnhXnmv1XEtCfXZZ3qqarXw8GAvOQbe10xklm5UAtu--C8NX32DE6659QtEqk-5g52SdFWIic_OlZ5-obHn3jOllo8qnsb-6mfEn_w',
'url': 'https://eng.44c.net/ovirt-engine/api', 'ca_file': None, 'insecure':
True, 'timeout': 0, 'compress': True, 'kerberos': False, 'headers': None,
'hostname': None, 'username': None, 'password': None} fetch_nested=False
nested_attributes=[] follow=[] all_content=False cluster_version=None
*Apr 20 22:10:22 ovirt3 journal[47971]: Invalid value '-1' for 'cpu.max':
Invalid argument*
Apr 20 22:10:23 ovirt3 sssd_kcm[50811]: Shutting down (status = 0)
Apr 20 22:10:23 ovirt3 systemd[1]: sssd-kcm.service: Deactivated
successfully.
Apr 20 22:10:23 ovirt3 ansible-async_wrapper.py[41856]: 41857 still running
(85400)
Apr 20 22:10:28 ovirt3 ansible-async_wrapper.py[41856]: 41857 still running
(85395)
What did I did wrong?
Thanks.
1 year
checking engine vm status during global maintenance
by Alexey Valkov
Hi all,
I tried to check engine status (via hosted-engine --vm-status) during global maintenance in oVirt 4.5.1 and discovered that
it showed me status as it was just before entering global maintenance.
Is it by design? And HA agent doesn't monitor and therefore doesn't update Engine VM status?
If I remember right in oVirt 4.2 hosted-engine --vm-status showed correct status of Engine VM regardless of Global maintenance.
I shutted down the engine but the output of hosted-engine --vm-status was
Engine status : {"vm": "up", "health": "good", "detail": "Up"}
Notice
!! Cluster is in GLOBAL MAINTENANCE mode !!
existed in the output.
Host timestamp and extra metadata was up to date.
All rest info looked good.
Thi is my second attempt to ask the question (first was at 24/04 and still is being moderated).
--
Best regards
Alexei
1 year
richiesta accesso Zanata
by Rosario Grasso
Buongiorno,
la presente per richiedere l'accesso a Zanata in lingua inglese e se
possibile anche in italiano.
Saluti,
RG
1 year
Disable SSL for ovirt-ha-broker?
by phil.gardnerjr＠gmail.com
I have a neglected oVirt 4.3 cluster that consists of two hosts with a hosted engine. Unfortunately, the host SSL certificates on both hosts are expired, and now the hosted engine is down from a power loss event.
I don't see a way to get ovirt-ha-broker functioning again if the vdsm certificates are expired, since I can't get the hosted engine VM to start in order to generate new host certificates.
My sledgehammer approach was to just disable SSL in the configuration for vdsm and libvirt, but I can't seem to figure out how to disable SSL for ovirt-ha-broker. Is this possible? I don't know what else to try.
I figure if I can just get the hosted-engine back up, and I can maybe proceed with getting one of the hosts back up and functional in some way, and maybe getting the single VM that I am concerned about started up.
If the hosted engine isn't recoverable, is it possible to get another VM up and running with just standard kvm/libvirt/virsh if I still have access to the storage?
1 year
