[ovirt-users] Re: uploading ang .OVA image

[Arik Hadas]

On Thu, Feb 4, 2021 at 3:49 PM Gianluca Cecchi 
wrote:

> On Thu, Feb 4, 2021 at 2:12 PM Ariez Ahito 
> wrote:
>
>> hi guys, i just want to ask if you can just upload an .OVA file to ovirt
>> just like uploading ISO?
>> without setting up virt-v2v and export domain?
>>
> thanks
>>
>>
> Put the OVA file on one of your hypervisors in a certain path
> Go to Web Admin Gui --> Compute --> Virtual Machines
> Select the three vertical dots at top right (near the "Migrate" button)
> and "Import"
> Select "Virtual Appliance (OVA)" as source and choose the host and File
> Path where you previously put the OVA
> select the VMs to import using the horizontal arrows
>
> In theory it should be supported oVirt as internal format and only vSphere
> as external format of OVA.
> But as far as your OVA complies with what oVirt expects, it could work
> too.
>

Yeah.
I'd say that with vSphere-compliant OVAs one needs to do the above
mentioned steps because we have to invoke virt-v2v (btw, there's no need
for an export domain).
But if you have an OVA that was produced by oVirt at hand, you can
alternatively upload it as the following script does:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_ova_as_vm_or_template.py


>
> Gianluca
>
>
> ___
> 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/IUA6QJGTZYHVAHIDUBEEGCTHCIR3CI2R/
>
___
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/7SD2ARW5IAWHIO47QHUIVCT3CSAEKBXK/

[ovirt-users] Re: Upgrade from 4.4.3 to 4.4.4 (oVirt Node) - vdsmd.service/start failed with result 'dependency'

[nikkognt]

Hi,
I add that in the first host in the directory / etc / openvswitch there are 
files but in the second host that has problems in the same directory is empty.
How can I do?
Thanks so much
___
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/RU6WAANV7CC4KDW733PM6GXUZU5O5ITQ/

[ovirt-users] ovirt AD issue

[Jason Keltz]

A while back, I had reconfigured my oVirt engine to auth based on my 
Samba AD server, and everything was working perfectly fine. oVirt 
version 4.3.10.4-1.


Today, I tried to login with my account into engine and I see:

server_error: The connection reader was unable to successfully complete 
TLS negotiation: 
SSLHandshakeException(sun.security.validator.ValidatorException: No 
trusted certificate found), ldapSDKVersion=4.0.7, 
revision=b28fb50058dfe2864171df2448ad2ad2b4c2ad58


I recently added a secondary domain controller with Samba, and I realize 
now that there is an error.  Since I didn't pre-initialize samba with a 
TLS certificate, it generated a new CA, and certificate and key for the 
second server.  Since I'm not using the same CA as the first server, 
ovirt engine (which only has the CA of the first server) won't be able 
to talk to the second server... no problem I will fix that eventually.


However, when I re-ran "ovirt-engine-extension-aaa-ldap-setup", and 
followed the exact steps I did before, ovirt is connecting to the first 
server, failing with the above error, then connecting to the second 
server, and the same error.  The CA hasn't changed for the first server, 
nor has the certificate/key.  I verified that the CA certificate that I 
am giving ovirt is matching with the exact CA certificate of the first 
server.


How can I debug further?

Jason.
___
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/YL54RUH43FH64GJITZFRSZZEDIKRGIAB/

[ovirt-users] Re: uploading ang .OVA image

[Gianluca Cecchi]

On Thu, Feb 4, 2021 at 2:12 PM Ariez Ahito  wrote:

> hi guys, i just want to ask if you can just upload an .OVA file to ovirt
> just like uploading ISO?
> without setting up virt-v2v and export domain?
>
> thanks
>
>
Put the OVA file on one of your hypervisors in a certain path
Go to Web Admin Gui --> Compute --> Virtual Machines
Select the three vertical dots at top right (near the "Migrate" button) and
"Import"
Select "Virtual Appliance (OVA)" as source and choose the host and File
Path where you previously put the OVA
select the VMs to import using the horizontal arrows

In theory it should be supported oVirt as internal format and only vSphere
as external format of OVA.
But as far as your OVA complies with what oVirt expects, it could work too.

Gianluca
___
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/IUA6QJGTZYHVAHIDUBEEGCTHCIR3CI2R/

[ovirt-users] uploading ang .OVA image

[Ariez Ahito]

hi guys, i just want to ask if you can just upload an .OVA file to ovirt just 
like uploading ISO?
without setting up virt-v2v and export domain?

thanks
___
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/O2HLA7HWDGLTEKJEPRNIP33YL5G7GESW/

[ovirt-users] Re: Recovery from power outage

[Yedidyah Bar David]

On Thu, Feb 4, 2021 at 12:15 PM Roderick Mooi  wrote:
>
> Thanks so much, this worked!
>
> For the record/list benefit, I first put the host into maintenance and then 
> selected Enroll Certificate - this regenerated the certs.
> (VDSM cert can be checked with: certtool -i --infile 
> /etc/pki/vdsm/certs/vdsmcert.pem)
>
> I then took these steps on the affected (incorrectly reported) host to update 
> the hosted-engine --vm-status:
> 1. hosted-engine --set-maintenance --mode=global
> 2. systemctl stop ovirt-ha-agent.service
> 3. hosted-engine --clean-metadata
> 4. systemctl start ovirt-ha-agent.service
> 5. hosted-engine --vm-status (after a minute or two - to verify that the host 
> details are now correct)

Mooi!

(pun intended) (Yes, I speak a little dutch)

Thanks for the report!

>
> Cheers :)
>
> On 2021/02/04 10:17, Yedidyah Bar David wrote:
> > On Thu, Feb 4, 2021 at 10:09 AM Roderick Mooi  wrote:
> >>
> >> Hi Didi!
> >>
> >> Ok, I started the clean metadata process and then found the real issue - I 
> >> had copied the certs (just /etc/pki/vdsm; other pki folders were intact) 
> >> from a working host (host 2) to host 1 following the re-deploy cleanup as 
> >> part of the process to get it online again. The problem is the cert 
> >> contains the hostname (so now the cert on host 1 contains as Subject CN 
> >> the hostname of host 2).
> >
> > Right. Sorry I didn't remember that.
> >
> >> I found some docs on the certs for libvirt but it's not clear what I need 
> >> to do to correctly re-generate the vdsm certs on host 1. Can you help? PS 
> >> I presume I need to re-generate client certs for that host as well and 
> >> copy to the engine?
> >
> > Easiest is to put the host to maintenance, then "Enroll Certificate" -
> > IIRC this should be enough. If you want to make sure, perhaps better
> > remove all certs/keys and do 'Reinstall' instead, and make sure you
> > choose 'Deploy' for 'Hosted Engine'.
> >
> > Good luck,
> >
> >>
> >> Appreciated,
> >>
> >> Roderick
> >>
> >>
> >> On 2021/02/03 16:58, Yedidyah Bar David wrote:
> >>> On Wed, Feb 3, 2021 at 4:52 PM Roderick Mooi  
> >>> wrote:
> 
>  Thanks,
> 
> > I didn't check, but am pretty certain that it's not related to the
> > engine db. Do you see such duplicates there as well (using the web ui
> > or sql against it)? If so, fix these first. If no other means, put the
> > host to maintenance and reinstall with the correct name.
> 
>  Not seeing duplicates in the web UI, only in the --vm-status. Can you 
>  please assist me with the sql commands or reference to the database 
>  schema + where to check? I'd like to check that first before doing 
>  anything too drastic.
> >>>
> >>> /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c 'select * from vds'
> >>>
> 
>  Note: it only duplicated the hostname after I changed the host_id, 
>  before that it had the correct hostname but duplicate host_id.
> 
>  PS I have a recent backup of the database (just before which I could 
>  restore if you think that'll do the trick without breaking anything?
> 
> 
>  On 2021/02/03 16:33, Yedidyah Bar David wrote:
> > On Wed, Feb 3, 2021 at 4:21 PM Roderick Mooi  
> > wrote:
> >>
> >> Hi,
> >>
> >>> Any idea how this happened?
> >>
> >> Somehow related to the power being "pulled" at the wrong time?
> >>
> >>> Perhaps this is a backup done by emacs?
> >>
> >> Not sure what does it but I'm glad it did ;)
> >>
> >>> Please compare it to your other hosts. It should be (mostly?)
> >>> identical, but make sure that host_id= is unique per host. It should
> >>> match the spm host id for this host in the engine database.
> >>
> >> I had to restore one of my hosts (host 1) manually due a cleanup 
> >> during my re-deploy attempts. I managed to do this successfully by 
> >> copying the missing files from another host (host 2) but the first 
> >> time the host ID matched one of the other hosts (which made at least 
> >> hosted-engine --vm-status unhappy) [I hadn't seen your email yet :(]. 
> >> I subsequently corrected the host_id and rebooted the guilty host. 
> >> Things mostly seem to be working now except that in hosted-engine 
> >> --vm-status my first two hosts (the one I copied the .conf from as 
> >> well as the one I copied it to [without changing the ID :O]) now have 
> >> the same hostname :-/ I'm assuming there's a mismatch in the engine 
> >> database - where/how do I fix that?
> >>
> >
> > I didn't check, but am pretty certain that it's not related to the
> > engine db. Do you see such duplicates there as well (using the web ui
> > or sql against it)? If so, fix these first. If no other means, put the
> > host to maintenance and reinstall with the correct name.
> >
> > If it's just the shared storage, you can try the following. Carefully.

[ovirt-users] Re: Recovery from power outage

[Roderick Mooi]

Thanks so much, this worked!

For the record/list benefit, I first put the host into maintenance and then 
selected Enroll Certificate - this regenerated the certs.
(VDSM cert can be checked with: certtool -i --infile 
/etc/pki/vdsm/certs/vdsmcert.pem)

I then took these steps on the affected (incorrectly reported) host to update 
the hosted-engine --vm-status:
1. hosted-engine --set-maintenance --mode=global
2. systemctl stop ovirt-ha-agent.service
3. hosted-engine --clean-metadata
4. systemctl start ovirt-ha-agent.service
5. hosted-engine --vm-status (after a minute or two - to verify that the host 
details are now correct)

Cheers :)

On 2021/02/04 10:17, Yedidyah Bar David wrote:

On Thu, Feb 4, 2021 at 10:09 AM Roderick Mooi  wrote:


Hi Didi!

Ok, I started the clean metadata process and then found the real issue - I had 
copied the certs (just /etc/pki/vdsm; other pki folders were intact) from a 
working host (host 2) to host 1 following the re-deploy cleanup as part of the 
process to get it online again. The problem is the cert contains the hostname 
(so now the cert on host 1 contains as Subject CN the hostname of host 2).


Right. Sorry I didn't remember that.


I found some docs on the certs for libvirt but it's not clear what I need to do 
to correctly re-generate the vdsm certs on host 1. Can you help? PS I presume I 
need to re-generate client certs for that host as well and copy to the engine?


Easiest is to put the host to maintenance, then "Enroll Certificate" -
IIRC this should be enough. If you want to make sure, perhaps better
remove all certs/keys and do 'Reinstall' instead, and make sure you
choose 'Deploy' for 'Hosted Engine'.

Good luck,



Appreciated,

Roderick


On 2021/02/03 16:58, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 4:52 PM Roderick Mooi  wrote:


Thanks,


I didn't check, but am pretty certain that it's not related to the
engine db. Do you see such duplicates there as well (using the web ui
or sql against it)? If so, fix these first. If no other means, put the
host to maintenance and reinstall with the correct name.


Not seeing duplicates in the web UI, only in the --vm-status. Can you please 
assist me with the sql commands or reference to the database schema + where to 
check? I'd like to check that first before doing anything too drastic.


/usr/share/ovirt-engine/dbscripts/engine-psql.sh -c 'select * from vds'



Note: it only duplicated the hostname after I changed the host_id, before that 
it had the correct hostname but duplicate host_id.

PS I have a recent backup of the database (just before which I could restore if 
you think that'll do the trick without breaking anything?


On 2021/02/03 16:33, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 4:21 PM Roderick Mooi  wrote:


Hi,


Any idea how this happened?


Somehow related to the power being "pulled" at the wrong time?


Perhaps this is a backup done by emacs?


Not sure what does it but I'm glad it did ;)


Please compare it to your other hosts. It should be (mostly?)
identical, but make sure that host_id= is unique per host. It should
match the spm host id for this host in the engine database.


I had to restore one of my hosts (host 1) manually due a cleanup during my 
re-deploy attempts. I managed to do this successfully by copying the missing 
files from another host (host 2) but the first time the host ID matched one of 
the other hosts (which made at least hosted-engine --vm-status unhappy) [I 
hadn't seen your email yet :(]. I subsequently corrected the host_id and 
rebooted the guilty host. Things mostly seem to be working now except that in 
hosted-engine --vm-status my first two hosts (the one I copied the .conf from 
as well as the one I copied it to [without changing the ID :O]) now have the 
same hostname :-/ I'm assuming there's a mismatch in the engine database - 
where/how do I fix that?



I didn't check, but am pretty certain that it's not related to the
engine db. Do you see such duplicates there as well (using the web ui
or sql against it)? If so, fix these first. If no other means, put the
host to maintenance and reinstall with the correct name.

If it's just the shared storage, you can try the following. Carefully.
Didn't try myself. Try on a test system first.

1. Set global maintenance

2. Stop ovirt-ha-agent, ovirt-ha-broker, perhaps also vdsmd, supervdsmd

3. hosted-engine --clean_metadata --host-id=1

- Perhaps even pass --force-cleanup, not sure when it's needed

- Repeat for other IDs as needed

4. Start ovirt-ha-agent (I think this should start all the others, but
make sure)

5. Wait a bit. I am pretty certain that they should recreate their
entries in the shared storage and eventually --vm-status should look
ok.

6. Exit global maintenance

Good luck,


Appreciated! (and happy cos our cluster is almost back to normal :) )

On 2021/02/03 11:30, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 11:12 AM Roderick Mooi  wrote:


Hello and thanks for assisting!

I 

[ovirt-users] Re: Recovery from power outage

[Yedidyah Bar David]

On Thu, Feb 4, 2021 at 10:09 AM Roderick Mooi  wrote:
>
> Hi Didi!
>
> Ok, I started the clean metadata process and then found the real issue - I 
> had copied the certs (just /etc/pki/vdsm; other pki folders were intact) from 
> a working host (host 2) to host 1 following the re-deploy cleanup as part of 
> the process to get it online again. The problem is the cert contains the 
> hostname (so now the cert on host 1 contains as Subject CN the hostname of 
> host 2).

Right. Sorry I didn't remember that.

> I found some docs on the certs for libvirt but it's not clear what I need to 
> do to correctly re-generate the vdsm certs on host 1. Can you help? PS I 
> presume I need to re-generate client certs for that host as well and copy to 
> the engine?

Easiest is to put the host to maintenance, then "Enroll Certificate" -
IIRC this should be enough. If you want to make sure, perhaps better
remove all certs/keys and do 'Reinstall' instead, and make sure you
choose 'Deploy' for 'Hosted Engine'.

Good luck,

>
> Appreciated,
>
> Roderick
>
>
> On 2021/02/03 16:58, Yedidyah Bar David wrote:
> > On Wed, Feb 3, 2021 at 4:52 PM Roderick Mooi  wrote:
> >>
> >> Thanks,
> >>
> >>> I didn't check, but am pretty certain that it's not related to the
> >>> engine db. Do you see such duplicates there as well (using the web ui
> >>> or sql against it)? If so, fix these first. If no other means, put the
> >>> host to maintenance and reinstall with the correct name.
> >>
> >> Not seeing duplicates in the web UI, only in the --vm-status. Can you 
> >> please assist me with the sql commands or reference to the database schema 
> >> + where to check? I'd like to check that first before doing anything too 
> >> drastic.
> >
> > /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c 'select * from vds'
> >
> >>
> >> Note: it only duplicated the hostname after I changed the host_id, before 
> >> that it had the correct hostname but duplicate host_id.
> >>
> >> PS I have a recent backup of the database (just before which I could 
> >> restore if you think that'll do the trick without breaking anything?
> >>
> >>
> >> On 2021/02/03 16:33, Yedidyah Bar David wrote:
> >>> On Wed, Feb 3, 2021 at 4:21 PM Roderick Mooi  
> >>> wrote:
> 
>  Hi,
> 
> > Any idea how this happened?
> 
>  Somehow related to the power being "pulled" at the wrong time?
> 
> > Perhaps this is a backup done by emacs?
> 
>  Not sure what does it but I'm glad it did ;)
> 
> > Please compare it to your other hosts. It should be (mostly?)
> > identical, but make sure that host_id= is unique per host. It should
> > match the spm host id for this host in the engine database.
> 
>  I had to restore one of my hosts (host 1) manually due a cleanup during 
>  my re-deploy attempts. I managed to do this successfully by copying the 
>  missing files from another host (host 2) but the first time the host ID 
>  matched one of the other hosts (which made at least hosted-engine 
>  --vm-status unhappy) [I hadn't seen your email yet :(]. I subsequently 
>  corrected the host_id and rebooted the guilty host. Things mostly seem 
>  to be working now except that in hosted-engine --vm-status my first two 
>  hosts (the one I copied the .conf from as well as the one I copied it to 
>  [without changing the ID :O]) now have the same hostname :-/ I'm 
>  assuming there's a mismatch in the engine database - where/how do I fix 
>  that?
> 
> >>>
> >>> I didn't check, but am pretty certain that it's not related to the
> >>> engine db. Do you see such duplicates there as well (using the web ui
> >>> or sql against it)? If so, fix these first. If no other means, put the
> >>> host to maintenance and reinstall with the correct name.
> >>>
> >>> If it's just the shared storage, you can try the following. Carefully.
> >>> Didn't try myself. Try on a test system first.
> >>>
> >>> 1. Set global maintenance
> >>>
> >>> 2. Stop ovirt-ha-agent, ovirt-ha-broker, perhaps also vdsmd, supervdsmd
> >>>
> >>> 3. hosted-engine --clean_metadata --host-id=1
> >>>
> >>> - Perhaps even pass --force-cleanup, not sure when it's needed
> >>>
> >>> - Repeat for other IDs as needed
> >>>
> >>> 4. Start ovirt-ha-agent (I think this should start all the others, but
> >>> make sure)
> >>>
> >>> 5. Wait a bit. I am pretty certain that they should recreate their
> >>> entries in the shared storage and eventually --vm-status should look
> >>> ok.
> >>>
> >>> 6. Exit global maintenance
> >>>
> >>> Good luck,
> >>>
>  Appreciated! (and happy cos our cluster is almost back to normal :) )
> 
>  On 2021/02/03 11:30, Yedidyah Bar David wrote:
> > On Wed, Feb 3, 2021 at 11:12 AM Roderick Mooi  
> > wrote:
> >>
> >> Hello and thanks for assisting!
> >>
> >> I think I may have found the problem :)
> >>
> >> /etc/ovirt-hosted-engine/hosted-engine.conf
> >>
> >> is blank.
> 

[ovirt-users] Re: Recovery from power outage

[Roderick Mooi]

Hi Didi!

Ok, I started the clean metadata process and then found the real issue - I had 
copied the certs (just /etc/pki/vdsm; other pki folders were intact) from a 
working host (host 2) to host 1 following the re-deploy cleanup as part of the 
process to get it online again. The problem is the cert contains the hostname 
(so now the cert on host 1 contains as Subject CN the hostname of host 2). I 
found some docs on the certs for libvirt but it's not clear what I need to do 
to correctly re-generate the vdsm certs on host 1. Can you help? PS I presume I 
need to re-generate client certs for that host as well and copy to the engine?

Appreciated,

Roderick


On 2021/02/03 16:58, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 4:52 PM Roderick Mooi  wrote:


Thanks,


I didn't check, but am pretty certain that it's not related to the
engine db. Do you see such duplicates there as well (using the web ui
or sql against it)? If so, fix these first. If no other means, put the
host to maintenance and reinstall with the correct name.


Not seeing duplicates in the web UI, only in the --vm-status. Can you please 
assist me with the sql commands or reference to the database schema + where to 
check? I'd like to check that first before doing anything too drastic.


/usr/share/ovirt-engine/dbscripts/engine-psql.sh -c 'select * from vds'



Note: it only duplicated the hostname after I changed the host_id, before that 
it had the correct hostname but duplicate host_id.

PS I have a recent backup of the database (just before which I could restore if 
you think that'll do the trick without breaking anything?


On 2021/02/03 16:33, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 4:21 PM Roderick Mooi  wrote:


Hi,


Any idea how this happened?


Somehow related to the power being "pulled" at the wrong time?


Perhaps this is a backup done by emacs?


Not sure what does it but I'm glad it did ;)


Please compare it to your other hosts. It should be (mostly?)
identical, but make sure that host_id= is unique per host. It should
match the spm host id for this host in the engine database.


I had to restore one of my hosts (host 1) manually due a cleanup during my 
re-deploy attempts. I managed to do this successfully by copying the missing 
files from another host (host 2) but the first time the host ID matched one of 
the other hosts (which made at least hosted-engine --vm-status unhappy) [I 
hadn't seen your email yet :(]. I subsequently corrected the host_id and 
rebooted the guilty host. Things mostly seem to be working now except that in 
hosted-engine --vm-status my first two hosts (the one I copied the .conf from 
as well as the one I copied it to [without changing the ID :O]) now have the 
same hostname :-/ I'm assuming there's a mismatch in the engine database - 
where/how do I fix that?



I didn't check, but am pretty certain that it's not related to the
engine db. Do you see such duplicates there as well (using the web ui
or sql against it)? If so, fix these first. If no other means, put the
host to maintenance and reinstall with the correct name.

If it's just the shared storage, you can try the following. Carefully.
Didn't try myself. Try on a test system first.

1. Set global maintenance

2. Stop ovirt-ha-agent, ovirt-ha-broker, perhaps also vdsmd, supervdsmd

3. hosted-engine --clean_metadata --host-id=1

- Perhaps even pass --force-cleanup, not sure when it's needed

- Repeat for other IDs as needed

4. Start ovirt-ha-agent (I think this should start all the others, but
make sure)

5. Wait a bit. I am pretty certain that they should recreate their
entries in the shared storage and eventually --vm-status should look
ok.

6. Exit global maintenance

Good luck,


Appreciated! (and happy cos our cluster is almost back to normal :) )

On 2021/02/03 11:30, Yedidyah Bar David wrote:

On Wed, Feb 3, 2021 at 11:12 AM Roderick Mooi  wrote:


Hello and thanks for assisting!

I think I may have found the problem :)

/etc/ovirt-hosted-engine/hosted-engine.conf

is blank.

But I do have hosted-engine.conf~


Any idea how this happened?

Perhaps this is a backup done by emacs?



Can I cp this to restore the original?


Please compare it to your other hosts. It should be (mostly?)
identical, but make sure that host_id= is unique per host. It should
match the spm host id for this host in the engine database.



Anything else I need to do?


Not sure, but better find the root cause to make sure no other damage was done.

Good luck,



Appreciated


On 2021/02/02 11:37, Strahil Nikolov wrote:

Usually,

I would start with checking the output of the 
/var/log/ovirt-hosted-engine-ha/{broker,agent}.log

I'm typing it on my phone, so the path could have a typo.

Check if the following services (also typed by memory, might have to remove the 
'd') are running:
- sanlock
- supervdsmd
- vdsmd


Sometimes, some of my VGs (gluster) are not activated, so if you run 
hyperconverged -> you can 'vgchange -ay'.

Best Regards,

[ovirt-users] Re: Locked disks

[Giulio Casella]

I've not been able to reproduce, if happens again I'll submit a bugzilla.

Thank you.

Regards,
gc


On 03/02/2021 17:49, Shani Leviim wrote:
> In such a case, the disks shouldn't remain locked - sounds like a bug.
> This one requires a deeper look.
> If you're able to reproduce it again, please open a bug in Bugzilla
> (https://bugzilla.redhat.com ) with engine
> and vdsm logs,
> so we'll be able to investigate it.
> 
> *Regards,
> *
> *Shani Leviim
> *
> 
> 
> On Wed, Feb 3, 2021 at 5:39 PM Giulio Casella  > wrote:
> 
> Hi,
> I tried unlock_entity.sh, and it solved the issue. So far so good.
> 
> But it's still unclear why disks were locked.
> 
> Let me make an hypothesis: in ovirt 4.3 a failure in snapshot removal
> would lead to a snapshot in illegal status. No problem, you can remove
> again and the situation is fixed.
> In ovirt 4.4 a failure in snapshot removal leave the whole disk in
> locked state (maybe a bug?), preventing any further action.
> 
> Does it make sense?
> 
> 
> On 03/02/2021 12:25, Giulio Casella wrote:
> > Hi Shani,
> > no tasks listed in UI, and now "taskcleaner.sh -o" reports no task
> (just
> > before I gave "taskcleaner.sh -r").
> > But disks are still locked, and "unlock_entity.sh -q -t all -c"
> > (accordingly) reports only two disk's uuid (with their vm's uuid).
> >
> > Time to give a chance to unlock_entity.sh?
> >
> > Regards,
> > gc
> >
> > On 03/02/2021 11:52, Shani Leviim wrote:
> >> Hi Giulio,
> >> Before running unlock_entity.sh, let's try to find if there's any
> task
> >> in progress.
> >> Is there any hint on the events in the UI?
> >> Or try to run [1]:
> >> ./taskcleaner.sh -o  
> >>
> >> Also, you can verify what entities are locked [2]:
> >> ./unlock_entity.sh -q -t all -c
> >>
> >> [1]
> >>
> 
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/dbutils/taskcleaner.sh
> 
> 
> >>
> 
>  
> >
> >> [2]
> >>
> 
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/dbutils/unlock_entity.sh
> 
> 
> >>
> 
>  
> >
> >>
> >> *Regards,
> >> *
> >> *Shani Leviim
> >> *
> >>
> >>
> >> On Wed, Feb 3, 2021 at 10:43 AM Giulio Casella
> mailto:giu...@di.unimi.it>
> >> >> wrote:
> >>
> >>     Since yesterday I found a couple VMs with locked disk. I
> don't know the
> >>     reason, I suspect some interaction made by our backup system
> (vprotect,
> >>     snapshot based), despite it's working for more than a year.
> >>
> >>     I'd give a chance to unlock_entity.sh script, but it reports:
> >>
> >>     CAUTION, this operation may lead to data corruption and
> should be used
> >>     with care. Please contact support prior to running this command
> >>
> >>     Do you think I should trust? Is it safe? VMs are in production...
> >>
> >>     My manager is 4.4.4.7-1.el8 (CentOS stream 8), hosts are
> oVirt Node
> >>     4.4.4
> >>
> >>
> >>     TIA,
> >>     Giulio
> >>     ___
> >>     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/M4HYMDMHOKC5DCHDP6CFLM4RWJQNN7R4/
> 
>