Re: [ovirt-users] User cannot create VMs having sufficient permissions to do so

[nicolas]

Seems I found out the problem.

This user had a permission as InstanceCreator over a VM. If I remove 
this permission, he can successfully create new VMs.


This seems a bug, not sure if known or not.

Should I file a BZ?

Thanks.

El 2017-10-18 11:04, nico...@devels.es escribió:

Hi,

We're running ovirt-4.1.6.2-1. We have a user that logs into the user
portal and tries to create a VM, but a message claiming that "There is
no Cluster on which you can create a VM. Please check Data Center
status and Cluster permissions." shows up.

However, this user has permissions on the cluster (both VmCreator and
DiskProfileUser, and also has a Quota created on the Cluster which
allows him to create VMs).

When clicking on the 'New VM' button, all we see in the engine.log is:

2017-10-18 10:59:31,825+01 ERROR
[org.ovirt.engine.core.bll.GetAllLabelsQuery] (default task-103)
[c23549c6-37a4-48d7-923d-6618e027cdca] Query execution failed due to
insufficient permissions.

This user has pretty much the same permissions as thousands of users
who can create VMs, but this one can't.

How can we debug what's happening and how to solve it?

Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] unlock_entity.sh

[nicolas]

Hi,

Not sure if this is the only one way, but this works for us (run as 
root):


  PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh 
-t all -u engine


Note that unlock_entity.sh has many flags and this is just an example.

You can find the PGPASSWORD value in the 
/etc/ovirt-engine/engine.conf.d/10-setup-database.conf file.


As to where can you find the disk ID, I usually use either the 
Python-SDK or from within the admin UI, you can go to the Disks tab and 
find the disk you're looking for. Simply click on it and you'll see the 
ID string easily.


Regards,

Nicolás

El 2017-10-24 11:18, Johan Vermeulen escribió:

Hello All,

first of all, I hope this question is not too trivial or hasn't been
asked lately
( but i scrolled down the mailing list and didn't find anything
similar, so...)

I have a lot of trouble with locked disks when trying to remove vm's.
I know there's the unlock_entity script but cannot get it to work.

Where can I find a copy-paste-able uuid nr of the disk?
It prompts me for a database password. Is this something I should have
created when setting up Ovirt?

Can anyone give me an example of a complete unlock entity command?

Many thanks for any help.

greetings, J.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Option to put host into maintenance after installation of new host

[nicolas]

Hi,

I opened this BZ [1] a time ago. Feel free to vote for it if you wish.

Regards,

Nicolás

  [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1322137

El 2017-12-18 14:48, Florian Schmid escribió:

Hi,

would it be possible for future releases to add an option to the add
new host tab to put the host in maintenance after installation instead
of activating it.
The same would be for reinstall.

I have the problem now, that all hosts after installation will be
activated, but network is not configured yet. Therefore host will be
in non operational state and will be rebooted immediately.
The only solution I have now is to configure power management after
the host has all networks configured.

I want to have all my networks as required, because otherwise someone
will forget to add all of them and then you have other issues.

BR Florian

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] how to clean stuck task

[nicolas]

El 2017-11-10 14:41, Gianluca Cecchi escribió:

On Fri, Nov 10, 2017 at 3:34 PM,  wrote:


oVirt upgrade to 4.1.7 will probably cleanup this stale task.
However, if you want to do it before upgrading, run this command:

   PGPASSWORD=...
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t all -u
engine

Note that unlock_entity.sh has many flags and this is just an
example (should clean all stale tasks).

You can find the PGPASSWORD value in the
/etc/ovirt-engine/engine.conf.d/10-setup-database.conf file. As of
4.2 you won't need to supply credentials anymore [1].

Regards,

Nicolás


It seems it didn't work as expected.
I got this at command line output

"

select fn_db_unlock_all();
 

INSERT 0 1
unlock all  completed successfully.
"



This is expected.


But the task remains in webadmin gui and I got an alert message in
alert section, of this type
"
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh : System user
root run manually unlock_entity script on entity [type,id] [all,] with
db user engine
"



I've seen this behavior too. IIRC the stale cleaning was not instant, it 
took some time to be applied.


Regards.


Gianluca

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] how to clean stuck task

[nicolas]

oVirt upgrade to 4.1.7 will probably cleanup this stale task. However, 
if you want to do it before upgrading, run this command:


   PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh 
-t all -u engine


Note that unlock_entity.sh has many flags and this is just an example 
(should clean all stale tasks).


You can find the PGPASSWORD value in the 
/etc/ovirt-engine/engine.conf.d/10-setup-database.conf file. As of 4.2 
you won't need to supply credentials anymore [1].


Regards,

Nicolás

  [1]: https://gerrit.ovirt.org/82615

El 2017-11-10 14:16, Gianluca Cecchi escribió:

Hello, 
I have a task that seems stuck in webadmin gui, in the sens tha I have
"Tasks(1)" listed
The task is  Restoring VM Snapshot Active VM before the preview of
VM snaptest
and the VM is powered down.
Screenshot of expanded steps of task, that actually seem all
completed, is here:
https://drive.google.com/file/d/1bfl_gEfVotIrxGC9TDzPHPCeRub41mUa/view?usp=sharing
[1]

Any hint on what to do to clean things? I'm on oVirt
4.1.6.2-1.el7.centos and I would like to clean before upgrading to
4.1.7.

Thanks
Gianluca

Links:
--
[1]
https://drive.google.com/file/d/1bfl_gEfVotIrxGC9TDzPHPCeRub41mUa/view?usp=sharing

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 4.1.7: Duplicate MAC addresses had to be introduced into mac pool violating no duplicates setting.

[nicolas]

Hi Alona,

El 2017-11-19 08:31, Alona Kaplan escribió:

Hi Nicolas,

There was a bug in oVirt [1] that in some cases a mac pool that
doesn't support duplicate macs could get duplicates.
The bug was (hopefully) fixed.

The error that you see means that you have a mac pool that was
affected by this bug and have duplicate macs although it doesn't
support it.
The second part of the error should contain the list of the duplicate
macs ("Following MACs violates duplicity restriction, and was pushed
into MAC pool without respect to it:").



Indeed, being this message:

engine.log-20171117.gz:2017-11-16 10:34:55,373Z ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(ServerService Thread Pool -- 52) [] EVENT_ID: 
MAC_ADDRESS_VIOLATES_NO_DUPLICATES_SETTING(10,917), Following MACs 
violates duplicity restriction, and was pushed into MAC pool without 
respect to it:[00:1a:4a:97:5f:16, 00:1a:4a:97:5f:05, 00:1a:4a:97:5f:1d, 
00:1a:4a:97:5f:07, 00:1a:4a:97:5f:0f, 00:1a:4a:4d:cc:1c, 
00:1a:4a:97:5f:15, 00:1a:4a:97:5f:0d]



It is just a warning, you can ignore it.
But we advise you to go over the duplicate macs and fix them.


However, recently I made a small script to find duplicate MACs because I 
was having an issue with dupe MACs (which BTW you helped me to debug in 
BZ [1]). I'm attaching the script just in case something is wrong in it, 
but the script shows no dupe MAC addresses currently. Maybe in the past 
(before the upgrade) there was dupes with those MAC addresses, but not 
now.


The output of the script shows only one machine per MAC address:

00:1a:4a:97:5f:16 ['VM1']
00:1a:4a:97:5f:05 ['VM2']
00:1a:4a:97:5f:1d ['VM3']
00:1a:4a:97:5f:07 ['VM4']
00:1a:4a:97:5f:0f ['VM5']
00:1a:4a:4d:cc:1c ['VM6']
00:1a:4a:97:5f:15 ['VM7']
00:1a:4a:97:5f:0d ['VM8']

Should I file a bug or simply ignore it?

Thanks.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1497242



Alona.

[1] https://bugzilla.redhat.com/1485688 [2]

On Fri, Nov 17, 2017 at 4:54 PM, <nico...@devels.es> wrote:


Hi,

We just upgraded from 4.1.6 to 4.1.7 and just after the engine was
brought back the following event showed up:

   Duplicate MAC addresses had to be introduced into mac pool
violating no duplicates setting.

Can someone explain why is that?

Thanks.

Nicolás
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]




Links:
--
[1] http://lists.ovirt.org/mailman/listinfo/users
[2] https://bugzilla.redhat.com/1485688#!/usr/bin/env python

from sys import path

import os.path
from sys import exit

from ovirtsdk4 import Connection, types
from scriptsparams import URI, USERNAME, PASSWORD, CERTPATH

conn = Connection(
   url=URI,
   username=USERNAME,
   password=PASSWORD,
   ca_file=CERTPATH
)

if not conn.test(raise_exception=False):
print "ERROR: Cannot connect. Is engine up? Are credentials ok?"
exit(1)

vms_macs = {}

sys_serv = conn.system_service()
vms_serv = sys_serv.vms_service()

macs = []
for vm in vms_serv.list():
nics = conn.follow_link(vm.nics)
for nic in nics:
if nic.mac.address in vms_macs:
vms_macs[nic.mac.address].append(vm.name)
else:
vms_macs[nic.mac.address] = [vm.name]
macs.append(nic.mac.address)

print '00:1a:4a:97:5f:16', vms_macs['00:1a:4a:97:5f:16']
print '00:1a:4a:97:5f:05', vms_macs['00:1a:4a:97:5f:05']
print '00:1a:4a:97:5f:1d', vms_macs['00:1a:4a:97:5f:1d']
print '00:1a:4a:97:5f:07', vms_macs['00:1a:4a:97:5f:07']
print '00:1a:4a:97:5f:0f', vms_macs['00:1a:4a:97:5f:0f']
print '00:1a:4a:4d:cc:1c', vms_macs['00:1a:4a:4d:cc:1c']
print '00:1a:4a:97:5f:15', vms_macs['00:1a:4a:97:5f:15']
print '00:1a:4a:97:5f:0d', vms_macs['00:1a:4a:97:5f:0d']
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] oVirt 4.1.7: Duplicate MAC addresses had to be introduced into mac pool violating no duplicates setting.

[nicolas]

Hi,

We just upgraded from 4.1.6 to 4.1.7 and just after the engine was 
brought back the following event showed up:


   Duplicate MAC addresses had to be introduced into mac pool violating 
no duplicates setting.


Can someone explain why is that?

Thanks.

Nicolás
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Hi,

We're getting closer to solve it :-)

I'll answer below with my steps, there's one that fails and I don't know 
why (probably I missed something).


El 2018-05-17 15:47, Benny Zlotnik escribió:

Sorry, I forgot it's ISCSI, it's a bit different

In my case it would look something like:

2018-05-17 17:30:12,740+0300 DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
'3e541b2d-
2a49-4eb8-ae4b-aa9acee228c6', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 0, 'image':
'dd6b5ae0-196e-4879-b076-a0a8d8a1dfde', 'ctime': '1526566607',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'221c45e1-7f65-42c8-afc3-0ccc1d6fc148', 'truesize': '1073741824',
'type': 'PREALLOCATED', 'lease': {'path':
'/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases', 'owners
': [], 'version': None, 'offset': 109051904}} (__init__:355)

I then look for 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 in sanlock.log:

2018-05-17 17:30:12 20753 [3335]: s10:r14 resource
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb
8-ae4b-aa9acee228c6/leases:109051904 for 2,11,31496



I only could find the entry on one of the hosts. So when I grepped the 
uuid I found:


2018-05-16 12:39:44 4761204 [1023]: s33:r103 resource 
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848 
for 23,47,9206



So the resource would
be: 
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
and the pid is 31496



Ok, so my resource is 
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848 
and my PID is 9206.



running
$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904

  offset                            lockspace     
                                   resource 
timestamp  own  gen lver

 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 020753 0001 0004 5
...


In my case the output would be:

[...]
 1876ab86-216f-4a37-a36b-2b5d99fcaad0 
c2cfbb02-9981-4fb7-baea-7257a824145c 0004918032 0008 0004 2

[...]



If the vdsm pid changed (and it probably did) it will be different,
so I acquire it for the new pid
$ sanlock client acquire -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265
acquire pid 32265



I checked vdsmd's PID

# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
[...]
├─17758 /usr/bin/python2 /usr/share/vdsm/vdsm

So the new PID is 17758.

# sanlock client acquire -r 
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848 
-p 17758

acquire pid 17758
acquire done 0



Then I can see the timestamp changed 

$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offset                            lockspace     
                                   resource 
timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 021210 0001 0005 6

And then I release it:
$ sanlock client release -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265

release pid 32265
release done 0



There's where it fails:

# sanlock direct release -r 
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848 
-p 17758

release done -251

And the resource is still stuck.

Is there something I missed there?


$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offset                            lockspace     
                                   resource 
timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 00 0001 0005 6

The timestamp is zeroed and the lease is free

On Thu, May 17, 2018 at 3:38 PM,  wrote:


This is vdsm 4.19.45. I grepped the disk uuid in
/var/log/sanlock.log but unfortunately no entry there...

El 2018-05-17 13:11, Benny Zlotnik escribió:

Which vdsm version are you using?

You can try looking for the image uuid in /var/log/sanlock.log

On Thu, May 17, 2018 at 2:40 PM,  wrote:

Thanks.

I've been able to see the line in the log, however, the format
differs slightly from yours.

  2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6)

[ovirt-users] VM's disk stuck in migrating state

[nicolas]

Hi,

We're running oVirt 4.1.9 (I know it's not the recommended version, but 
we can't upgrade yet) and recently we had an issue with a Storage Domain 
while a VM was moving a disk. The Storage Domain went down for a few 
minutes, then it got back.


However, the disk's state has stuck in a 'Migrating: 10%' state (see 
ss-2.png).


I run the 'unlock_entity.sh' script to try to unlock the disk, with 
these parameters:


 # PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh 
-t disk -u engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38


The disk's state changed to 'OK', but the actual state still states it's 
migrating (see ss-1.png).


Calling the script with -t all doesn't make a difference either.

Currently, the disk is unmanageable: cannot be deactivated, moved or 
copied, as it says there's a copying operation running already.


Could someone provide a way to unlock this disk? I don't mind modifying 
a value directly into the database, I just need the copying process 
cancelled.


Thanks.___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry I can 
find grepping by Volume.getInfo is like this:


  2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] 
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)


I cannot find a line like yours... any other way on how to obtain those 
parameters. This is an iSCSI based storage FWIW (both source and 
destination of the movement).


Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:

In the vdsm log you will find the volumeInfo log which looks like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':
u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e
b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease

Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0
for 2,9,5049

Then you can use this command to unlock, the pid in this case is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik 
wrote:


I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [1]

You can try to release the lease manually using the sanlock client
command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be unlock

On Thu, May 17, 2018 at 11:05 AM,  wrote:


Hi,

We're running oVirt 4.1.9 (I know it's not the recommended
version, but we can't upgrade yet) and recently we had an issue
with a Storage Domain while a VM was moving a disk. The Storage
Domain went down for a few minutes, then it got back.

However, the disk's state has stuck in a 'Migrating: 10%' state
(see ss-2.png).

I run the 'unlock_entity.sh' script to try to unlock the disk,
with these parameters:

 # PGPASSWORD=...
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -u
engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38

The disk's state changed to 'OK', but the actual state still
states it's migrating (see ss-1.png).

Calling the script with -t all doesn't make a difference either.

Currently, the disk is unmanageable: cannot be deactivated, moved
or copied, as it says there's a copying operation running already.

Could someone provide a way to unlock this disk? I don't mind
modifying a value directly into the database, I just need the
copying process cancelled.

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org




Links:
--
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Please disregard the last e-mail. I re-run the command and now the exit 
code was 0, and the migration process is not stuck anymore.


Thanks so much for all the help, Benny!

Regards.

El 2018-05-18 08:42, nico...@devels.es escribió:

Hi,

We're getting closer to solve it :-)

I'll answer below with my steps, there's one that fails and I don't
know why (probably I missed something).

El 2018-05-17 15:47, Benny Zlotnik escribió:

Sorry, I forgot it's ISCSI, it's a bit different

In my case it would look something like:

2018-05-17 17:30:12,740+0300 DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
'3e541b2d-
2a49-4eb8-ae4b-aa9acee228c6', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 0, 'image':
'dd6b5ae0-196e-4879-b076-a0a8d8a1dfde', 'ctime': '1526566607',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'221c45e1-7f65-42c8-afc3-0ccc1d6fc148', 'truesize': '1073741824',
'type': 'PREALLOCATED', 'lease': {'path':
'/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases', 'owners
': [], 'version': None, 'offset': 109051904}} (__init__:355)

I then look for 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 in sanlock.log:

2018-05-17 17:30:12 20753 [3335]: s10:r14 resource
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb
8-ae4b-aa9acee228c6/leases:109051904 for 2,11,31496



I only could find the entry on one of the hosts. So when I grepped the
uuid I found:

2018-05-16 12:39:44 4761204 [1023]: s33:r103 resource
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848
for 23,47,9206


So the resource would
be: 
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
and the pid is 31496



Ok, so my resource is
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848
and my PID is 9206.


running
$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904

  offset                            lockspace     
                                   resource 
timestamp  own  gen lver

 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 020753 0001 0004 5
...


In my case the output would be:

[...]
 1876ab86-216f-4a37-a36b-2b5d99fcaad0
c2cfbb02-9981-4fb7-baea-7257a824145c 0004918032 0008 0004 2
[...]



If the vdsm pid changed (and it probably did) it will be different,
so I acquire it for the new pid
$ sanlock client acquire -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265
acquire pid 32265



I checked vdsmd's PID

# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
[...]
├─17758 /usr/bin/python2 /usr/share/vdsm/vdsm

So the new PID is 17758.

# sanlock client acquire -r
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848
-p 17758
acquire pid 17758
acquire done 0



Then I can see the timestamp changed 

$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offset                            lockspace     
                                   resource 
timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 021210 0001 0005 6

And then I release it:
$ sanlock client release -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265

release pid 32265
release done 0



There's where it fails:

# sanlock direct release -r
1876ab86-216f-4a37-a36b-2b5d99fcaad0:c2cfbb02-9981-4fb7-baea-7257a824145c:/dev/1876ab86-216f-4a37-a36b-2b5d99fcaad0/leases:128974848
-p 17758
release done -251

And the resource is still stuck.

Is there something I missed there?


$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offset                            lockspace     
                                   resource 
timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6           
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 00 0001 0005 6

The timestamp is zeroed and the lease is free

On Thu, May 17, 2018 at 3:38 PM,  wrote:


This is vdsm 4.19.45. I grepped the disk uuid in
/var/log/sanlock.log but unfortunately no entry there...

El 2018-05-17 13:11, Benny Zlotnik escribió:

Which vdsm version are you using?

You can try looking for the image uuid in /var/log/sanlock.log

On Thu, May 17, 2018 at 

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Thanks.

I've been able to see the line in the log, however, the format differs 
slightly from yours.


  2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] 
Calling 'Volume.getInfo' in bridge with {u'storagepoolID': 
u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'imageID': 
u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID': 
u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID': 
u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] 
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain': 
'1876ab86-216f-4a37-a36b-2b5d99fcaad0', 'voltype': 'INTERNAL', 
'description': 'None', 'parent': 'ea9a0182-329f-4b8f-abe3-e894de95dac0', 
'format': 'COW', 'generation': 1, 'image': 
'b4013aba-a936-4a54-bb14-670d3a8b7c38', 'ctime': '1526470759', 
'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': 
'1073741824', 'children': [], 'pool': '', 'capacity': '21474836480', 
'uuid': u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': 
'1073741824', 'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}} 
(__init__:582)


As you can see, there's no path field there.

How should I procceed?

El 2018-05-17 12:01, Benny Zlotnik escribió:

vdsm-client replaces vdsClient, take a look
here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
[4]

On Thu, May 17, 2018 at 1:57 PM,  wrote:


The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO 
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the
volume lease is not FREE - the job is running

I tried setting the log level to debug but it seems I have not a
vdsm-client command. All I have is a vdsm-tool command. Is it
equivalent?

Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:
By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik

wrote:

I see because I am on debug level, you need to enable it in order
to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [1]
[3]

On Thu, 17 May 2018, 13:10 ,  wrote:

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:
In the vdsm log you will find the volumeInfo log which looks
like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK',
'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',
'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':


 
u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e







b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',


'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0. [2]



[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource



5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0


for 2,9,5049

Then you can use this command to unlock, the pid in this case
is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik

wrote:

I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [3] [2]


 [1]


You can try to release the lease manually using the

 sanlock client


command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be

 unlock


On Thu, May 17, 2018 at 11:05 AM,  wrote:

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO  
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller] 
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e] Command 
CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the volume lease is 
not FREE - the job is running


I tried setting the log level to debug but it seems I have not a 
vdsm-client command. All I have is a vdsm-tool command. Is it 
equivalent?


Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:

By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik 
wrote:


I see because I am on debug level, you need to enable it in order to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [3]

On Thu, 17 May 2018, 13:10 ,  wrote:


Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:

In the vdsm log you will find the volumeInfo log which looks

like

this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)

[jsonrpc.JsonRpcServer]

Return 'Volume.getInfo' in bridge with {'status': 'OK',

'domain':

'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',

'description':

'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':






u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e







b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',

'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0.





[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource






5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0

for 2,9,5049

Then you can use this command to unlock, the pid in this case

is 5049


sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik



wrote:


I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [2]

[1]


You can try to release the lease manually using the

sanlock client

command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be

unlock


On Thu, May 17, 2018 at 11:05 AM,  wrote:


Hi,

We're running oVirt 4.1.9 (I know it's not the recommended
version, but we can't upgrade yet) and recently we had an

issue

with a Storage Domain while a VM was moving a disk. The

Storage

Domain went down for a few minutes, then it got back.

However, the disk's state has stuck in a 'Migrating: 10%'

state

(see ss-2.png).

I run the 'unlock_entity.sh' script to try to unlock the

disk,

with these parameters:

 # PGPASSWORD=...
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t

disk -u

engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38

The disk's state changed to 'OK', but the actual state still
states it's migrating (see ss-1.png).

Calling the script with -t all doesn't make a difference

either.


Currently, the disk is unmanageable: cannot be deactivated,

moved

or copied, as it says there's a copying operation running

already.


Could someone provide a way to unlock this disk? I don't mind
modifying a value directly into the database, I just need the
copying process cancelled.

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org




Links:
--
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [2]




Links:
--
[1] http://10.35.0.
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
[3] https://www.ovirt.org/develop/developer-guide/vdsm/log-files/

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

This is vdsm 4.19.45. I grepped the disk uuid in /var/log/sanlock.log 
but unfortunately no entry there...


El 2018-05-17 13:11, Benny Zlotnik escribió:

Which vdsm version are you using?

You can try looking for the image uuid in /var/log/sanlock.log

On Thu, May 17, 2018 at 2:40 PM,  wrote:


Thanks.

I've been able to see the line in the log, however, the format
differs slightly from yours.

  2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer] Calling 'Volume.getInfo' in bridge with
{u'storagepoolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63',
u'imageID': u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID':
u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID':
u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer] Return 'Volume.getInfo' in bridge with
{'status': 'OK', 'domain': '1876ab86-216f-4a37-a36b-2b5d99fcaad0',
'voltype': 'INTERNAL', 'description': 'None', 'parent':
'ea9a0182-329f-4b8f-abe3-e894de95dac0', 'format': 'COW',
'generation': 1, 'image': 'b4013aba-a936-4a54-bb14-670d3a8b7c38',
'ctime': '1526470759', 'disktype': '2', 'legality': 'LEGAL',
'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool':
'', 'capacity': '21474836480', 'uuid':
u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': '1073741824',
'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}}
(__init__:582)

As you can see, there's no path field there.

How should I procceed?

El 2018-05-17 12:01, Benny Zlotnik escribió:
vdsm-client replaces vdsClient, take a look
here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
[1]
[4]

On Thu, May 17, 2018 at 1:57 PM,  wrote:

The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO 
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the
volume lease is not FREE - the job is running

I tried setting the log level to debug but it seems I have not a
vdsm-client command. All I have is a vdsm-tool command. Is it
equivalent?

Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:
By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik

wrote:

I see because I am on debug level, you need to enable it in order
to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [2]
[1]

[3]

On Thu, 17 May 2018, 13:10 ,  wrote:

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:
In the vdsm log you will find the volumeInfo log which looks
like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK',
'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',
'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':



 u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e




b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',


'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0. [3] [2]



[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource



5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0


for 2,9,5049

Then you can use this command to unlock, the pid in this case
is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik

wrote:

I believe you've hit this
bug: 

[ovirt-users] Re: General failure

[nicolas]

Hi Benny,

Please find the logs at [1].

Thank you.

  [1]: 
https://wetransfer.com/downloads/12208fb4a6a5df3114bbbc10af194c8820180618101223/647c066b7b91096570def304da86dbca20180618101223/583d3d


El 2018-06-18 09:28, Benny Zlotnik escribió:

Can you provide full engine and vdsm logs?

On Mon, Jun 18, 2018 at 11:20 AM,  wrote:


Hi,

We're running oVirt 4.1.9 (we cannot upgrade at this time) and
we're having a major problem in our infrastructure. On friday, a
snapshots were automatically created on more than 200 VMs and as
this was just a test task, all of them were deleted at the same
time, which seems to have corrupted several VMs.

When trying to delete a snapshot on some of the VMs, a "General
error" is thrown with a NullPointerException in the engine log
(attached).

But the worst part is that when some of these machines is powered
off and then powered on, the VMs are corrupt...

VM myvm is down with error. Exit message: Bad volume specification
{u'index': 0, u'domainID': u'110ea376-d789-40a1-b9f6-6b40c31afe01',
'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'address':
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'1fd0f9aa-6505-45d2-a17e-859bd5dd4290', 'apparentsize':
'23622320128', u'imageID': u'65519220-68e1-462a-99b3-f0763c78eae2',
u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'optional': u'false', u'deviceId':
u'65519220-68e1-462a-99b3-f0763c78eae2', 'truesize': '23622320128',
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type':
u'disk'}.

We're really frustrated by now and don't know how to procceed... We
have a DB backup (with engine-backup) from thursday which would have
a "sane" DB definition without all the snapshots, as they were all
created on friday. Would it be safe to restore this backup?

Any help is really appreciated...

Thanks.
___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

[3]




Links:
--
[1] https://www.ovirt.org/site/privacy-policy/
[2] https://www.ovirt.org/community/about/community-guidelines/
[3]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

___
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/DDDBLNYMIJV222MK4QS6UPALQ7WRA6M3/

[ovirt-users] Re: General failure

[nicolas]

Hi Marcelo,

Do you mean copying the whole disk block to a different device and 
attaching it to a new VM?


Anything will be appreciated, as currently we're facing a distressing 
situation, so if you can describe what you mean I'd be grateful.


Thanks.

El 2018-06-18 16:19, Marcelo Leandro escribió:

Hello, 
Do you can copy diskbase to a new vm.

If you want I can describe the step.

Em seg, 18 de jun de 2018 11:49,  escreveu:


Indeed, when the problem started I think the SPM was the host I
added as
VDSM log in the first e-mail. Currently it is the one I sent in the

second mail.

FWIW, if it helps to debug more fluently, we can provide VPN access
to
our infrastructure so you can access and see whateve you need (all
hosts, DB, etc...).

Right now the machines that keep running work, but once shut down
they
start showing the problem below...

Thank you

El 2018-06-18 15:20, Benny Zlotnik escribió:

I'm having trouble following the errors, I think the SPM changed

or

the vdsm log from the right host might be missing.

However, I believe what started the problems is this transaction
timeout:

2018-06-15 14:20:51,378+01 ERROR
[org.ovirt.engine.core.bll.tasks.CommandAsyncTask]
(org.ovirt.thread.pool-6-thread-29)
[1db468cb-85fd-4189-b356-d31781461504] [within thread]: endAction

for

action type RemoveSnapshotSingleDisk threw an exception.:
org.springframework.jdbc.CannotGetJdbcConnectionException: Could

not

get JDBC Connection; nested exception is java.sql.SQLException:
javax.resource.ResourceException: IJ000460: Error checking for a
transaction
  at




org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)

[spring-jdbc.jar:4.2.4.RELEASE]
  at




org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:615)

[spring-jdbc.jar:4.2.4.RELEASE]
  at




org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:680)

[spring-jdbc.jar:4.2.4.RELEASE]
  at




org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:712)

[spring-jdbc.jar:4.2.4.RELEASE]
  at




org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:762)

[spring-jdbc.jar:4.2.4.RELEASE]
  at




org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:152)

[dal.jar:]

This looks like a bug

Regardless, I am not sure restoring a backup would help since you
probably have orphaned images on the storage which need to be

removed


Adding Ala

On Mon, Jun 18, 2018 at 4:19 PM,  wrote:


Hi Benny,

Please find the SPM logs at [1].

Thank you

  [1]:






https://wetransfer.com/downloads/62bf649462aabbc2ef21824682b0a08320180618131825/036b7782f58d337baf909a7220d8455320180618131825/5550ee

[1]

[1]

El 2018-06-18 13:19, Benny Zlotnik escribió:
Can you send the SPM logs as well?

On Mon, Jun 18, 2018 at 1:13 PM,  wrote:

Hi Benny,

Please find the logs at [1].

Thank you.

  [1]:







https://wetransfer.com/downloads/12208fb4a6a5df3114bbbc10af194c8820180618101223/647c066b7b91096570def304da86dbca20180618101223/583d3d

[2]

[2]
[1]

El 2018-06-18 09:28, Benny Zlotnik escribió:

Can you provide full engine and vdsm logs?

On Mon, Jun 18, 2018 at 11:20 AM,  wrote:

Hi,

We're running oVirt 4.1.9 (we cannot upgrade at this time) and
we're having a major problem in our infrastructure. On friday, a
snapshots were automatically created on more than 200 VMs and as
this was just a test task, all of them were deleted at the same
time, which seems to have corrupted several VMs.

When trying to delete a snapshot on some of the VMs, a "General
error" is thrown with a NullPointerException in the engine log
(attached).

But the worst part is that when some of these machines is

powered

off and then powered on, the VMs are corrupt...

VM myvm is down with error. Exit message: Bad volume

specification

{u'index': 0, u'domainID':

u'110ea376-d789-40a1-b9f6-6b40c31afe01',

'reqsize': '0', u'format': u'cow', u'bootOrder': u'1',

u'address':

{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'1fd0f9aa-6505-45d2-a17e-859bd5dd4290', 'apparentsize':
'23622320128', u'imageID':

u'65519220-68e1-462a-99b3-f0763c78eae2',

u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'optional': u'false', u'deviceId':
u'65519220-68e1-462a-99b3-f0763c78eae2', 'truesize':

'23622320128',

u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off',

u'type':

u'disk'}.

We're really frustrated by now and don't know how to procceed...

We

have a DB backup (with engine-backup) from thursday which would
have
a "sane" DB definition without all the snapshots, as they were

all

created on friday. Would it be safe to restore this backup?

Any help is really appreciated...

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email 

[ovirt-users] Re: General failure

[nicolas]

Indeed, when the problem started I think the SPM was the host I added as 
VDSM log in the first e-mail. Currently it is the one I sent in the 
second mail.


FWIW, if it helps to debug more fluently, we can provide VPN access to 
our infrastructure so you can access and see whateve you need (all 
hosts, DB, etc...).


Right now the machines that keep running work, but once shut down they 
start showing the problem below...


Thank you

El 2018-06-18 15:20, Benny Zlotnik escribió:

I'm having trouble following the errors, I think the SPM changed or
the vdsm log from the right host might be missing.

However, I believe what started the problems is this transaction
timeout:

2018-06-15 14:20:51,378+01 ERROR
[org.ovirt.engine.core.bll.tasks.CommandAsyncTask]
(org.ovirt.thread.pool-6-thread-29)
[1db468cb-85fd-4189-b356-d31781461504] [within thread]: endAction for
action type RemoveSnapshotSingleDisk threw an exception.:
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
get JDBC Connection; nested exception is java.sql.SQLException:
javax.resource.ResourceException: IJ000460: Error checking for a
transaction
 at
org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)
[spring-jdbc.jar:4.2.4.RELEASE]
 at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:615)
[spring-jdbc.jar:4.2.4.RELEASE]
 at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:680)
[spring-jdbc.jar:4.2.4.RELEASE]
 at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:712)
[spring-jdbc.jar:4.2.4.RELEASE]
 at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:762)
[spring-jdbc.jar:4.2.4.RELEASE]
 at
org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:152)
[dal.jar:]

This looks like a bug

Regardless, I am not sure restoring a backup would help since you
probably have orphaned images on the storage which need to be removed

Adding Ala

On Mon, Jun 18, 2018 at 4:19 PM,  wrote:


Hi Benny,

Please find the SPM logs at [1].

Thank you

  [1]:


https://wetransfer.com/downloads/62bf649462aabbc2ef21824682b0a08320180618131825/036b7782f58d337baf909a7220d8455320180618131825/5550ee

[1]

El 2018-06-18 13:19, Benny Zlotnik escribió:
Can you send the SPM logs as well?

On Mon, Jun 18, 2018 at 1:13 PM,  wrote:

Hi Benny,

Please find the logs at [1].

Thank you.

  [1]:



https://wetransfer.com/downloads/12208fb4a6a5df3114bbbc10af194c8820180618101223/647c066b7b91096570def304da86dbca20180618101223/583d3d

[2]
[1]

El 2018-06-18 09:28, Benny Zlotnik escribió:

Can you provide full engine and vdsm logs?

On Mon, Jun 18, 2018 at 11:20 AM,  wrote:

Hi,

We're running oVirt 4.1.9 (we cannot upgrade at this time) and
we're having a major problem in our infrastructure. On friday, a
snapshots were automatically created on more than 200 VMs and as
this was just a test task, all of them were deleted at the same
time, which seems to have corrupted several VMs.

When trying to delete a snapshot on some of the VMs, a "General
error" is thrown with a NullPointerException in the engine log
(attached).

But the worst part is that when some of these machines is powered
off and then powered on, the VMs are corrupt...

VM myvm is down with error. Exit message: Bad volume specification
{u'index': 0, u'domainID': u'110ea376-d789-40a1-b9f6-6b40c31afe01',
'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'address':
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'1fd0f9aa-6505-45d2-a17e-859bd5dd4290', 'apparentsize':
'23622320128', u'imageID': u'65519220-68e1-462a-99b3-f0763c78eae2',
u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'optional': u'false', u'deviceId':
u'65519220-68e1-462a-99b3-f0763c78eae2', 'truesize': '23622320128',
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type':
u'disk'}.

We're really frustrated by now and don't know how to procceed... We
have a DB backup (with engine-backup) from thursday which would
have
a "sane" DB definition without all the snapshots, as they were all
created on friday. Would it be safe to restore this backup?

Any help is really appreciated...

Thanks.
___
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/ [3]
[2]
[1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [4] [3]
[2]
List Archives:



https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

[5]
[4]
[3]

Links:
--
[1] https://www.ovirt.org/site/privacy-policy/ [3] [2]
[2] https://www.ovirt.org/community/about/community-guidelines/ [4]
[3]
[3]

[ovirt-users] Re: General failure

[nicolas]

Hi Benny,

Please find the SPM logs at [1].

Thank you

  [1]: 
https://wetransfer.com/downloads/62bf649462aabbc2ef21824682b0a08320180618131825/036b7782f58d337baf909a7220d8455320180618131825/5550ee


El 2018-06-18 13:19, Benny Zlotnik escribió:

Can you send the SPM logs as well?

On Mon, Jun 18, 2018 at 1:13 PM,  wrote:


Hi Benny,

Please find the logs at [1].

Thank you.

  [1]:


https://wetransfer.com/downloads/12208fb4a6a5df3114bbbc10af194c8820180618101223/647c066b7b91096570def304da86dbca20180618101223/583d3d

[1]

El 2018-06-18 09:28, Benny Zlotnik escribió:

Can you provide full engine and vdsm logs?

On Mon, Jun 18, 2018 at 11:20 AM,  wrote:

Hi,

We're running oVirt 4.1.9 (we cannot upgrade at this time) and
we're having a major problem in our infrastructure. On friday, a
snapshots were automatically created on more than 200 VMs and as
this was just a test task, all of them were deleted at the same
time, which seems to have corrupted several VMs.

When trying to delete a snapshot on some of the VMs, a "General
error" is thrown with a NullPointerException in the engine log
(attached).

But the worst part is that when some of these machines is powered
off and then powered on, the VMs are corrupt...

VM myvm is down with error. Exit message: Bad volume specification
{u'index': 0, u'domainID': u'110ea376-d789-40a1-b9f6-6b40c31afe01',
'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'address':
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'1fd0f9aa-6505-45d2-a17e-859bd5dd4290', 'apparentsize':
'23622320128', u'imageID': u'65519220-68e1-462a-99b3-f0763c78eae2',
u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'optional': u'false', u'deviceId':
u'65519220-68e1-462a-99b3-f0763c78eae2', 'truesize': '23622320128',
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type':
u'disk'}.

We're really frustrated by now and don't know how to procceed... We
have a DB backup (with engine-backup) from thursday which would
have
a "sane" DB definition without all the snapshots, as they were all
created on friday. Would it be safe to restore this backup?

Any help is really appreciated...

Thanks.
___
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/ [2]
[1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [3] [2]
List Archives:



https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

[4]
[3]

Links:
--
[1] https://www.ovirt.org/site/privacy-policy/ [2]
[2] https://www.ovirt.org/community/about/community-guidelines/ [3]
[3]


https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

[4]




Links:
--
[1]
https://wetransfer.com/downloads/12208fb4a6a5df3114bbbc10af194c8820180618101223/647c066b7b91096570def304da86dbca20180618101223/583d3d
[2] https://www.ovirt.org/site/privacy-policy/
[3] https://www.ovirt.org/community/about/community-guidelines/
[4]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5OOGBL3BRZIQ2I46FYELBUIIWT5QK4C/

___
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/PJOVP7GFNSDCQWTEATIGOUYCVUQXIU6H/

[ovirt-users] General failure

[nicolas]

Hi,

We're running oVirt 4.1.9 (we cannot upgrade at this time) and we're 
having a major problem in our infrastructure. On friday, a snapshots 
were automatically created on more than 200 VMs and as this was just a 
test task, all of them were deleted at the same time, which seems to 
have corrupted several VMs.


When trying to delete a snapshot on some of the VMs, a "General error" 
is thrown with a NullPointerException in the engine log (attached).


But the worst part is that when some of these machines is powered off 
and then powered on, the VMs are corrupt...


VM myvm is down with error. Exit message: Bad volume specification 
{u'index': 0, u'domainID': u'110ea376-d789-40a1-b9f6-6b40c31afe01', 
'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'address': 
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x', u'type': 
u'pci', u'slot': u'0x06'}, u'volumeID': 
u'1fd0f9aa-6505-45d2-a17e-859bd5dd4290', 'apparentsize': '23622320128', 
u'imageID': u'65519220-68e1-462a-99b3-f0763c78eae2', u'discard': False, 
u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', 
u'optional': u'false', u'deviceId': 
u'65519220-68e1-462a-99b3-f0763c78eae2', 'truesize': '23622320128', 
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device': u'disk', 
u'shared': u'false', u'propagateErrors': u'off', u'type': u'disk'}.


We're really frustrated by now and don't know how to procceed... We have 
a DB backup (with engine-backup) from thursday which would have a "sane" 
DB definition without all the snapshots, as they were all created on 
friday. Would it be safe to restore this backup?


Any help is really appreciated...

Thanks.2018-06-18 08:55:27,157+01 ERROR 
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand] (default task-121) 
[0e41a07b-3c27-46d9-8587-a4f0b5c9055d] Error during ValidateFailure.: 
java.lang.NullPointerException
at 
org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.getTotalSizeForMerge(StorageDomainValidator.java:121)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.hasSpaceForMerge(StorageDomainValidator.java:207)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.lambda$allDomainsHaveSpaceForMerge$0(MultipleStorageDomainsValidator.java:128)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.validOrFirstFailure(MultipleStorageDomainsValidator.java:190)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.allDomainsHaveSpaceForMerge(MultipleStorageDomainsValidator.java:125)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.validateStorageDomains(RemoveSnapshotCommand.java:381)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.validate(RemoveSnapshotCommand.java:359)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:840) 
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:390) 
[bll.jar:]
at 
org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13)
 [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:516) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:498) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451) 
[bll.jar:]
at sun.reflect.GeneratedMethodAccessor622.invoke(Unknown Source) 
[:1.8.0_171]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [rt.jar:1.8.0_171]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_171]
at 
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at 
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at 
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at 
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
 [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at 
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
 [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at 
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
 [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at 
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at 
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at 
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at 

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

There's no such field in the output. There's a similar one called 
commandId (maybe because this is 4.1.9?).


An output has this format:

 {   
   +
   "@class" : 
"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 
 +
   "commandId" : [ "org.ovirt.engine.core.compat.Guid", {
   +
 "uuid" : "a13f9eb4-1b0b-4ea3-924c-bd519af7853b" 
   +
   } ],  
   +
   "parametersCurrentUser" : {   
   +
 "@class" : 
"org.ovirt.engine.core.common.businessentities.aaa.DbUser",  
   +
 "id" : [ "org.ovirt.engine.core.compat.Guid", { 
   +
   "uuid" : "5e0f9455-e9b5-4445-adb0-0058fc604bef"   
   +
 } ],
   +
 "externalId" : "fdfc627c-d875-11e0-90f0-83df133b58cc",  
   +
 "domain" : "internal",  
   +
 "namespace" : "*",  
   +
 "loginName" : "admin",  
   +
 "firstName" : "admin",  
   +
 "lastName" : "",
   +
 "department" : "",  
   +
 "email" : "",   
   +
 "note" : "",
   +
 "groupNames" : [ "java.util.ArrayList", [ ] ],  
   +
 "groupIds" : [ "java.util.ArrayList", [ ] ],
   +
 "admin" : true, 
   +
 "group" : false 
   +
   },
   +
   "compensationEnabled" : false,
   +
   "parentCommand" : "Unknown",  
   +
   "commandType" : "Unknown",
   +
   "multipleAction" : true,  
   +
   "entityInfo" : null,  
   +
   "taskGroupSuccess" : true,
   +
   "vdsmTaskIds" : null, 
   +
   "vdsRunningOn" : null,
   +
   "endProcedure" : "PARENT_MANAGED",
   +
   "useCinderCommandCallback" : false,   
   +
   "correlationId" : "adf5f92f-7fa8-41c9-af2f-4c116f7b6d55", 
   +
   "jobId" : null,   
   +
   "stepId" : null,  
   +
   "jobWeight" : null,   
   +
   "operationsJobWeight" : [ "java.util.Collections$EmptyMap", { } ],
   +
   "lockProperties" : {  
   +
 "scope" : "Execution",  
   +
 "wait" : false  
   +
   },
   +
   "lifeInMinutes" : null,   
   

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

Hi Ala,

All vmSnapshotId fields are null.

Could it be that this could be solved by running what there's on comment 
19 in [1]?


  [1]: https://bugzilla.redhat.com/show_bug.cgi?id=145#c19

El 2018-06-25 10:20, Ala Hino escribió:

I understand.

Back to command entities. 
For each active command_parameter_class
org.ovirt.engine.core.common.action.RemoveSnapshotParameters, you will
find the command params in command_parameters column. One of these
params, is the snapshotId. You need to check whether there is a
snapshot with that Id in snapshots table.

On Mon, Jun 25, 2018 at 11:48 AM,  wrote:


Currently there are no merge related commands running, if you mean
that we're aware of some merge should be happening (it shouldn't). I
restarted the engine but the event is still showing up every 10
seconds.

El 2018-06-25 09:39, Ala Hino escribió:
Do you have any running merge related commands now?
Is it possible for you to restart the engine? I want to see if
restarting the engine, while the merge commands already manually
repaired, may cause that log message to stop appearing.

On Mon, Jun 25, 2018 at 11:06 AM,  wrote:

So if I have this entry, for example, what should I do next?

 cc7764c5-dbc3-4886-bdd6-dabcc756cf6a |          235 |
cc7764c5-dbc3-4886-bdd6-dabcc756cf6a | {                 
                                           
 
                                          +|
org.ovir
t.engine.core.common.action.Re [1] [1]moveDiskSnapshotsParameters |
2018-06-15 09:39:16.846795+01 | ACTIVE | t                |
f                 | {
                                           
                +|
org.ovirt.engine.core.common.action.VdcReturnValueBase | t     
  | 5e0f9455-e9b5-4445-adb0-0058fc604bef |
---- | { }
  |                699165 | {                   
                               +
                                      |     
        |                                   
  |   "@class" :



"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 

                        +|
                                           
              |                             
 |        |                  |               
   |   "valid" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   "jobId" : [
"org.ovirt.engine.core.compat.Guid", {+
                                      |     
        |                                   
  |   "commandId" : [ "org.ovirt.engine.core.compat.Guid", { 
 
                                           
 
 +|
                                           
              |                             
 |        |                  |               
   |   "validationMessages" : [ "VAR__ACTION__REMOVE",
"VAR__TYPE__DISK__SNAP
SHOT", "VAR__ACTION__REMOVE", "VAR__TYPE__DISK__SNAPSHOT" ],+|   
                                           
 
      |          |                           
          |                                 
    |
  |                       |     "uuid" :
"2f1ee2a3-fa2f-48b1-924b-9bfa6497f3b3" +
                                      |     
        |                                   
  |     "uuid" : "cc7764c5-dbc3-4886-bdd6-dabcc756cf6a"     
                                           
 
    +|
                                           
              |                             
 |        |                  |               
   |   "succeeded" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   } ],           
                                  +
                                      |     
        |                                   
  |   } ],                                   
                                           
 
                   +|
                                           
              |                             
 |        |                  |               
   |   "isSyncronious" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   "stepId" : null,   
                              +
                                      |     
        |                                   
  |   "parametersCurrentUser" : {                   
 
                                           
 
          +|
                                           
              |                             
 |        |                  |               
   |   "description" : "",
                                           
                +|                           
  

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

Yes, it returned 0 rows:

engine=#  select command_parameters from command_entities where 
command_params_class = 
'org.ovirt.engine.core.common.action.RemoveSnapshotParameters' and 
status = 'ACTIVE';

 command_parameters

(0 rows)

El 2018-06-25 11:55, Ala Hino escribió:

There is a correlationId field, I marked below.
Can you please the following statement and send the output?

select command_parameters from command_entities where
command_params_class =
'org.ovirt.engine.core.common.action.RemoveSnapshotParameters' and
status = 'ACTIVE'

On Mon, Jun 25, 2018 at 1:21 PM,  wrote:


There's no such field in the output. There's a similar one called
commandId (maybe because this is 4.1.9?).

An output has this format:

 {                                         
                                             
                  +
   "@class" :


"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 

                        +
   "commandId" : [ "org.ovirt.engine.core.compat.Guid", {     
                                           
 +
     "uuid" : "a13f9eb4-1b0b-4ea3-924c-bd519af7853b"       
                                             
  +
   } ],                                     
                                             
                 +
   "parametersCurrentUser" : {                       
                                             
        +
     "@class" :
"org.ovirt.engine.core.common.businessentities.aaa.DbUser",     
                           +
     "id" : [ "org.ovirt.engine.core.compat.Guid", {       
                                             
  +
       "uuid" : "5e0f9455-e9b5-4445-adb0-0058fc604bef"     
                                             
  +
     } ],                                   
                                             
                 +
     "externalId" : "fdfc627c-d875-11e0-90f0-83df133b58cc",   
                                           
 +
     "domain" : "internal",                       
                                             
           +
     "namespace" : "*",                           
                                             
           +
     "loginName" : "admin",                       
                                             
           +
     "firstName" : "admin",                       
                                             
           +
     "lastName" : "",                           
                                             
             +
     "department" : "",                           
                                             
           +
     "email" : "",                             
                                             
              +
     "note" : "",                               
                                             
             +
     "groupNames" : [ "java.util.ArrayList", [ ] ],       
                                             
   +
     "groupIds" : [ "java.util.ArrayList", [ ] ],         
                                             
   +
     "admin" : true,                             
                                             
            +
     "group" : false                             
                                             
            +
   },                                       
                                             
                 +
   "compensationEnabled" : false,                     
                                             
       +
   "parentCommand" : "Unknown",                     
                                             
         +
   "commandType" : "Unknown",                       
                                             
         +
   "multipleAction" : true,                         
                                             
         +
   "entityInfo" : null,                           
                                             
           +
   "taskGroupSuccess" : true,                       
                                             
         +
   "vdsmTaskIds" : null,                           
                                             
          +
   "vdsRunningOn" : null,                         
                                             
           +
   "endProcedure" : "PARENT_MANAGED",                 
                                             
       +
   "useCinderCommandCallback" : false,                 
                                             
      +
   "CORRELATIONID" : "ADF5F92F-7FA8-41C9-AF2F-4C116F7B6D55",   
                                            +
   "jobId" : null,                               
                                             
            +
   "stepId" : null,                             
                                             
             +
   "jobWeight" : null,                           
                                             
            +
   "operationsJobWeight" : [ "java.util.Collections$EmptyMap", {
} 

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

I tried cloning the VM and deleting the original so maybe it would also 
delete the related tasks... but it didn't, instead of:


   Failed to delete snapshot '' for VM 'vmname'.

It now shows:

   Failed to delete snapshot '' for VM ''.

Any tip on how to solve this, please?

Thanks

El 2018-06-25 13:28, nico...@devels.es escribió:

Yes, it returned 0 rows:

engine=#  select command_parameters from command_entities where
command_params_class =
'org.ovirt.engine.core.common.action.RemoveSnapshotParameters' and
status = 'ACTIVE';
 command_parameters

(0 rows)

El 2018-06-25 11:55, Ala Hino escribió:

There is a correlationId field, I marked below.
Can you please the following statement and send the output?

select command_parameters from command_entities where
command_params_class =
'org.ovirt.engine.core.common.action.RemoveSnapshotParameters' and
status = 'ACTIVE'

On Mon, Jun 25, 2018 at 1:21 PM,  wrote:


There's no such field in the output. There's a similar one called
commandId (maybe because this is 4.1.9?).

An output has this format:

 {                                         
                                             
                  +
   "@class" :


"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 

                        +
   "commandId" : [ "org.ovirt.engine.core.compat.Guid", {     
                                           
 +
     "uuid" : "a13f9eb4-1b0b-4ea3-924c-bd519af7853b"       
                                             
  +
   } ],                                     
                                             
                 +
   "parametersCurrentUser" : {                       
                                             
        +
     "@class" :
"org.ovirt.engine.core.common.businessentities.aaa.DbUser",     
                           +
     "id" : [ "org.ovirt.engine.core.compat.Guid", {       
                                             
  +
       "uuid" : "5e0f9455-e9b5-4445-adb0-0058fc604bef"     
                                             
  +
     } ],                                   
                                             
                 +
     "externalId" : "fdfc627c-d875-11e0-90f0-83df133b58cc",   
                                           
 +
     "domain" : "internal",                       
                                             
           +
     "namespace" : "*",                           
                                             
           +
     "loginName" : "admin",                       
                                             
           +
     "firstName" : "admin",                       
                                             
           +
     "lastName" : "",                           
                                             
             +
     "department" : "",                           
                                             
           +
     "email" : "",                             
                                             
              +
     "note" : "",                               
                                             
             +
     "groupNames" : [ "java.util.ArrayList", [ ] ],       
                                             
   +
     "groupIds" : [ "java.util.ArrayList", [ ] ],         
                                             
   +
     "admin" : true,                             
                                             
            +
     "group" : false                             
                                             
            +
   },                                       
                                             
                 +
   "compensationEnabled" : false,                     
                                             
       +
   "parentCommand" : "Unknown",                     
                                             
         +
   "commandType" : "Unknown",                       
                                             
         +
   "multipleAction" : true,                         
                                             
         +
   "entityInfo" : null,                           
                                             
           +
   "taskGroupSuccess" : true,                       
                                             
         +
   "vdsmTaskIds" : null,                           
                                             
          +
   "vdsRunningOn" : null,                         
                                             
           +
   "endProcedure" : "PARENT_MANAGED",                 
                                             
       +
   "useCinderCommandCallback" : false,                 
                                             
      +
   "CORRELATIONID" : "ADF5F92F-7FA8-41C9-AF2F-4C116F7B6D55",   
                                            +
   "jobId" : null,                               
                 

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

engine=# SELECT status FROM command_entities;
   status

 FAILED
 ENDED_SUCCESSFULLY
 FAILED
 FAILED
 UNKNOWN
 UNKNOWN
 ENDED_WITH_FAILURE
 ENDED_WITH_FAILURE
 ENDED_WITH_FAILURE
 ENDED_WITH_FAILURE
 ACTIVE
 ACTIVE
 SUCCEEDED
 SUCCEEDED
 ACTIVE
 ACTIVE
 ACTIVE
 SUCCEEDED
 SUCCEEDED
 SUCCEEDED
 ACTIVE
 SUCCEEDED
(22 rows)

Is it safe to just remove the events in this table?

Thanks

El 2018-06-25 08:43, Ala Hino escribió:

I'd look into command_entites table in the database. 
You will probably see several merge related commands that are not in
END_(SUCCESSFULLY/FAILED) status.

On Mon, Jun 25, 2018 at 10:30 AM,  wrote:


Hi,

We're running oVirt 4.1.9, recently we had an issue with snapshots
so we had to fix them manually. The issue is mostly solved but now
we're seeing a lot of events like this one:

   2018-06-25 07:58:06,637+01 ERROR


[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

(DefaultQuartzScheduler6) [91430fc5-284d-4c26-8d8d-b7bf4053a7e4]
EVENT_ID: USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Correlation
ID: 91430fc5-284d-4c26-8d8d-b7bf4053a7e4, Job ID:
da8120a4-9c6d-4379-ad67-a3808db1fd46, Call Stack: null, Custom ID:
null, Custom Event ID: -1, Message: Failed to delete snapshot
'' for VM 'vmname'.

Which generates the following event in the manager:

   Failed to delete snapshot '' for VM 'vmname'.

This event is being generated every 10 seconds, so it's kind of
annoying.

Any way to remove it manually? It doesn't matter if it entails
touching the DB directly.

Thanks.
___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/QYCTXTBGPB25LZYVXGKROG6SSKOCODMQ/

[3]




Links:
--
[1] https://www.ovirt.org/site/privacy-policy/
[2] https://www.ovirt.org/community/about/community-guidelines/
[3]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QYCTXTBGPB25LZYVXGKROG6SSKOCODMQ/

___
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/BRIK5I3MKYQS5OM6564TE6WARTQTP6L2/

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

So if I have this entry, for example, what should I do next?

 cc7764c5-dbc3-4886-bdd6-dabcc756cf6a |  235 | 
cc7764c5-dbc3-4886-bdd6-dabcc756cf6a | { 
 
+| org.ovir
t.engine.core.common.action.RemoveDiskSnapshotsParameters | 2018-06-15 
09:39:16.846795+01 | ACTIVE | t| f | {
+| 
org.ovirt.engine.core.common.action.VdcReturnValueBase | t| 
5e0f9455-e9b5-4445-adb0-0058fc604bef | 
---- | { }
  |699165 | {
   +
  |  |   
   |   "@class" : 
"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 
 +|
  |  
 ||  |   |   
"valid" : true,
+|   
 |  |
  |  |
  |   |   "jobId" : [ 
"org.ovirt.engine.core.compat.Guid", {+
  |  |   
   |   "commandId" : [ 
"org.ovirt.engine.core.compat.Guid", {   
+|
  |  
 ||  |   |   
"validationMessages" : [ "VAR__ACTION__REMOVE", "VAR__TYPE__DISK__SNAP
SHOT", "VAR__ACTION__REMOVE", "VAR__TYPE__DISK__SNAPSHOT" ],+|   
 |  |
  |  |
  |   | "uuid" : 
"2f1ee2a3-fa2f-48b1-924b-9bfa6497f3b3" +
  |  |   
   | "uuid" : "cc7764c5-dbc3-4886-bdd6-dabcc756cf6a" 
   +|
  |  
 ||  |   |   
"succeeded" : true,
+|   
 |  |
  |  |
  |   |   } ],   
   +
  |  |   
   |   } ],  
   +|
  |  
 ||  |   |   
"isSyncronious" : true,
+|   
 |  |
  |  |
  |   |   "stepId" : null,   
   +
  |  |   
   |   "parametersCurrentUser" : {   
   +|
  |  
 ||  |   |   
"description" : "",
+|   
 |  |
  |  |
  |   |   "executionMethod" : "AsJob",   
   +
  |  |   
   | "@class" : 
"org.ovirt.engine.core.common.businessentities.aaa.DbUser",  
   +|
  |  
 ||  |   |   
"taskPlaceHolderIdList" : [ ],
+|   
 |  |
  |  |
  |   |   "monitored" : true,
   +
  |  |   
   | "id" : [ "org.ovirt.engine.core.compat.Guid", { 
   +|
   

[ovirt-users] Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

Hi,

We're running oVirt 4.1.9, recently we had an issue with snapshots so we 
had to fix them manually. The issue is mostly solved but now we're 
seeing a lot of events like this one:


   2018-06-25 07:58:06,637+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(DefaultQuartzScheduler6) [91430fc5-284d-4c26-8d8d-b7bf4053a7e4] 
EVENT_ID: USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Correlation ID: 
91430fc5-284d-4c26-8d8d-b7bf4053a7e4, Job ID: 
da8120a4-9c6d-4379-ad67-a3808db1fd46, Call Stack: null, Custom ID: null, 
Custom Event ID: -1, Message: Failed to delete snapshot '' for 
VM 'vmname'.


Which generates the following event in the manager:

   Failed to delete snapshot '' for VM 'vmname'.

This event is being generated every 10 seconds, so it's kind of 
annoying.


Any way to remove it manually? It doesn't matter if it entails touching 
the DB directly.


Thanks.
___
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/QYCTXTBGPB25LZYVXGKROG6SSKOCODMQ/

[ovirt-users] Re: Failed to delete snapshot '' for VM 'vmname'.

[nicolas]

Currently there are no merge related commands running, if you mean that 
we're aware of some merge should be happening (it shouldn't). I 
restarted the engine but the event is still showing up every 10 seconds.


El 2018-06-25 09:39, Ala Hino escribió:

Do you have any running merge related commands now?
Is it possible for you to restart the engine? I want to see if
restarting the engine, while the merge commands already manually
repaired, may cause that log message to stop appearing.

On Mon, Jun 25, 2018 at 11:06 AM,  wrote:


So if I have this entry, for example, what should I do next?

 cc7764c5-dbc3-4886-bdd6-dabcc756cf6a |          235 |
cc7764c5-dbc3-4886-bdd6-dabcc756cf6a | {                 
                                             
                                          +|
org.ovir
t.engine.core.common.action.Re [1]moveDiskSnapshotsParameters |
2018-06-15 09:39:16.846795+01 | ACTIVE | t                |
f                 | {
                                           
                +|
org.ovirt.engine.core.common.action.VdcReturnValueBase | t     
  | 5e0f9455-e9b5-4445-adb0-0058fc604bef |
---- | { }
  |                699165 | {                   
                               +
                                      |     
        |                                   
  |   "@class" :


"org.ovirt.engine.core.common.action.RemoveDiskSnapshotsParameters", 

                        +|
                                           
              |                             
 |        |                  |               
   |   "valid" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   "jobId" : [
"org.ovirt.engine.core.compat.Guid", {+
                                      |     
        |                                   
  |   "commandId" : [ "org.ovirt.engine.core.compat.Guid", {   
                                             
 +|
                                           
              |                             
 |        |                  |               
   |   "validationMessages" : [ "VAR__ACTION__REMOVE",
"VAR__TYPE__DISK__SNAP
SHOT", "VAR__ACTION__REMOVE", "VAR__TYPE__DISK__SNAPSHOT" ],+|   
                                             
      |          |                           
          |                                 
    |
  |                       |     "uuid" :
"2f1ee2a3-fa2f-48b1-924b-9bfa6497f3b3" +
                                      |     
        |                                   
  |     "uuid" : "cc7764c5-dbc3-4886-bdd6-dabcc756cf6a"     
                                             
    +|
                                           
              |                             
 |        |                  |               
   |   "succeeded" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   } ],           
                                  +
                                      |     
        |                                   
  |   } ],                                   
                                             
                   +|
                                           
              |                             
 |        |                  |               
   |   "isSyncronious" : true,
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   "stepId" : null,   
                              +
                                      |     
        |                                   
  |   "parametersCurrentUser" : {                     
                                             
          +|
                                           
              |                             
 |        |                  |               
   |   "description" : "",
                                           
                +|                           
                            |          |     
                                |           
                          |
  |                       |   "executionMethod" :
"AsJob",                      +
                                      |     
        |                                   
  |     "@class" :
"org.ovirt.engine.core.common.businessentities.aaa.DbUser",     
                           +|
                                           
              |                             
 |        |                  |               
   |   "taskPlaceHolderIdList" : [ ],
                                

[ovirt-users] Re: General failure

[nicolas]

Hi Ala,

Yes, there's no way to remove it. I actually found a way to workaround 
the issue, I'm posting it so other people can have a clue how to solve 
it...


I'm fully aware that touching the DB directly is not a good idea but 
I've been unable to find an alternative way.


1) Find the broken snapshot in the snapshots table and delete it.

engine=# select snapshot_id,snapshot_type,status,description from 
snapshots where vm_id='343db85c-64bc-4f0c-b9a0-4ca8d129e0c3';
 snapshot_id  | snapshot_type | status | 
   description

--+---++---
 3d1eaf0a-49b3-45be-a104-f5ceebe52540 | ACTIVE| OK | Active 
VM
 cb8672bb-38d3-47ee-a498-4b403fc7d8db | REGULAR   | OK | Broken 
snapshot

(2 rows)

2) Find the image linked to the broken snapshot (you must find the disk 
in the Disks tab and write the UUID).


engine=# select 
image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active 
from images where image_group_id='6cf2c490-784b-437f-8305-1bed40dc9c9d';
  image_guid  |   parentid   
| imagestatus |vm_snapshot_id| volume_type | 
volume_format | active

--+--+-+--+-+---+
 b7af66ad-d27b-4087-9c33-11625912a45f | 
---- |   4 | 
cb8672bb-38d3-47ee-a498-4b403fc7d8db |   1 | 5 | f
 7f14ae53-feac-4088-9560-c77a16dcd5e3 | 
b7af66ad-d27b-4087-9c33-11625912a45f |   1 | 
3d1eaf0a-49b3-45be-a104-f5ceebe52540 |   2 | 4 | t

(2 rows)

3) Delete the broken snapshot from the snapshots table.

engine=# delete  from snapshots where 
snapshot_id='cb8672bb-38d3-47ee-a498-4b403fc7d8db';

DELETE 1

4) Delete the associated image to the broken snapshots.

engine=# delete from images where 
image_guid='7f14ae53-feac-4088-9560-c77a16dcd5e3';

DELETE 1

At this time, the snapshot is no longer shown on the 'Snapshots' tab of 
the VM. However, when starting the VM, I get an error with something 
like this:


VM SED-tpl is down with error. Exit message: Bad volume specification 
{u'index': 0, u'domainID': u'110ea376-d789-40a1-b9f6-6b40c31afe01', 
'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'address': 
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x', u'type': 
u'pci', u'slot': u'0x06'}, u'volumeID': 
u'538600a5-31ab-40af-b326-d56bfc92bb0b', 'apparentsize': '34359738368', 
u'imageID': u'e05874d2-fb8a-4fd2-94ff-2f4bc6438d47', u'discard': False, 
u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', 
u'optional': u'false', u'deviceId': 
u'e05874d2-fb8a-4fd2-94ff-2f4bc6438d47', 'truesize': '34359738368', 
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device': u'disk', 
u'shared': u'false', u'propagateErrors': u'off', u'type': u'disk'}.


Now, get the storage domain ID on which the failed snapshot is. You can 
know that by looking at the 'storage_domains' table in the DB. Then, run 
the command that Benny mentioned (being the last UUID the one of the 
storage domain):


vdsm-tool -vvv dump-volume-chains 
bc0480e2-85fe-42a4-91ae-f733b23c801f


That will provide a map of the image list with all volumes and their 
statuses. You should see at least an ILLEGAL one. Despite removing the 
entries from the DB, they seem to still show up  because the snapshot is 
still in metadata and needs to be set as LEGAL. To set it as legal, 
start the VM on a specific host where previously you are 'tail -f'ing 
the vdsm.log. You'll see an entry like this:


2018-06-19 12:13:26,832+0100 INFO  (vm/5bf9a0bb) [vdsm.api] START 
prepareImage(sdUUID=u'bc0480e2-85fe-42a4-91ae-f733b23c801f', 
spUUID=u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', 
imgUUID=u'870f7e85-d9b6-494a-9541-b419fb0e1b32', 
leafUUID=u'd7fa8c51-8cad-4695-b90a-a8d1dc146371', allowIllegal=False) 
from=internal, task_id=89770233-103d-47f3-acc1-45d2e96d9e91 (api:46)


Now, go to the SPM and run a command like this:

  vdsClient -s yourhost.com setVolumeLegality 
bc0480e2-85fe-42a4-91ae-f733b23c801f 
75bf8f48-970f-42bc-8596-f8ab6efb2b63 
870f7e85-d9b6-494a-9541-b419fb0e1b32 
d7fa8c51-8cad-4695-b90a-a8d1dc146371 LEGAL


The VM is now able to power up. I know this is not a clean solution as 
this leaves orphaned snapshots on storage domains, but up until now 
we've not been able to find a better solution. At least now we know 
machines can be powered up and no data loss happened.


If you have any additional tips we'd be glad to know so we can apply 
them.


Thanks.

El 2018-06-19 14:41, Ala Hino escribió:

Hi,

Did you try to remove the same snapshot while the VM is down?

On Tue, Jun 19, 2018 at 10:44 AM,  wrote:


Hi Benny,

I used the tool to track one of the illegal volumes:

   image:    

Re: [ovirt-users] Failed upgrade from 4.1.9 to 4.2.x

[nicolas]

El 2018-02-05 14:03, Simone Tiraboschi escribió:

On Mon, Feb 5, 2018 at 2:46 PM,  wrote:


Hi,

We're trying to upgrade from 4.1.9 to 4.2.x and we're bumping into
an error we don't know how to solve. As per [1] we run the
'engine-setup' command and it fails with:

[ INFO  ] Rolling back to the previous PostgreSQL instance
(postgresql).
[ ERROR ] Failed to execute stage 'Misc configuration': Command
'/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to
execute
[ INFO  ] Yum Performing yum transaction rollback
[ INFO  ] Stage: Clean up
          Log file is located at


/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log

[ INFO  ] Generating answer file
'/var/lib/ovirt-engine/setup/answers/20180205133354-setup.co [1]nf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed

As of the


/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log

file I could see this:

 * upgrading from 'postgresql.service' to
'rh-postgresql95-postgresql.se [2]rvice'
 * Upgrading database.
ERROR: pg_upgrade tool failed
ERROR: Upgrade failed.
 * See /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log for
details.

And this file contains this information:

  Performing Consistency Checks
  -
  Checking cluster versions                         
         ok
  Checking database user is the install user             
    ok
  Checking database connection settings                 
     ok
  Checking for prepared transactions                   
      ok
  Checking for reg* system OID user data types             
  ok
  Checking for contrib/isn with bigint-passing mismatch     
 ok
  Checking for invalid "line" user columns               
    ok
  Creating dump of global objects                     
       ok
  Creating dump of database schemas
    django
    engine
    ovirt_engine_history
    postgres
    template1
                                           
                ok
  Checking for presence of required libraries             
   fatal

  Your installation references loadable libraries that are missing
from the
  new installation.  You can add these libraries to the new
installation,
  or remove the functions using them from the old installation. 
A list of
  problem libraries is in the file:
  loadable_libraries.txt

  Failure, exiting

I'm attaching full logs FWIW. Also, I'd like to mention that we
created two custom triggers on the engine's 'users' table, but as I
understand from the error this is not the issue (We upgraded several
times within the same minor and we had no issues with that).

Could someone shed some light on this error and how to debug it?


Hi,
can you please attach also loadable_libraries.txt ?
 


Could not load library "$libdir/plpython2"
ERROR:  could not access file "$libdir/plpython2": No such file or 
directory


Well, definitely it has to do with the triggers... The trigger uses 
plpython2u to replicate some entries in a different database. Is there a 
way I can get rid of this error other than disabling plpython2 before 
upgrading and re-enabling it after the upgrade?


Thanks.




Thanks.

  [1]: https://www.ovirt.org/release/4.2.0/ [3]
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [4]




Links:
--
[1] http://20180205133354-setup.co
[2] http://rh-postgresql95-postgresql.se
[3] https://www.ovirt.org/release/4.2.0/
[4] http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Failed upgrade from 4.1.9 to 4.2.x

[nicolas]

Hi,

We're trying to upgrade from 4.1.9 to 4.2.x and we're bumping into an 
error we don't know how to solve. As per [1] we run the 'engine-setup' 
command and it fails with:


[ INFO  ] Rolling back to the previous PostgreSQL instance (postgresql).
[ ERROR ] Failed to execute stage 'Misc configuration': Command 
'/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to 
execute

[ INFO  ] Yum Performing yum transaction rollback
[ INFO  ] Stage: Clean up
  Log file is located at 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log
[ INFO  ] Generating answer file 
'/var/lib/ovirt-engine/setup/answers/20180205133354-setup.conf'

[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed

As of the 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log 
file I could see this:


 * upgrading from 'postgresql.service' to 
'rh-postgresql95-postgresql.service'

 * Upgrading database.
ERROR: pg_upgrade tool failed
ERROR: Upgrade failed.
 * See /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log for 
details.


And this file contains this information:

  Performing Consistency Checks
  -
  Checking cluster versions   ok
  Checking database user is the install user  ok
  Checking database connection settings   ok
  Checking for prepared transactions  ok
  Checking for reg* system OID user data typesok
  Checking for contrib/isn with bigint-passing mismatch   ok
  Checking for invalid "line" user columnsok
  Creating dump of global objects ok
  Creating dump of database schemas
django
engine
ovirt_engine_history
postgres
template1
ok
  Checking for presence of required libraries fatal

  Your installation references loadable libraries that are missing from 
the
  new installation.  You can add these libraries to the new 
installation,
  or remove the functions using them from the old installation.  A list 
of

  problem libraries is in the file:
  loadable_libraries.txt

  Failure, exiting

I'm attaching full logs FWIW. Also, I'd like to mention that we created 
two custom triggers on the engine's 'users' table, but as I understand 
from the error this is not the issue (We upgraded several times within 
the same minor and we had no issues with that).


Could someone shed some light on this error and how to debug it?

Thanks.

  [1]: https://www.ovirt.org/release/4.2.0/

upgrade.tar.gz
Description: GNU Zip compressed data
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Add a disk and set the console for a VM in the user portal

[nicolas]

Hi,

We recently upgraded to oVirt 4.2.0 and we're testing things so we can 
determine if our production system might also be upgraded or not. We do 
an extensive use of the User Portal, I've granted the VmCreator and 
DiskProfileUser privileges on a user (the user has a quota as well), I 
logged in to the user portal, I can successfully create a VM setting its 
memory and CPUs but:


1) I can't see a way to change the console type. By default, when the 
machine is created, SPICE is chosen as the mechanism, and I'd like to 
change it to VNC, but I can't find a way.

2) I can't see a way to add a disk to the VM.

I'm attaching a screenshot of what I see in the panel.

Are some new privileges needed to add a disk or change the console type?

Thanks___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Add a disk and set the console for a VM in the user portal

[nicolas]

I can't even see other options, like adding NICs, or changing the 
machine type (server, desktop)... Was this removed on purpose or there's 
some permission(s) to grant?


El 2018-02-06 11:45, nico...@devels.es escribió:

Hi,

We recently upgraded to oVirt 4.2.0 and we're testing things so we can
determine if our production system might also be upgraded or not. We
do an extensive use of the User Portal, I've granted the VmCreator and
DiskProfileUser privileges on a user (the user has a quota as well), I
logged in to the user portal, I can successfully create a VM setting
its memory and CPUs but:

1) I can't see a way to change the console type. By default, when the
machine is created, SPICE is chosen as the mechanism, and I'd like to
change it to VNC, but I can't find a way.
2) I can't see a way to add a disk to the VM.

I'm attaching a screenshot of what I see in the panel.

Are some new privileges needed to add a disk or change the console 
type?


Thanks

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Failed upgrade from 4.1.9 to 4.2.x

[nicolas]

El 2018-02-05 14:48, Martin Perina escribió:

On Mon, Feb 5, 2018 at 3:08 PM,  wrote:


El 2018-02-05 14:03, Simone Tiraboschi escribió:
On Mon, Feb 5, 2018 at 2:46 PM,  wrote:

Hi,

We're trying to upgrade from 4.1.9 to 4.2.x and we're bumping into
an error we don't know how to solve. As per [1] we run the
'engine-setup' command and it fails with:

[ INFO  ] Rolling back to the previous PostgreSQL instance
(postgresql).
[ ERROR ] Failed to execute stage 'Misc configuration': Command
'/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to
execute
[ INFO  ] Yum Performing yum transaction rollback
[ INFO  ] Stage: Clean up
          Log file is located at



/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log

[ INFO  ] Generating answer file
'/var/lib/ovirt-engine/setup/answers/20180205133354-setup.co [1]
[1]nf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed

As of the



/var/log/ovirt-engine/setup/ovirt-engine-setup-20180205133116-sm2xd1.log

file I could see this:

 * upgrading from 'postgresql.service' to
'rh-postgresql95-postgresql.se [2] [2]rvice'
 * Upgrading database.
ERROR: pg_upgrade tool failed
ERROR: Upgrade failed.
 * See /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log for
details.

And this file contains this information:

  Performing Consistency Checks
  -
  Checking cluster versions                         
         ok
  Checking database user is the install user             
    ok
  Checking database connection settings                 
     ok
  Checking for prepared transactions                   
      ok
  Checking for reg* system OID user data types             
  ok
  Checking for contrib/isn with bigint-passing mismatch     
 ok
  Checking for invalid "line" user columns               
    ok
  Creating dump of global objects                     
       ok
  Creating dump of database schemas
    django
    engine
    ovirt_engine_history
    postgres
    template1
                                           
                ok
  Checking for presence of required libraries             
   fatal

  Your installation references loadable libraries that are missing
from the
  new installation.  You can add these libraries to the new
installation,
  or remove the functions using them from the old installation. 
A list of
  problem libraries is in the file:
  loadable_libraries.txt

  Failure, exiting

I'm attaching full logs FWIW. Also, I'd like to mention that we
created two custom triggers on the engine's 'users' table, but as I
understand from the error this is not the issue (We upgraded
several
times within the same minor and we had no issues with that).

Could someone shed some light on this error and how to debug it?

Hi,
can you please attach also loadable_libraries.txt ?
 


 Could not load library "$libdir/plpython2"
 ERROR:  could not access file "$libdir/plpython2": No such file or
directory

​Hmm, you probably need to install
rh-postgresql95-postgresql-plpython package. This is not installed by
default with oVirt as we don't use it
​ 


Indeed, this made it. Thank you very much.




Well, definitely it has to do with the triggers... The trigger uses
plpython2u to replicate some entries in a different database. Is
there a way I can get rid of this error other than disabling
plpython2 before upgrading and re-enabling it after the upgrade?

Thanks.

Thanks.

  [1]: https://www.ovirt.org/release/4.2.0/ [3] [3]
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [4] [4]

Links:
--
[1] http://20180205133354-setup.co [1]
[2] http://rh-postgresql95-postgresql.se [2]
[3] https://www.ovirt.org/release/4.2.0/ [3]
[4] http://lists.ovirt.org/mailman/listinfo/users [4]

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users [4]

--

Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.


Links:
--
[1] http://20180205133354-setup.co
[2] http://rh-postgresql95-postgresql.se
[3] https://www.ovirt.org/release/4.2.0/
[4] http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Add a disk and set the console for a VM in the user portal

[nicolas]

Sorry, but I don't understand what's the new VM portal purpose then... I 
mean, you can create a VM but you can't modify the console type, nor add 
disks, nor add NIC interfaces?


If that's how the new VM portal works, we can't upgrade our oVirt 
infrastructure because as I said, we extensively use the VM portal and 
users need to create their VMs and fully customize them.


Regards.

El 2018-02-07 10:05, Bohdan Iakymets escribió:

Hi,

if you want VNC, you must choose it on adminportal: 'Edit VM' ->
'Console (you need to show advanced options)' -> 'Graphics protocols'.

With the best regards,
Bohdan Iakymets

On Tue, Feb 6, 2018 at 1:13 PM,  wrote:


I can't even see other options, like adding NICs, or changing the
machine type (server, desktop)... Was this removed on purpose or
there's some permission(s) to grant?

El 2018-02-06 11:45, nico...@devels.es escribió:


Hi,

We recently upgraded to oVirt 4.2.0 and we're testing things so
we can
determine if our production system might also be upgraded or not.
We
do an extensive use of the User Portal, I've granted the
VmCreator and
DiskProfileUser privileges on a user (the user has a quota as
well), I
logged in to the user portal, I can successfully create a VM
setting
its memory and CPUs but:

1) I can't see a way to change the console type. By default, when
the
machine is created, SPICE is chosen as the mechanism, and I'd
like to
change it to VNC, but I can't find a way.
2) I can't see a way to add a disk to the VM.

I'm attaching a screenshot of what I see in the panel.

Are some new privileges needed to add a disk or change the
console type?

Thanks

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]




Links:
--
[1] http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Add a disk and set the console for a VM in the user portal

[nicolas]

El 2018-02-07 10:54, Michal Skrivanek escribió:

On 6 Feb 2018, at 13:13, nico...@devels.es wrote:

I can't even see other options, like adding NICs, or changing the 
machine type (server, desktop)... Was this removed on purpose or 
there's some permission(s) to grant?


it just hasn’t been coded. Feel free to open issues or submit patches
for the project[1]



I will open the issues for that. I feel the new interface has been a 
nice improvement but if it doesn't contain all the former 
functionalities it's not useful at all. Our users create their machines 
from scratch with no template (they are engineering students and they 
need to know how to do some basic stuff).


Thank you.





El 2018-02-06 11:45, nico...@devels.es escribió:

Hi,
We recently upgraded to oVirt 4.2.0 and we're testing things so we 
can

determine if our production system might also be upgraded or not. We
do an extensive use of the User Portal, I've granted the VmCreator 
and
DiskProfileUser privileges on a user (the user has a quota as well), 
I

logged in to the user portal, I can successfully create a VM setting
its memory and CPUs but:


yeah, the VM creation in ovirt-ewb-ui is simplistic and relies on the
original Template mostly.


1) I can't see a way to change the console type. By default, when the
machine is created, SPICE is chosen as the mechanism, and I'd like to
change it to VNC, but I can't find a way.


it’s using whatever you have in the Template. Could you change it
there? If you need flexibility then use SPICE+VNC, then clients can
choose either.

Thanks,
michal

[1] https://github.com/oVirt/ovirt-web-ui


2) I can't see a way to add a disk to the VM.
I'm attaching a screenshot of what I see in the panel.
Are some new privileges needed to add a disk or change the console 
type?

Thanks
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Console button greyed out (4.2)

[nicolas]

Thanks guys, setting the VM to headless and then removing this option 
seemed to do the trick. Indeed, this VM was created back in 3.6, however 
it had QXL set in options. Seems that despite this something was not 
migrated correctly.


I think I have more machines in this situation, in case the oVirt team 
would like to make some additional tests.


Regards.

El 2018-02-15 19:39, Vineet Khandpur escribió:

Hello.

Just had the same issue

@ 4.1, upgraded to 4.2(.1)

Updated cluster compatibility, then, data centre compatibility

All VMs lost their hardware (NICs (showed attached but unplugged),
disks (status changed to disabled) and console)

Our solution was simply to connect the NICs, activate the disks, then
edit the VM and set Console to headless.

Shut down the VM

Then before bringing it back up, unchecked headless in the VM

We then had to do a Run-Once which failed

Then did a normal Run.

Console was available, and all hardware came back fine.

Didn't have to delete and re-create anything (although had to perform
the above on all 70+ production hosts including our main web servers
and HA load balancers .. which wasn't fun) ...

Hope this helps someone

vk

On 15 February 2018 at 12:28, John Taylor <jtt77...@gmail.com> wrote:


On Thu, Feb 15, 2018 at 11:54 AM, Michal Skrivanek
<michal.skriva...@redhat.com> wrote:




On 15 Feb 2018, at 15:58, John Taylor <jtt77...@gmail.com>

wrote:


Hi Nicolas,
I had the same problem and it looked like it was because of some

older

vms (I believe from 3.6) that were configured with console with

video

type of CIRRUS and protocol VNC.


3.6 had cirrus indeed. That should work. Can you somehow confirm

it was really a 3.6 VM and it stopped working in 4.2? The exact
steps are important, unfortunately.




I'm pretty sure they were VMs created in 3.6, but I can't say for
absolute certain.  Sorry.


Tracing it out it showed that the vm  libvirt xml was begin set

to

headless.


do you at least recall what cluster level version it was when it

stopped working? The VM definition should have been changed to VGA
when you move the VM from 3.6 cluster to a 4.0+

I upgraded from 4.1.something and I'm pretty sure at the time the
cluster level was 4.1, and those same VMs were able to get
consoles.
Sorry I can't be more help now. I'll see if I have any notes that
might help me remember.




  I tried different settings but the only thing that seemed
to work was to set them to headless, then reopen config and set

them

to something else.

-John

On Thu, Feb 15, 2018 at 8:48 AM,  <nico...@devels.es> wrote:

Hi,

We upgraded one of our infrastructures to 4.2.0 recently and

since then some

of our machines have the "Console" button greyed-out in the

Admin UI, like

they were disabled.

I changed their compatibility to 4.2 but with no luck, as

they're still

disabled.

Is there a way to know why is that, and how to solve it?

I'm attaching a screenshot.

Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]





___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [1]




Links:
--
[1] http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Console button greyed out (4.2)

[nicolas]

Hi,

We upgraded one of our infrastructures to 4.2.0 recently and since then 
some of our machines have the "Console" button greyed-out in the Admin 
UI, like they were disabled.


I changed their compatibility to 4.2 but with no luck, as they're still 
disabled.


Is there a way to know why is that, and how to solve it?

I'm attaching a screenshot.

Thanks.___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] VMs stuck in migrating state

[nicolas]

Hi,

We're running 4.1.9 and during the weekend we had a storage issue that 
seemed to leave some hosts in an strange state. One of the hosts has 
almost all VMs migrating (although it seems to not actually being 
migrating them) and the migration state cannot be cancelled.


When clicking on one of those machines and selecting 'Cancel migration', 
in the ovirt-engine log I see:


2018-02-26 08:52:07,588Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.CancelMigrateVDSCommand] 
(org.ovirt.thread.pool-6-thread-36) 
[887dfbf9-dece-4f7b-90a8-dac02b849b7f] HostName = host2.domain.com
2018-02-26 08:52:07,588Z ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.CancelMigrateVDSCommand] 
(org.ovirt.thread.pool-6-thread-36) 
[887dfbf9-dece-4f7b-90a8-dac02b849b7f] Command 
'CancelMigrateVDSCommand(HostName = host2.domain.com, 
CancelMigrationVDSParameters:{runAsync='true', 
hostId='e63b9146-10c4-47ad-bd6c-f053a8c5b4eb', 
vmId='26d37e43-32e2-4e55-9c1e-1438518d5021'})' execution failed: 
VDSGenericException: VDSErrorException: Failed to CancelMigrateVDS, 
error = Migration process cancelled, code = 82


On the vdsm side I see:

2018-02-26 08:56:19,396+ INFO  (jsonrpc/0) [vdsm.api] START 
migrateCancel() from=:::10.X.X.X,54654, 
flow_id=874d36d7-63f5-4b71-8a4d-6d9f3ec65858 (api:46)
2018-02-26 08:56:19,398+ INFO  (jsonrpc/0) [vdsm.api] FINISH 
migrateCancel return={'status': {'message': 'Migration process 
cancelled', 'code': 82}, 'progress': 0} from=:::10.X.X.X,54654, 
flow_id=874d36d7-63f5-4b71-8a4d-6d9f3ec65858 (api:52)


So no error on the vdsm side log.

I already tried restarting ovirt-engine but it didn't work.

Could someone shed some light on how to cancel the migration status for 
these machines? All of them seem to be running on the same host.


Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Re: General failure

[nicolas]

Hi Benny,

I used the tool to track one of the illegal volumes:

   image:e05874d2-fb8a-4fd2-94ff-2f4bc6438d47

 [...]

 - 887f486b-15cf-4083-9b35-8b7821a7841a
   status: ILLEGAL, voltype: LEAF, format: COW, legality: 
ILLEGAL, type: SPARSE


So I tracked 887f486b-15cf-4083-9b35-8b7821a7841a in the logs and I saw:

2018-06-16 04:46:20,818+01 INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] 
(pool-5-thread-3) [cfc392ec-dc9f-418d-8156-d05c8e7ab9f8] START, 
GetVolumeInfoVDSCommand(HostName = host.domain.es, 
GetVolumeInfoVDSCommandParameters:{expectedEngineErrors='[VolumeDoesNotExist]', 
runAsync='true', hostId='b2dfb945-d767-44aa-a547-2d1a4381f8e3', 
storagePoolId='75bf8f48-970f-42bc-8596-f8ab6efb2b63', 
storageDomainId='110ea376-d789-40a1-b9f6-6b40c31afe01', 
imageGroupId='e05874d2-fb8a-4fd2-94ff-2f4bc6438d47', 
imageId='887f486b-15cf-4083-9b35-8b7821a7841a'}), log id: 2a795424


2018-06-16 04:46:22,256+01 ERROR 
[org.ovirt.engine.core.bll.DestroyImageCheckCommand] (pool-5-thread-3) 
[cfc392ec-dc9f-418d-8156-d05c8e7ab9f8] The following images were not 
removed: [887f486b-15cf-4083-9b35-8b7821a7841a]


2018-06-16 04:47:44,900+01 ERROR 
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand] 
(DefaultQuartzScheduler10) [cfc392ec-dc9f-418d-8156-d05c8e7ab9f8] 
Snapshot '7b6f43ac-d3ad-47b2-8882-f5dccd74cf07' images 
'887f486b-15cf-4083-9b35-8b7821a7841a'..'538600a5-31ab-40af-b326-d56bfc92bb0b' 
merged, but volume removal failed. Some or all of the following volumes 
may be orphaned: [887f486b-15cf-4083-9b35-8b7821a7841a]. Please retry 
Live Merge on the snapshot to complete the operation.


Can you provide some additional steps?

Thank you!

El 2018-06-18 18:27, Benny Zlotnik escribió:

We prevent starting VMs with illegal images[1] 

You can use "$ vdsm-tool dump-volume-chains"
to look for illegal images and then look in the engine log for the
reason they became illagal, 

if it's something like this, it usually means you can remove them:

63696:2018-06-15 09:41:58,134+01 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
(DefaultQuartzScheduler2) [6fa97ea4-8f61-4a48-8e08-a8bb1b9de826]
Merging of snapshot 'e609d6cc-2025-4cf0-ad34-03519131cdd1' images
'1d01c6c8-b61e-42bc-a054-f04c3f792b10'..'ef6f732e-2a7a-4a14-a10f-bcc88bdd805f'
failed. Images have been marked illegal and can no longer be previewed
or reverted to. Please retry Live Merge on the snapshot to complete
the operation.

On Mon, Jun 18, 2018 at 5:46 PM,  wrote:


Indeed, when the problem started I think the SPM was the host I
added as VDSM log in the first e-mail. Currently it is the one I
sent in the second mail.

FWIW, if it helps to debug more fluently, we can provide VPN access
to our infrastructure so you can access and see whateve you need
(all hosts, DB, etc...).

Right now the machines that keep running work, but once shut down
they start showing the problem below...

Thank you

El 2018-06-18 15:20, Benny Zlotnik escribió:

I'm having trouble following the errors, I think the SPM changed or
the vdsm log from the right host might be missing.

However, I believe what started the problems is this transaction
timeout:

2018-06-15 14:20:51,378+01 ERROR
[org.ovirt.engine.core.bll.tasks.CommandAsyncTask]
(org.ovirt.thread.pool-6-thread-29)
[1db468cb-85fd-4189-b356-d31781461504] [within thread]: endAction
for
action type RemoveSnapshotSingleDisk threw an exception.:
org.springframework.jdbc.CannotGetJdbcConnectionException: Could
not
get JDBC Connection; nested exception is java.sql.SQLException:
javax.resource.ResourceException: IJ000460: Error checking for a
transaction
 at


org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80)

[spring-jdbc.jar:4.2.4.RELEASE]
 at


org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:615)

[spring-jdbc.jar:4.2.4.RELEASE]
 at


org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:680)

[spring-jdbc.jar:4.2.4.RELEASE]
 at


org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:712)

[spring-jdbc.jar:4.2.4.RELEASE]
 at


org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:762)

[spring-jdbc.jar:4.2.4.RELEASE]
 at


org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:152)

[dal.jar:]

This looks like a bug

Regardless, I am not sure restoring a backup would help since you
probably have orphaned images on the storage which need to be
removed

Adding Ala

On Mon, Jun 18, 2018 at 4:19 PM,  wrote:

Hi Benny,

Please find the SPM logs at [1].

Thank you

  [1]:



https://wetransfer.com/downloads/62bf649462aabbc2ef21824682b0a08320180618131825/036b7782f58d337baf909a7220d8455320180618131825/5550ee

[1]
[1]

El 2018-06-18 13:19, Benny Zlotnik escribió:
Can you send the SPM logs as well?

On Mon, Jun 18, 2018 at 1:13 PM,  wrote:

Hi Benny,

[ovirt-users] Re: Python-SDK4: Check snapshot deletion result?

[nicolas]

Hi Benny,

El 2018-07-12 08:50, Benny Zlotnik escribió:

Perhaps you can query the status of job using the correlation id
(taking the examples from ovirt-system-tests):
  dead_snap1_params = types.Snapshot(

        description=SNAPSHOT_DESC_1,
        persist_memorystate=False,
        disk_attachments=[
            types.DiskAttachment(
                disk=types.Disk(
                    id=disk.id [5]
                )
            )
        ]
    )
    correlation_id = uuid.uuid4()

    vm1_snapshots_service.add(dead_snap1_params,
                              query={'correlation_id':
correlation_id})

    testlib.assert_true_within_long(
        lambda:
        test_utils.all_jobs_finished(engine, correlation_id)
    )



I tried this approach but with the snapshot deletion task instead of 
creating one.


customuuid = uuid4()
snaps_service.service(newsnap.id).remove(query={'correlation_id': 
customuuid})


However, when this task is run, I see no task with this correlation_id. 
Moreover, I cannot find a correlation_id field in the job object.


In [40]: job
Out[40]: 

In [41]: job.
job.auto_cleared  job.description   job.external  job.id
job.name  job.start_timejob.steps
job.comment   job.end_time  job.href  job.last_updated  
job.owner job.status


The 'id' field doesn't correspond to the correlation_id generated above.


All jobs finished checks that jobs with correlation_id have finished,
it is implemented like this[2]:

def all_jobs_finished(engine, correlation_id):
    try:
        jobs = engine.jobs_service().list(
            search='correlation_id=%s' % correlation_id
        )
    except:
        jobs = engine.jobs_service().list()
    return all(job.status != types.JobStatus.STARTED for job in
jobs)

You can instead do something like this:

 jobs = engine.jobs_service().list(
            search='correlation_id=%s' % correlation_id
        )


This won't work either, it returns an exception claiming this:

TypeError: list() got an unexpected keyword argument 'search'

Any further hints with this?

Thanks


return any(job.status == types.JobStatus.FAILED for job in jobs)

[1]
- 
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-master/test-scenarios/004_basic_sanity.py#L353
[6]
[2]
- 
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-master/test_utils/__init__.py#L209
[7]

On Thu, Jul 12, 2018 at 10:28 AM  wrote:


Hi Ondra,

El 2018-07-12 08:02, Ondra Machacek escribió:

On 07/11/2018 10:10 AM, nico...@devels.es wrote:

Hi,

We're using ovirt-engine-sdk-python 4.1.6 on oVirt 4.1.9,

currently

we're trying to delete some snapshots via a script like this:

      sys_serv = conn.system_service()
      vms_service = sys_serv.vms_service()
      vm_service = vms_service.vm_service(vmid)
      snaps_service = vm_service.snapshots_service()
      snaps_service.service('SNAPSHOT-ID').remove()


In case of failure this line should raise Error, so you should

know it

failed.



It doesn't, actually. This call is asynchronous, and the snapshot
deletion seems to fail after about 10 seconds, so initially it
seems to
be correct but fails afterwards, that's why I need a way to check
if the
task ended correctly or not.



This works, mostly... however, sometimes the deletion fails:

      Failed to delete snapshot 'snapshot name' for VM 'vm'.

Is it currently possible to know via Python-SDK that the

deletion

actually failed? I know I can check the state of a snapshot, but

I'd

like to check the result of the task. Is that possible somehow?

Thanks.
___
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/

[1]

oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:




https://lists.ovirt.org/archives/list/users@ovirt.org/message/AFGSUUJ3RNWX6H66RRGDPFLM6YEL577F/

[3]
___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFPROJO4XHL36SJIQIYAAXUTPI6N4IIS/

[4]



Links:
--
[1] https://www.ovirt.org/site/privacy-policy/
[2] https://www.ovirt.org/community/about/community-guidelines/
[3]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AFGSUUJ3RNWX6H66RRGDPFLM6YEL577F/
[4]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFPROJO4XHL36SJIQIYAAXUTPI6N4IIS/
[5] http://disk.id
[6]
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-master/test-scenarios/004_basic_sanity.py#L353
[7]

[ovirt-users] Re: Unable to start VM - Image is not a legal chain

[nicolas]

Hi Alex,

We had a bigger problem recently which involved the error you mention. I 
sent it to the mail list and you can find the final solution we chose at 
[1]. Not the cleanest solution of course, but we managed to recover all 
VMs... I think in your case the relevant part is the one that mention 
the "vdsClient setVolumeLegality" command, although I don't know the 
root reason why you're getting the error (might be a corrupt snapshot, 
as in our case)...


Hope this helps.

  [1]: https://www.mail-archive.com/users@ovirt.org/msg49300.html

El 2018-07-11 09:16, Alex K escribió:

Due to urgency of the case, I fetched the backup copy from weekend and
proceeded to push missing data to VM (the VM is a git repo). I lost
few notes, though not much damage was done...
I'm starting to feel uncomfortable with this solution though and might
switch (at least the production VMs) to plain KVM where I had never
experienced such issues.

Alex

On Wed, Jul 11, 2018 at 7:27 AM, Yedidyah Bar David 
wrote:


(Changing subject, adding Freddy)

On Tue, Jul 10, 2018 at 8:06 PM, Alex K 
wrote:


Hi all,

I did a routine maintenance today (updating the hosts) to ovirt
cluster (4.2) and I have one VM that was complaining about an
invalid snapshot. After shutdown of VM the VM is not able to start
again, giving the error:

VM Gitlab is down with error. Exit message: Bad volume
specification {'serial': 'b6af2856-a164-484a-afe5-9836bbdd14e8',
'index': 0, 'iface': 'virtio', 'apparentsize': '51838976',
'specParams': {}, 'cache': 'none', 'imageID':
'b6af2856-a164-484a-afe5-9836bbdd14e8', 'truesize': '52011008',
'type': 'disk', 'domainID':
'142bbde6-ef9d-4a52-b9da-2de533c1f1bd', 'reqsize': '0', 'format':
'cow', 'poolID': '0001-0001-0001-0001-0311', 'device':
'disk', 'path':




'/rhev/data-center/0001-0001-0001-0001-0311/142bbde6-ef9d-4a52-b9da-2de533c1f1bd/images/b6af2856-a164-484a-afe5-9836bbdd14e8/f3125f62-c909-472f-919c-844e0b8c156d',

'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1',
'volumeID': 'f3125f62-c909-472f-919c-844e0b8c156d', 'diskType':
'file', 'alias': 'ua-b6af2856-a164-484a-afe5-9836bbdd14e8',
'discard': False}.

I see also the following error:

VDSM command CopyImageVDS failed: Image is not a legal chain:
(u'b6af2856-a164-484a-afe5-9836bbdd14e8',)


This error appears a few more times in the list's archive, all of
which seem to be related to rather-old bugs (3.5/3.6 times) or
storage problems. I assume you use 4.2. Are you sure the corruption
happened only now? Did working with snapshots worked well before the
upgrade?

 


Seems as a corrupt VM disk?


Seems so to me, but I am not a storage expert.

 


The VM had 3 snapshots. I was able to delete one from GUI then am
not able to delete the other two as the task fails. Generally I am
not allowed to clone, export or do sth to the VM.
 



Have you encountered sth similar. Any advice?


The lastest post, from 2016, included a workaround, you might (very
carefully!) try that.

I suggest to also open a bug and attach all relevant logs (engine,
vdsm from all relevant hosts, including SPMs at time of snapshot
operations and any other host that ran the VM), and try to give
accurate reproduction steps.

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/VYR4KMOZVEQOJ5CBTFJMRYY7XAF5YAPP/

___
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/Q4TUEIMBIHO6BX5JQQQSVC2RFD6IRAQG/

[ovirt-users] Python-SDK4: Check snapshot deletion result?

[nicolas]

Hi,

We're using ovirt-engine-sdk-python 4.1.6 on oVirt 4.1.9, currently 
we're trying to delete some snapshots via a script like this:


sys_serv = conn.system_service()
vms_service = sys_serv.vms_service()
vm_service = vms_service.vm_service(vmid)
snaps_service = vm_service.snapshots_service()
snaps_service.service('SNAPSHOT-ID').remove()

This works, mostly... however, sometimes the deletion fails:

Failed to delete snapshot 'snapshot name' for VM 'vm'.

Is it currently possible to know via Python-SDK that the deletion 
actually failed? I know I can check the state of a snapshot, but I'd 
like to check the result of the task. Is that possible somehow?


Thanks.
___
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/AFGSUUJ3RNWX6H66RRGDPFLM6YEL577F/

[ovirt-users] Re: Python-SDK4: Check snapshot deletion result?

[nicolas]

Hi Ondra,

El 2018-07-12 08:02, Ondra Machacek escribió:

On 07/11/2018 10:10 AM, nico...@devels.es wrote:

Hi,

We're using ovirt-engine-sdk-python 4.1.6 on oVirt 4.1.9, currently 
we're trying to delete some snapshots via a script like this:


     sys_serv = conn.system_service()
     vms_service = sys_serv.vms_service()
     vm_service = vms_service.vm_service(vmid)
     snaps_service = vm_service.snapshots_service()
     snaps_service.service('SNAPSHOT-ID').remove()


In case of failure this line should raise Error, so you should know it
failed.



It doesn't, actually. This call is asynchronous, and the snapshot 
deletion seems to fail after about 10 seconds, so initially it seems to 
be correct but fails afterwards, that's why I need a way to check if the 
task ended correctly or not.




This works, mostly... however, sometimes the deletion fails:

     Failed to delete snapshot 'snapshot name' for VM 'vm'.

Is it currently possible to know via Python-SDK that the deletion 
actually failed? I know I can check the state of a snapshot, but I'd 
like to check the result of the task. Is that possible somehow?


Thanks.
___
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/AFGSUUJ3RNWX6H66RRGDPFLM6YEL577F/

___
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/XFPROJO4XHL36SJIQIYAAXUTPI6N4IIS/

[ovirt-users] Python-SDK4: Knowing snapshot status?

[nicolas]

Hi,

I'm running ovirt-engine-sdk-python 4.2.4 and I'm performing some 
snapshot-related tasks. I'd like to somehow control the status of the 
snapshot in order to know when I'll be able to run the next 
snapshot-related operation.


For example, I'd like to create a new snapshot and then delete X oldest 
snapshots. After creating the snapshot I have to make sure the snapshot 
operation has concluded to run the deletion.


However, I'm unable to find a native way to get the status of a 
snapshot.


In [1]: snap = conn.follow_link(vm.snapshots)[3]   # This returns 
one snapshot


In [2]: snap.status

In [3]: snap.status_detail

So both status-related properties return None. I've managed to find a 
"poorman's" way by doing this:


while True:
try:
snaps_service.service(snap.id).remove()
except Error, e:
if e.code == 409:
sleep(30)
continue
else:
break

Which works but is quite "tricky".

Is there a better way to do this?

Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Unable to get volume size for domain

[nicolas]

El 2018-04-19 08:53, Francesco Romani escribió:

On 04/19/2018 09:44 AM, nico...@devels.es wrote:

Hi,

We're running oVirt 4.1.9 and recently we've experienced a corruption
of a lot of VMs... I tried to investigate the reasons but I simply
can't find an explaination of why this happens.

I'd really appreciate if someone could take a look at these logs and
shed some light on what happened and if this can be fixed somehow,
because these are really a lot of VMs affected... I'm attaching both
engine and SPM's vdsm logs.

These storage domains are all iSCSI-based.


This is pretty frequent on your vdsm logs and alarming:

VolumeGroupSizeError: Volume Group not big enough: ('Not enough free
extents for extending LV
f3bb30a0-4745-4c77-aaca-e5f385905c1e/5c1ad23a-e418-4bb2-86b7-af4b14079224
(free=6, needed=8)',)

The fix depends on how you set up your ISCSI storage


This might be due to a Storage Domain that became 100% full since 
yesterday at cca. 16:00.


Could you be more specific on what should I check to know how to fix it?

Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] GPG Key of evilissimo repo for ovirt-guest-agent is expired

[nicolas]

Also noticed this.

As per the CHANGELOG of the package, the maintainer is a member of 
RedHat at least until Aug 2014. Not sure if he's subscribed to this 
list, though. Maybe sending him an e-mail directly? You can find it in 
the /usr/share/doc/ovirt-guest-agent/changelog.Debian.gz file.


Regards.

El 2018-03-20 16:42, Florian Schmid escribió:

Hi,

it looks like for this repo, the GPG key is expired.
http://download.opensuse.org/repositories/home:/evilissimo:/ubuntu:/16.04/xUbuntu_16.04/

Does someone know, whom I should contact, that this key will be 
renewed?


Or does someone know another repo, where I can download the latest
ovirt-guest-agent for Ubuntu 16.04

BR Florian
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Bad volume specification

[nicolas]

Hi,

We're running oVirt 4.1.9, today I put a host on maintenance, I saw one 
of the VMs was taking too long to migrate so I shut it down. It seems 
that just in that moment the machine ended migrating, but the shutdown 
did happen as well.


Now, when I try to start the VM I'm getting the following error:

2018-03-21 12:31:02,309Z ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(DefaultQuartzScheduler3) [7985a4e2] EVENT_ID: VM_DOWN_ERROR(119), 
Correlation ID: null, Call Stack: null, Custom ID: null, Custom Event 
ID: -1, Message: VM openmaint.iaas.domain.com is down with error. Exit 
message: Bad volume specification {'index': '0', u'domainID': 
u'04cb5bd0-d94e-4d14-a71a-e63a669e11b9', 'reqsize': '0', u'format': 
u'cow', u'optional': u'false', u'address': {u'function': u'0x0', u'bus': 
u'0x00', u'domain': u'0x', u'type': u'pci', u'slot': u'0x06'}, 
u'volumeID': u'68ee7a04-ceff-49f0-bf91-256870543921', 'apparentsize': 
'3221225472', u'imageID': u'9d087e6b-0832-46db-acb0-16d5131afa0c', 
u'discard': False, u'specParams': {}, u'readonly': u'false', u'iface': 
u'virtio', u'deviceId': u'9d087e6b-0832-46db-acb0-16d5131afa0c', 
'truesize': '3221225472', u'poolID': 
u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device': u'disk', u'shared': 
u'false', u'propagateErrors': u'off', u'type': u'disk'}.


It looks quite bad... I'm attaching the engine.log since the moment I 
start the VM.


Is there anything I can do to recover the VM? oVirt says the disk is OK 
in the 'Disks' tab.


Thanks.2018-03-21 12:30:39,539Z INFO  [org.ovirt.engine.core.bll.RunVmCommand] 
(default task-151) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] Lock Acquired to 
object 'EngineLock:{exclusiveLocks='[f503b710-7165-415b-a567-16251da7212d=VM]', 
sharedLocks=''}'
2018-03-21 12:30:39,645Z INFO  
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (default 
task-151) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] START, 
IsVmDuringInitiatingVDSCommand( 
IsVmDuringInitiatingVDSCommandParameters:{runAsync='true', 
vmId='f503b710-7165-415b-a567-16251da7212d'}), log id: 15ef3c8a
2018-03-21 12:30:39,645Z INFO  
[org.ovirt.engine.core.vdsbroker.IsVmDuringInitiatingVDSCommand] (default 
task-151) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] FINISH, 
IsVmDuringInitiatingVDSCommand, return: false, log id: 15ef3c8a
2018-03-21 12:30:39,792Z INFO  
[org.ovirt.engine.core.bll.scheduling.SchedulingManager] (default task-151) 
[429d4c9e-f77d-4fad-951c-08a6b7751bd6] Candidate host 'kvmr05.domain.com' 
('f7ab19fe-5192-4a22-88cf-c8d019fa0372') was filtered out by 
'VAR__FILTERTYPE__INTERNAL' filter 'Memory' (correlation id: null)
2018-03-21 12:30:39,863Z INFO  [org.ovirt.engine.core.bll.RunVmCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
Running command: RunVmCommand internal: false. Entities affected :  ID: 
f503b710-7165-415b-a567-16251da7212d Type: VMAction group RUN_VM with role type 
USER
2018-03-21 12:30:39,870Z INFO  [org.ovirt.engine.core.bll.RunVmCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
Emulated machine 'pc-i440fx-rhel7.3.0' selected since Custom Compatibility 
Version is set for 'VM [openmaint.iaas.domain.com]'
2018-03-21 12:30:39,979Z INFO  
[org.ovirt.engine.core.bll.scheduling.SchedulingManager] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
Candidate host 'kvmr05.domain.com' ('f7ab19fe-5192-4a22-88cf-c8d019fa0372') was 
filtered out by 'VAR__FILTERTYPE__INTERNAL' filter 'Memory' (correlation id: 
429d4c9e-f77d-4fad-951c-08a6b7751bd6)
2018-03-21 12:30:40,032Z INFO  
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
START, UpdateVmDynamicDataVDSCommand( 
UpdateVmDynamicDataVDSCommandParameters:{runAsync='true', hostId='null', 
vmId='f503b710-7165-415b-a567-16251da7212d', 
vmDynamic='org.ovirt.engine.core.common.businessentities.VmDynamic@db93365b'}), 
log id: 141aa350
2018-03-21 12:30:40,037Z INFO  
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
FINISH, UpdateVmDynamicDataVDSCommand, log id: 141aa350
2018-03-21 12:30:40,040Z INFO  
[org.ovirt.engine.core.vdsbroker.CreateVmVDSCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
START, CreateVmVDSCommand( CreateVmVDSCommandParameters:{runAsync='true', 
hostId='b2dfb945-d767-44aa-a547-2d1a4381f8e3', 
vmId='f503b710-7165-415b-a567-16251da7212d', vm='VM 
[openmaint.iaas.domain.com]'}), log id: 3435053c
2018-03-21 12:30:40,046Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateVDSCommand] 
(org.ovirt.thread.pool-6-thread-46) [429d4c9e-f77d-4fad-951c-08a6b7751bd6] 
START, CreateVDSCommand(HostName = kvmr04.domain.com, 
CreateVmVDSCommandParameters:{runAsync='true', 
hostId='b2dfb945-d767-44aa-a547-2d1a4381f8e3', 

Re: [ovirt-users] Bad volume specification

[nicolas]

Guys, any hints to this?

El 2018-03-21 12:37, nico...@devels.es escribió:

Hi,

We're running oVirt 4.1.9, today I put a host on maintenance, I saw
one of the VMs was taking too long to migrate so I shut it down. It
seems that just in that moment the machine ended migrating, but the
shutdown did happen as well.

Now, when I try to start the VM I'm getting the following error:

2018-03-21 12:31:02,309Z ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(DefaultQuartzScheduler3) [7985a4e2] EVENT_ID: VM_DOWN_ERROR(119),
Correlation ID: null, Call Stack: null, Custom ID: null, Custom Event
ID: -1, Message: VM openmaint.iaas.domain.com is down with error. Exit
message: Bad volume specification {'index': '0', u'domainID':
u'04cb5bd0-d94e-4d14-a71a-e63a669e11b9', 'reqsize': '0', u'format':
u'cow', u'optional': u'false', u'address': {u'function': u'0x0',
u'bus': u'0x00', u'domain': u'0x', u'type': u'pci', u'slot':
u'0x06'}, u'volumeID': u'68ee7a04-ceff-49f0-bf91-256870543921',
'apparentsize': '3221225472', u'imageID':
u'9d087e6b-0832-46db-acb0-16d5131afa0c', u'discard': False,
u'specParams': {}, u'readonly': u'false', u'iface': u'virtio',
u'deviceId': u'9d087e6b-0832-46db-acb0-16d5131afa0c', 'truesize':
'3221225472', u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63',
u'device': u'disk', u'shared': u'false', u'propagateErrors': u'off',
u'type': u'disk'}.

It looks quite bad... I'm attaching the engine.log since the moment I
start the VM.

Is there anything I can do to recover the VM? oVirt says the disk is
OK in the 'Disks' tab.

Thanks.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bad volume specification

[nicolas]

El 2018-03-23 15:38, Yaniv Kaul escribió:

On Fri, Mar 23, 2018 at 3:20 PM,  wrote:


El 2018-03-23 12:16, Sandro Bonazzola escribió:
2018-03-21 13:37 GMT+01:00 :

Hi,

We're running oVirt 4.1.9, today I put a host on maintenance, I saw
one of the VMs was taking too long to migrate so I shut it down. It
seems that just in that moment the machine ended migrating, but the
shutdown did happen as well.

I would suggest to update to 4.2 as soon as possible since 4.1 is
not
supported anymore now that 4.2 is available


 We have 2 oVirt infrastructures. One is migrated to 4.2, we can't
migrate the other one since most of the user portal features in 4.1
are not present in 4.2 and our users do a massive usage of this portal
to create/tune VMs. I know several issues were created on Github to
implement missing features, but we cannot upgrade until they are
implemented.

Have you checked the latest oVirt 4.2.2 RC? We have brought back
several features to the user portal.
Y.
 


Yes, I'm aware. I'm about to find some time to test it, still I think 
there will be some features missing (I think I've read that it won't be 
possible to deploy a VM without a template), but I need to test it for a 
while. Still I guess we can upgrade and let some teachers test if they 
can get used to the new user portal.


Thank you!




Thanks.

 

Now, when I try to start the VM I'm getting the following error:

2018-03-21 12:31:02,309Z ERROR



[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

(DefaultQuartzScheduler3) [7985a4e2] EVENT_ID: VM_DOWN_ERROR(119),
Correlation ID: null, Call Stack: null, Custom ID: null, Custom
Event ID: -1, Message: VM openmaint.iaas.domain.com [1] [1] is down
with
error. Exit message: Bad volume specification {'index': '0',
u'domainID': u'04cb5bd0-d94e-4d14-a71a-e63a669e11b9', 'reqsize':
'0', u'format': u'cow', u'optional': u'false', u'address':
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'68ee7a04-ceff-49f0-bf91-256870543921', 'apparentsize':
'3221225472', u'imageID': u'9d087e6b-0832-46db-acb0-16d5131afa0c',
u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'deviceId':
u'9d087e6b-0832-46db-acb0-16d5131afa0c', 'truesize': '3221225472',
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type':
u'disk'}.

It looks quite bad... I'm attaching the engine.log since the moment
I start the VM.

Is there anything I can do to recover the VM? oVirt says the disk
is OK in the 'Disks' tab.

Adding some people who may be able to help. Once solved, please
consider upgrade.

 

Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [2] [2]

--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION
R

Red Hat EMEA [3]

sbona...@redhat.com   

                 [4]

 [5]

Links:
--
[1] http://openmaint.iaas.domain.com [1]
[2] http://lists.ovirt.org/mailman/listinfo/users [2]
[3] https://www.redhat.com/ [3]
[4] https://red.ht/sig [4]
[5] https://redhat.com/summit [5]


 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users [2]



Links:
--
[1] http://openmaint.iaas.domain.com
[2] http://lists.ovirt.org/mailman/listinfo/users
[3] https://www.redhat.com/
[4] https://red.ht/sig
[5] https://redhat.com/summit

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bad volume specification

[nicolas]

El 2018-03-23 12:16, Sandro Bonazzola escribió:

2018-03-21 13:37 GMT+01:00 :


Hi,

We're running oVirt 4.1.9, today I put a host on maintenance, I saw
one of the VMs was taking too long to migrate so I shut it down. It
seems that just in that moment the machine ended migrating, but the
shutdown did happen as well.


I would suggest to update to 4.2 as soon as possible since 4.1 is not
supported anymore now that 4.2 is available



We have 2 oVirt infrastructures. One is migrated to 4.2, we can't 
migrate the other one since most of the user portal features in 4.1 are 
not present in 4.2 and our users do a massive usage of this portal to 
create/tune VMs. I know several issues were created on Github to 
implement missing features, but we cannot upgrade until they are 
implemented.


Thanks.


 


Now, when I try to start the VM I'm getting the following error:

2018-03-21 12:31:02,309Z ERROR


[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

(DefaultQuartzScheduler3) [7985a4e2] EVENT_ID: VM_DOWN_ERROR(119),
Correlation ID: null, Call Stack: null, Custom ID: null, Custom
Event ID: -1, Message: VM openmaint.iaas.domain.com [1] is down with
error. Exit message: Bad volume specification {'index': '0',
u'domainID': u'04cb5bd0-d94e-4d14-a71a-e63a669e11b9', 'reqsize':
'0', u'format': u'cow', u'optional': u'false', u'address':
{u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x',
u'type': u'pci', u'slot': u'0x06'}, u'volumeID':
u'68ee7a04-ceff-49f0-bf91-256870543921', 'apparentsize':
'3221225472', u'imageID': u'9d087e6b-0832-46db-acb0-16d5131afa0c',
u'discard': False, u'specParams': {}, u'readonly': u'false',
u'iface': u'virtio', u'deviceId':
u'9d087e6b-0832-46db-acb0-16d5131afa0c', 'truesize': '3221225472',
u'poolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'device':
u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type':
u'disk'}.

It looks quite bad... I'm attaching the engine.log since the moment
I start the VM.

Is there anything I can do to recover the VM? oVirt says the disk
is OK in the 'Disks' tab.


Adding some people who may be able to help. Once solved, please
consider upgrade.

 


Thanks.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users [2]


--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA [3]

sbona...@redhat.com   

 [4]

 [5]



Links:
--
[1] http://openmaint.iaas.domain.com
[2] http://lists.ovirt.org/mailman/listinfo/users
[3] https://www.redhat.com/
[4] https://red.ht/sig
[5] https://redhat.com/summit

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] VMs stuck in migrating state

[nicolas]

El 2018-03-02 15:34, Milan Zamazal escribió:

nico...@devels.es writes:


El 2018-03-02 14:10, Milan Zamazal escribió:

nico...@devels.es writes:

We're running 4.1.9 and during the weekend we had a storage issue 
that

seemed
to leave some hosts in an strange state. One of the hosts has almost 
all VMs
migrating (although it seems to not actually being migrating them) 
and the

migration state cannot be cancelled.

When clicking on one of those machines and selecting 'Cancel 
migration', in

the
ovirt-engine log I see:

2018-02-26 08:52:07,588Z INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.CancelMigrateVDSCommand]
(org.ovirt.thread.pool-6-thread-36) 
[887dfbf9-dece-4f7b-90a8-dac02b849b7f]

HostName = host2.domain.com
2018-02-26 08:52:07,588Z ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.CancelMigrateVDSCommand]
(org.ovirt.thread.pool-6-thread-36) 
[887dfbf9-dece-4f7b-90a8-dac02b849b7f]

Command 'CancelMigrateVDSCommand(HostName = host2.domain.com,
CancelMigrationVDSParameters:{runAsync='true',
hostId='e63b9146-10c4-47ad-bd6c-f053a8c5b4eb',
vmId='26d37e43-32e2-4e55-9c1e-1438518d5021'})' execution failed:
VDSGenericException: VDSErrorException: Failed to CancelMigrateVDS, 
error =

Migration process cancelled, code = 82

On the vdsm side I see:

2018-02-26 08:56:19,396+ INFO  (jsonrpc/0) [vdsm.api] START
migrateCancel()
from=:::10.X.X.X,54654, 
flow_id=874d36d7-63f5-4b71-8a4d-6d9f3ec65858

(api:46)
2018-02-26 08:56:19,398+ INFO  (jsonrpc/0) [vdsm.api] FINISH
migrateCancel
return={'status': {'message': 'Migration process cancelled', 'code': 
82},

'progress': 0} from=:::10.X.X.X,54654,
flow_id=874d36d7-63f5-4b71-8a4d-6d9f3ec65858 (api:52)

So no error on the vdsm side log.


Interesting.  The messages above indicate that the VM was attempted 
to
migrate, but the migration got temporarily rejected on the 
destination
due to the number of already running incoming migrations (the limit 
is 2

incoming migrations by default).  Later, Vdsm was asked to cancel the
outgoing migration and it successfully set a migration canceling 
flag.

However the action was reported as an error to Engine, due to hitting
the incoming migration limit on the destination.  Maybe it's a bug, 
I'm
not sure, resulting in minor confusion.  Normally it shouldn't 
matter,
the migration should be canceled shortly after anyway and Engine 
should

be informed about that.

However the migration apparently wasn't canceled here.  I can't say 
what
happened without complete Vdsm log.  One of possible reasons is that 
the
migration has been waiting on completion of another migration 
outgoing
from the source (only one outgoing migration at the time is allowed 
by

default).  In any case it seems the migration either wasn't actually
started at all or it just started being set up and that has never 
been

completely finished.



I'm attaching the log. Basically the storage backend was restarted by 
fencing
and then this issue happened. This was on 26/02 at about 08:52 (log 
time).


Thank you for the log, but VMs are already “migrating” at its 
beginning,

there had to be some problem already earlier.


I already tried restarting ovirt-engine but it didn't work.


Here the problem is clearly on the Vdsm side.

Could someone shed some light on how to cancel the migration status 
for

these
machines? All of them seem to be running on the same host.


Did the VMs get unblocked in the meantime?  I can't know what's the


No, they didn't. They're still in a "Migrating" state.

actual state of the given VMs without seeing the complete Vdsm log, 
so
it's difficult to give a good advice.  I think that Vdsm restart on 
the
given host would help BUT it's generally not a very good idea to 
restart

Vdsm if any real migration, outgoing or incoming, is running on the
host.  VMs that aren't actually being migrated (despite being 
reported
as migrating) at all should simply return to Up state after the 
restart,

but VMs with any real migration action pending might get return to Up
state without proper cleanup, resulting in a different kind of mess 
or
maybe something even worse (things should improve in oVirt 4.2, but 
it's

still good to avoid Vdsm restarts with migrations running).



I assume this is not a real migration as it has been in this state for 
several

days. Would you advice restarting vdsm in this case then?


I'd say try it.  Since nothing has changed for several days, restarting
Vdsm looks like appropriate action at this point.  Just don't make a
habit of it :-).



Thanks, that made it.

Regards.


Regards,
Milan

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] vdsClient in oVirt 4.3

[nicolas]

Hi,

In oVirt 4.1 we used this command to set a volume as LEGAL:

vdsClient -s  setVolumeLegality sdUUID spUUID imgUUID leafUUID 
LEGAL


What would be the equivalent to this command using vdsm-client in oVirt 
4.3?


Thanks.
___
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/T7QYVJMDWNRUOKLOZGEA7QPDBKLX4TO2/

[ovirt-users] Re: vdsClient in oVirt 4.3

[nicolas]

Thanks Liran, it worked perfectly.

Regards.

El 2019-04-03 11:33, Liran Rotenberg escribió:

I think the similar way to do it as you used to is:
$ vdsm-client Volume setLegality storagedomainID=sdUUID
storagepoolID=spUUID imageID=imgUUID legality=LEGAL volumeID=volUUID
Where the values you set should be inside quotes for example 'LEGAL'.

On Wed, Apr 3, 2019 at 1:08 PM  wrote:


Hi Benny,

Thanks for the help.

Could you please tell me what job_uuid and vol_gen should be replaced
by? Should I just put any UUID for the job?

Thanks.

El 2019-04-03 09:52, Benny Zlotnik escribió:
> it should be something like this:
>   $ cat update.json
>   {
>   "job_id":"",
>   "vol_info": {
>   "sd_id": "",
>   "img_id": "",
>   "vol_id": "",
>   "generation": ""
>   },
>   "legality": "LEGAL"
>   }
>   }
>
>   $ vdsm-client SDM update_volume -f update.json
>
> On Wed, Apr 3, 2019 at 11:48 AM  wrote:
>>
>> Hi,
>>
>> In oVirt 4.1 we used this command to set a volume as LEGAL:
>>
>>  vdsClient -s  setVolumeLegality sdUUID spUUID imgUUID
>> leafUUID
>> LEGAL
>>
>> What would be the equivalent to this command using vdsm-client in
>> oVirt
>> 4.3?
>>
>> Thanks.
>> ___
>> 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/T7QYVJMDWNRUOKLOZGEA7QPDBKLX4TO2/
___
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/LUZX6W6KWRZWHDRDJPH6PIEGRVNAGVED/

___
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/RHODSQZLPK6JEGUH2NKTSGRVTBJXDXJC/

[ovirt-users] Re: vdsClient in oVirt 4.3

[nicolas]

Hi Benny,

Thanks for the help.

Could you please tell me what job_uuid and vol_gen should be replaced 
by? Should I just put any UUID for the job?


Thanks.

El 2019-04-03 09:52, Benny Zlotnik escribió:

it should be something like this:
  $ cat update.json
  {
  "job_id":"",
  "vol_info": {
  "sd_id": "",
  "img_id": "",
  "vol_id": "",
  "generation": ""
  },
  "legality": "LEGAL"
  }
  }

  $ vdsm-client SDM update_volume -f update.json

On Wed, Apr 3, 2019 at 11:48 AM  wrote:


Hi,

In oVirt 4.1 we used this command to set a volume as LEGAL:

 vdsClient -s  setVolumeLegality sdUUID spUUID imgUUID 
leafUUID

LEGAL

What would be the equivalent to this command using vdsm-client in 
oVirt

4.3?

Thanks.
___
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/T7QYVJMDWNRUOKLOZGEA7QPDBKLX4TO2/

___
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/LUZX6W6KWRZWHDRDJPH6PIEGRVNAGVED/

[ovirt-users] NPE for GetValidHostsForVmsQuery

[nicolas]

Hi,

We're running oVirt 4.3.2. When we click on the "Migrate" button over a 
VM, an error popup shows up and in the ovirt-engine log we see:


  2019-04-03 12:37:40,897+01 ERROR 
[org.ovirt.engine.core.bll.GetValidHostsForVmsQuery] (default task-6) 
[478381f0-18e3-4c96-bcb5-aafd116d7b7a] Query 'GetValidHostsForVmsQuery' 
failed: null


I'm attaching the full NPE.

Could someone point out what could be the reason for the NPE?

Thanks.2019-04-03 12:37:40,897+01 ERROR 
[org.ovirt.engine.core.bll.GetValidHostsForVmsQuery] (default task-6) 
[478381f0-18e3-4c96-bcb5-aafd116d7b7a] Query 'GetValidHostsForVmsQuery' failed: 
null
2019-04-03 12:37:40,898+01 ERROR 
[org.ovirt.engine.core.bll.GetValidHostsForVmsQuery] (default task-6) 
[478381f0-18e3-4c96-bcb5-aafd116d7b7a] Exception: java.lang.NullPointerException
at 
org.ovirt.engine.core.bll.scheduling.SchedulingManager.subtractRunningVmResources(SchedulingManager.java:923)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.scheduling.SchedulingManager.canSchedule(SchedulingManager.java:616)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.GetValidHostsForVmsQuery.lambda$getValidHosts$0(GetValidHostsForVmsQuery.java:56)
 [bll.jar:]
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 
[rt.jar:1.8.0_201]
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) 
[rt.jar:1.8.0_201]
at 
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
[rt.jar:1.8.0_201]
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) 
[rt.jar:1.8.0_201]
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) 
[rt.jar:1.8.0_201]
at 
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
[rt.jar:1.8.0_201]
at 
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 
[rt.jar:1.8.0_201]
at 
org.ovirt.engine.core.bll.GetValidHostsForVmsQuery.getValidHosts(GetValidHostsForVmsQuery.java:59)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.GetValidHostsForVmsQuery.executeQueryCommand(GetValidHostsForVmsQuery.java:36)
 [bll.jar:]
at 
org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:106)
 [bll.jar:]
at 
org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) 
[dal.jar:]
at 
org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecutor.execute(DefaultBackendQueryExecutor.java:14)
 [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:520) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:489) 
[bll.jar:]
at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source) 
[:1.8.0_201]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [rt.jar:1.8.0_201]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201]
at 
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at 
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at 
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at 
org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92)
 [wildfly-weld-ejb-15.0.1.Final.jar:15.0.1.Final]
at 
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.interceptorChainCompleted(WeldInvocationContextImpl.java:107)
 [weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:126)
 [weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 
org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12)
 [common.jar:]
at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) 
[:1.8.0_201]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [rt.jar:1.8.0_201]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201]
at 
org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
 [weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92)
 [weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124)
 [weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 
org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105) 
[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
at 

[ovirt-users] Re: NPE for GetValidHostsForVmsQuery

[nicolas]

Hi Andrej,

I missed to point a fact that is probably determining. Prior to noticing 
the error, we upgraded the Cluster & Data Center compatibility version 
from 4.1 to 4.3, which caused ovirt-engine to automatically edit all VMs 
and modify their compatibility versions as well (with changes pending 
until next reboot).


So if we powered down the VM, edited the VM, saved it (even without 
changes) and powered it up, migrations would work again.


This happened with all affected machines.

If you need some additional info, just ask.

Thanks.

El 2019-04-04 17:03, Andrej Krejcir escribió:

Hi,

The NPE is because the CPU load of a VM is missing. It happens when
the VM statistics are not updated.

This is definitely a bug, missing CPU load should not prevent
migration.
I will open a Bugzilla ticket. 

Can you share some more details about the VMs?
Does the NPE happen for all VMs or only some specific types?

Thanks,
Andrej

On Wed, 3 Apr 2019 at 13:45,  wrote:


Hi,

We're running oVirt 4.3.2. When we click on the "Migrate" button
over a
VM, an error popup shows up and in the ovirt-engine log we see:

   2019-04-03 12:37:40,897+01 ERROR
[org.ovirt.engine.core.bll.GetValidHostsForVmsQuery] (default
task-6)
[478381f0-18e3-4c96-bcb5-aafd116d7b7a] Query
'GetValidHostsForVmsQuery'
failed: null

I'm attaching the full NPE.

Could someone point out what could be the reason for the NPE?

Thanks.___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/VZWPQR34DDQMTDPUI2EZFA3VSHA77BET/

[3]



Links:
--
[1] https://www.ovirt.org/site/privacy-policy/
[2] https://www.ovirt.org/community/about/community-guidelines/
[3]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VZWPQR34DDQMTDPUI2EZFA3VSHA77BET/

___
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/R3QVBGUKKRYQ5OUWEXZ2DHD3SGLQN5UM/

[ovirt-users] Re: Clearing asynchronous task Unknown

[nicolas]

Hi Nicholas,

Thanks for this. Indeed, that was the problem. I opened the vdsm log and 
saw a lot of exceptions like this:


2019-01-28 10:56:54,792+ INFO  (jsonrpc/2) [vdsm.api] FINISH 
clearTask error=Operation is not allowed in this task state: ("can't 
clean in state running",) from=:::10.6.4.10,49326, flow_id=12aea163, 
task_id=b66d9abc-cfb2-4a62-bd54-5f46d32ca1c3 (api:50)
2019-01-28 10:56:54,792+ ERROR (jsonrpc/2) 
[storage.TaskManager.Task] (Task='b66d9abc-cfb2-4a62-bd54-5f46d32ca1c3') 
Unexpected error (task:872)

Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 879, in _run
return fn(*args, **kargs)
  File "", line 2, in clearTask
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, 
in method

ret = func(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 2260, in clearTask
return self.taskMng.clearTask(taskID=taskID)
  File "/usr/share/vdsm/storage/taskManager.py", line 175, in clearTask
t.clean()
  File "/usr/share/vdsm/storage/task.py", line 1049, in clean
raise se.TaskStateError("can't clean in state %s" % self.state)
TaskStateError: Operation is not allowed in this task state: ("can't 
clean in state running",)


I migrated all VMs to a different host, forcibly rebooted the SPM host 
and now the event stopped showing.


Thanks.

Regards.

El 2019-01-25 16:19, Nicholas Vaughan escribió:

Hi Nicolas,

We had a similar issue and it was caused by a stuck task in VDSM on
the host that was the SPM.

We found that VDSM tasks don't always show up in the oVirt GUI.  You
can check using 'vdsm-client Host getAllTasksStatuses' on the SPM
host.

We could not manually cancel any of the stuck VDSM tasks or move the
SPM to another host.  The only solution we found was to migrate all
the VM's off that host and restart it.  Once the remaining hosts had
contended to be the new SPM, we gave the engine a restart too.

Hope that helps,
Nick

On Fri, 25 Jan 2019 at 12:02,  wrote:


Hi,

We're running oVirt 4.1.9 (I know there's a new version, we can't
upgrade until [1] is implemented). The thing is that since some
days
we're having an event that floods our event list:

   Clearing asynchronous task Unknown that started at Tue Jan 22
14:33:17
WET 2019

The event shows up every minute. We tried restarting the
ovirt-engine,
but after some time it starts flooding again. No pending tasks in
the
task list.

How can I check what is happening and how to solve it?

Thanks.

   [1]: https://github.com/oVirt/ovirt-web-ui/issues/490 [1]
___
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/ [2]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [3]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/YQ35IGLYZBYGY7F5IKUOXFMRUOXD6BK7/

[4]



Links:
--
[1] https://github.com/oVirt/ovirt-web-ui/issues/490
[2] https://www.ovirt.org/site/privacy-policy/
[3] https://www.ovirt.org/community/about/community-guidelines/
[4]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YQ35IGLYZBYGY7F5IKUOXFMRUOXD6BK7/

___
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/4QMBYHRKP6SCI3QDOI4XBAQXHDIIXVD7/

[ovirt-users] Clearing asynchronous task Unknown

[nicolas]

Hi,

We're running oVirt 4.1.9 (I know there's a new version, we can't 
upgrade until [1] is implemented). The thing is that since some days 
we're having an event that floods our event list:


  Clearing asynchronous task Unknown that started at Tue Jan 22 14:33:17 
WET 2019


The event shows up every minute. We tried restarting the ovirt-engine, 
but after some time it starts flooding again. No pending tasks in the 
task list.


How can I check what is happening and how to solve it?

Thanks.

  [1]: https://github.com/oVirt/ovirt-web-ui/issues/490
___
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/YQ35IGLYZBYGY7F5IKUOXFMRUOXD6BK7/

[ovirt-users] Re: Cannot allocate and run VM from VM-Pool. There are no available VMs in the VM-Pool

[nicolas]

Are the VMs from the pool 'up'? If so, no assignation can be done unless 
they are powered off.


El 2019-04-12 14:31, Florian Rädler escribió:

I am getting the following Error after a Pool was generated and
migrated to another host.

START_POOL fehlgeschlagen [Cannot allocate and run VM from VM-Pool.
There are no available VMs in the VM-Pool.]

No user is connected to any of the running VMs. What can I do to solve
this problem?

-

 Pflichtangaben anzeigen [1]

 Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie
hier: http://www.deutschebahn.com/de/konzern/datenschutz [2]

Links:
--
[1] http://www.deutschebahn.com/pflichtangaben/20190408
[2] http://www.deutschebahn.com/de/konzern/datenschutz

___
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/UL2KJKETQYFZR4HTVJI42IIAKHHJ2NWW/

___
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/WNB2EQKIFRDUF5RO4CZCIJ75OH75E7LU/

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 15:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 3:48 PM  wrote:


El 2019-05-24 14:42, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 3:39 PM  wrote:


El 2019-05-24 14:30, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:56 PM  wrote:


El 2019-05-24 13:39, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:32 PM  wrote:


El 2019-05-24 13:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 1:51 PM  wrote:


El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM 

wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to

configure

one of the

> hosts to support Nested Virtualization, but when

installing

the nested

> host it claims it doesn't support hardware

virtualization.

>
> On the physical host, we've enabled nested

virtualization:

>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the

nested

host. I

> try to deploy it but the engine will show it failed

because:

>
> 2019-05-10 09:11:32,006+01 ERROR
>



















[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

> (VdsDeploy) [6381e662] EVENT_ID:

VDS_INSTALL_IN_PROGRESS_ERROR(511),

> An error has occurred during installation of Host

host1:

Failed to

> execute stage 'Setup validation': Hardware does not

support

> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in

/var/log/ovirt-engine/host-deploy

(on the engine machine, it's copied there after deploy

finishes).




I had a look at it, but nothing relevant shows up besides

this

line:


2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
   File

"/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py",

line

132,

in _executeMethod
     method['method']()
   File




















"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",

line 71, in _validate_virtualization
     _('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization


It's been some time since I configured this myself, so I

do

not

remember
the details anymore. Did you check some guides/blog

posts/etc.

about

this?



I didn't. I just enabled nested virtualization in the

host

and

tried to

deploy.


What type of CPU did you configure in the VM (and

cluster)?




In the Cluster I have the Intel Broadwell Family, and as

the

VM

CPU I

have the default cluster CPU which is the one I just

referenced.

Not

sure if anything else should be done.


To see what checks the code does, you can read [1],

although

the

log

should be enough IMO.

[1]



/usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py


I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG

otopi.ovirt_host_deploy.hardware


hardware._isVirtualizationEnabled:208 virtualization

support

GenuineIntel (cpu: False, bios: True)

So the CPU is not able to support virtualization. Why

could

be

that?


Hi,
can you please share the output of cat /proc/cpuinfo ?
 


Hi Simone,

Please find attached the output (assuming you meant the VM

that

is

meant
to be added as a host). You'll probably see the model name

as

Haswell
because I forced it to test, but the same happens with

Broadwell.


OK,
vmx flag is not there so this VM doesn't support

virtualization

and

for that you have to enable nested virt support on the

underlying

level. What (SW) are you using on the underlying layer?

Let's try to recap:
L0 is your physical machine
L1 is the VM you are going to use as a virtualization host

for

oVirt

L2 are the VM you are going to create with oVirt

In order to be able to start a L2 VM from oVirt, you have to

enable

nested virtualization support on your L0 physical host.



Ok, the output I sent in the previous e-mail was for L1. For

L0

I'm


sending the cpuinfo log now.

I saw in the code, the flag that is returning false at

deployment

of L1
is this:

     cpu_ok = self._cpu_has_vmx_support()

Which calls the _cpu_has_vmx_support():

     def _cpu_has_vmx_support(self):
         eax, ebx, ecx, edx = self._cpuid(1)
         # CPUID.1:ECX.VMX[bit 5] -> VT
         ret = ecx & (1 << 5) != 0
         self.logger.debug('vmx support: %s', ret)
         return ret

 From that, am I assuming well that vmx support should be

enabled

also
for L1? If so, what could be the reason for not being enabled?


Nested virtualization support on L0 is supposed to enable
virtualization support (vmx flag) on L1.
How you 

[ovirt-users] Re: ETL service sampling has encountered an error. Please consult the service log for more details.

[nicolas]

Hi Shirly,

Thanks for the answer.

El 2019-06-06 16:22, Shirly Radco escribió:

Hi Nicolas,

Please open a bug in bugzilla and attach the ovirt-engine-dwh.log,
engine.log,


https://bugzilla.redhat.com/show_bug.cgi?id=1718165

Feel free to change anything that is not correctly set.


The versions of ovirt-engine and ovirt-engine-dwh
and any other relevant information that you can tell about your env.
Did you do any change before this issue started?



Not that I know, this started all of sudden.

Thanks.


Best regards,

--

Shirly Radco

BI Senior Software Engineer

Red Hat [5]

 [5]

On Thu, Jun 6, 2019 at 3:44 PM  wrote:


Hi,

We're running oVirt 4.1.9 (cannot upgrade yet until [1] is
released).
Since a few days ago our event list if full of lines like this:

   ETL service sampling has encountered an error. Please consult
the
service log for more details.

Having a look at the log I see events like:

2019-06-06


13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java


Exception|tJDBCOutput_7|org.postgresql.util.PSQLException:ERROR:
current
transaction is aborted, commands ignored until end of transaction
block|1
2019-06-06


13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java


Exception|tJDBCOutput_4|org.postgresql.util.PSQLException:ERROR:
current
transaction is aborted, commands ignored until end of transaction
block|1
Exception in component tJDBCOutput_5
org.postgresql.util.PSQLException: ERROR: current transaction is
aborted, commands ignored until end of transaction block
         at


org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)

         at


org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)

         at


org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)

         at


org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)

         at


org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)

         at


org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:363)

         at


ovirt_engine_dwh.statisticssync_4_1.StatisticsSync.tJDBCInput_10Process(StatisticsSync.java:9030)

         at


ovirt_engine_dwh.statisticssync_4_1.StatisticsSync$5.run(StatisticsSync.java:16071)

2019-06-06


13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java


Exception|tJDBCOutput_5|org.postgresql.util.PSQLException:ERROR:
current
transaction is aborted, commands ignored until end of transaction
block|1
Exception in component tRunJob_5
java.lang.RuntimeException: Child job running failed
         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_5Process(SampleRunJobs.java:1654)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_6Process(SampleRunJobs.java:1456)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_1Process(SampleRunJobs.java:1228)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_4Process(SampleRunJobs.java:1000)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tJDBCConnection_2Process(SampleRunJobs.java:767)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tJDBCConnection_1Process(SampleRunJobs.java:642)

         at


ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs$2.run(SampleRunJobs.java:2683)

2019-06-06


13:37:11|FdlWtU|TOlL8U|KNLNa4|OVIRT_ENGINE_DWH|SampleRunJobs|Default|6|Java


Exception|tRunJob_5|java.lang.RuntimeException:Child job running
failed|1
Exception in component tRunJob_1
java.lang.RuntimeException: Child job running failed
         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tRunJob_1Process(SampleTimeKeepingJob.java:6067)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_2Process(SampleTimeKeepingJob.java:5809)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_1Process(SampleTimeKeepingJob.java:)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_2Process(SampleTimeKeepingJob.java:4319)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tRowGenerator_2Process(SampleTimeKeepingJob.java:4188)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_3Process(SampleTimeKeepingJob.java:3593)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_5Process(SampleTimeKeepingJob.java:2977)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_4Process(SampleTimeKeepingJob.java:2295)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_3Process(SampleTimeKeepingJob.java:1649)

         at


ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob$2.run

[ovirt-users] ETL service sampling has encountered an error. Please consult the service log for more details.

[nicolas]

Hi,

We're running oVirt 4.1.9 (cannot upgrade yet until [1] is released). 
Since a few days ago our event list if full of lines like this:


  ETL service sampling has encountered an error. Please consult the 
service log for more details.


Having a look at the log I see events like:

2019-06-06 
13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java 
Exception|tJDBCOutput_7|org.postgresql.util.PSQLException:ERROR: current 
transaction is aborted, commands ignored until end of transaction 
block|1
2019-06-06 
13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java 
Exception|tJDBCOutput_4|org.postgresql.util.PSQLException:ERROR: current 
transaction is aborted, commands ignored until end of transaction 
block|1

Exception in component tJDBCOutput_5
org.postgresql.util.PSQLException: ERROR: current transaction is 
aborted, commands ignored until end of transaction block
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)
at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:363)
at 
ovirt_engine_dwh.statisticssync_4_1.StatisticsSync.tJDBCInput_10Process(StatisticsSync.java:9030)
at 
ovirt_engine_dwh.statisticssync_4_1.StatisticsSync$5.run(StatisticsSync.java:16071)
2019-06-06 
13:37:11|NJ4C8T|TOlL8U|FdlWtU|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java 
Exception|tJDBCOutput_5|org.postgresql.util.PSQLException:ERROR: current 
transaction is aborted, commands ignored until end of transaction 
block|1

Exception in component tRunJob_5
java.lang.RuntimeException: Child job running failed
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_5Process(SampleRunJobs.java:1654)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_6Process(SampleRunJobs.java:1456)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_1Process(SampleRunJobs.java:1228)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tRunJob_4Process(SampleRunJobs.java:1000)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tJDBCConnection_2Process(SampleRunJobs.java:767)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs.tJDBCConnection_1Process(SampleRunJobs.java:642)
at 
ovirt_engine_dwh.samplerunjobs_4_1.SampleRunJobs$2.run(SampleRunJobs.java:2683)
2019-06-06 
13:37:11|FdlWtU|TOlL8U|KNLNa4|OVIRT_ENGINE_DWH|SampleRunJobs|Default|6|Java 
Exception|tRunJob_5|java.lang.RuntimeException:Child job running 
failed|1

Exception in component tRunJob_1
java.lang.RuntimeException: Child job running failed
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tRunJob_1Process(SampleTimeKeepingJob.java:6067)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_2Process(SampleTimeKeepingJob.java:5809)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_1Process(SampleTimeKeepingJob.java:)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_2Process(SampleTimeKeepingJob.java:4319)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tRowGenerator_2Process(SampleTimeKeepingJob.java:4188)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_3Process(SampleTimeKeepingJob.java:3593)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_5Process(SampleTimeKeepingJob.java:2977)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCInput_4Process(SampleTimeKeepingJob.java:2295)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob.tJDBCConnection_3Process(SampleTimeKeepingJob.java:1649)
at 
ovirt_engine_dwh.sampletimekeepingjob_4_1.SampleTimeKeepingJob$2.run(SampleTimeKeepingJob.java:11363)


Can someone tell me how to fix it? I already restarted ovirt-engine, 
ovirt-engine-dwhd, postgresql and the three at a time and still didn't 
fix the issue. Currently the DWHD data is empty in the Dashboard.


Thanks!

  [1]: https://github.com/oVirt/ovirt-web-ui/issues/490
___
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/PXMHT5K6ZBFMNHEAUSYWWSDZ2GFUIOXQ/

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:

Hi,

We're running oVirt version 4.3.3, and trying to configure one of the
hosts to support Nested Virtualization, but when installing the nested
host it claims it doesn't support hardware virtualization.

On the physical host, we've enabled nested virtualization:

# cat /sys/module/kvm_intel/parameters/nested
Y

Content of /etc/modprobe.d/kvm.conf:

options kvm_intel nested=1
options kvm_intel enable_shadow_vmcs=1
options kvm_intel enable_apicv=1
options kvm_intel ept=1

I created a VM to run on that host, which will be the nested host. I
try to deploy it but the engine will show it failed because:

2019-05-10 09:11:32,006+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(VdsDeploy) [6381e662] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511),
An error has occurred during installation of Host host1: Failed to
execute stage 'Setup validation': Hardware does not support
virtualization.

Am I missing something here?

Thanks.
___
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/P7ZJB2NVO5DYARQTEHLMA4WR3T3P6N4N/

___
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/7LALMJF4SQQXLFZUXV2I53YRGX7J7FR6/

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM  wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to configure one of the
> hosts to support Nested Virtualization, but when installing the nested
> host it claims it doesn't support hardware virtualization.
>
> On the physical host, we've enabled nested virtualization:
>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the nested host. I
> try to deploy it but the engine will show it failed because:
>
> 2019-05-10 09:11:32,006+01 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [6381e662] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511),
> An error has occurred during installation of Host host1: Failed to
> execute stage 'Setup validation': Hardware does not support
> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in /var/log/ovirt-engine/host-deploy
(on the engine machine, it's copied there after deploy finishes).



I had a look at it, but nothing relevant shows up besides this line:

2019-05-10 09:11:32,628+0100 DEBUG otopi.context 
context._executeMethod:145 method exception

Traceback (most recent call last):
  File "/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py", line 132, in 
_executeMethod

method['method']()
  File 
"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py", 
line 71, in _validate_virtualization

_('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization

It's been some time since I configured this myself, so I do not 
remember
the details anymore. Did you check some guides/blog posts/etc. about 
this?




I didn't. I just enabled nested virtualization in the host and tried to 
deploy.



What type of CPU did you configure in the VM (and cluster)?



In the Cluster I have the Intel Broadwell Family, and as the VM CPU I 
have the default cluster CPU which is the one I just referenced. Not 
sure if anything else should be done.



To see what checks the code does, you can read [1], although the log
should be enough IMO.

[1] /usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py

Best regards,


>
> Am I missing something here?
>
> Thanks.
> ___
> 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/P7ZJB2NVO5DYARQTEHLMA4WR3T3P6N4N/
___
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/7LALMJF4SQQXLFZUXV2I53YRGX7J7FR6/

___
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/4QMYFBJUMSO7XF2XID4UWY27RMKDV6C4/

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 13:39, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:32 PM  wrote:


El 2019-05-24 13:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 1:51 PM  wrote:


El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM  wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to configure

one of the

> hosts to support Nested Virtualization, but when installing

the nested

> host it claims it doesn't support hardware virtualization.
>
> On the physical host, we've enabled nested virtualization:
>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the

nested

host. I

> try to deploy it but the engine will show it failed

because:

>
> 2019-05-10 09:11:32,006+01 ERROR
>







[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

> (VdsDeploy) [6381e662] EVENT_ID:

VDS_INSTALL_IN_PROGRESS_ERROR(511),

> An error has occurred during installation of Host host1:

Failed to

> execute stage 'Setup validation': Hardware does not support
> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in

/var/log/ovirt-engine/host-deploy

(on the engine machine, it's copied there after deploy

finishes).




I had a look at it, but nothing relevant shows up besides this

line:


2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
   File "/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py",

line

132,

in _executeMethod
     method['method']()
   File








"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",

line 71, in _validate_virtualization
     _('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization


It's been some time since I configured this myself, so I do

not

remember
the details anymore. Did you check some guides/blog posts/etc.

about

this?



I didn't. I just enabled nested virtualization in the host and

tried to

deploy.


What type of CPU did you configure in the VM (and cluster)?



In the Cluster I have the Intel Broadwell Family, and as the VM

CPU I

have the default cluster CPU which is the one I just

referenced.

Not

sure if anything else should be done.


To see what checks the code does, you can read [1], although

the

log

should be enough IMO.

[1]

/usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py

I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG

otopi.ovirt_host_deploy.hardware


hardware._isVirtualizationEnabled:208 virtualization support
GenuineIntel (cpu: False, bios: True)

So the CPU is not able to support virtualization. Why could be
that?


Hi,
can you please share the output of cat /proc/cpuinfo ?
 


Hi Simone,

Please find attached the output (assuming you meant the VM that is
meant
to be added as a host). You'll probably see the model name as
Haswell
because I forced it to test, but the same happens with Broadwell.


OK,
vmx flag is not there so this VM doesn't support virtualization and
for that you have to enable nested virt support on the underlying
level. What (SW) are you using on the underlying layer?

Let's try to recap:
L0 is your physical machine
L1 is the VM you are going to use as a virtualization host for oVirt
L2 are the VM you are going to create with oVirt

In order to be able to start a L2 VM from oVirt, you have to enable
nested virtualization support on your L0 physical host.



Ok, the output I sent in the previous e-mail was for L1. For L0 I'm 
sending the cpuinfo log now.


I saw in the code, the flag that is returning false at deployment of L1 
is this:


cpu_ok = self._cpu_has_vmx_support()

Which calls the _cpu_has_vmx_support():

def _cpu_has_vmx_support(self):
eax, ebx, ecx, edx = self._cpuid(1)
# CPUID.1:ECX.VMX[bit 5] -> VT
ret = ecx & (1 << 5) != 0
self.logger.debug('vmx support: %s', ret)
return ret

From that, am I assuming well that vmx support should be enabled also 
for L1? If so, what could be the reason for not being enabled?


Thanks again.


 


Thanks.





Best regards,


>
> Am I missing something here?
>
> Thanks.
> ___
> 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/ [1]

[1]

> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/

[2]

[2]

> List Archives:
>

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM  wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to configure one of the
> hosts to support Nested Virtualization, but when installing the nested
> host it claims it doesn't support hardware virtualization.
>
> On the physical host, we've enabled nested virtualization:
>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the nested host. I
> try to deploy it but the engine will show it failed because:
>
> 2019-05-10 09:11:32,006+01 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [6381e662] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511),
> An error has occurred during installation of Host host1: Failed to
> execute stage 'Setup validation': Hardware does not support
> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in /var/log/ovirt-engine/host-deploy
(on the engine machine, it's copied there after deploy finishes).



I had a look at it, but nothing relevant shows up besides this line:

2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
  File "/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py", line 132,
in _executeMethod
method['method']()
  File
"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",
line 71, in _validate_virtualization
_('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization

It's been some time since I configured this myself, so I do not 
remember
the details anymore. Did you check some guides/blog posts/etc. about 
this?




I didn't. I just enabled nested virtualization in the host and tried to 
deploy.



What type of CPU did you configure in the VM (and cluster)?



In the Cluster I have the Intel Broadwell Family, and as the VM CPU I
have the default cluster CPU which is the one I just referenced. Not
sure if anything else should be done.


To see what checks the code does, you can read [1], although the log
should be enough IMO.

[1] /usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py



I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG otopi.ovirt_host_deploy.hardware 
hardware._isVirtualizationEnabled:208 virtualization support 
GenuineIntel (cpu: False, bios: True)


So the CPU is not able to support virtualization. Why could be that?



Best regards,


>
> Am I missing something here?
>
> Thanks.
> ___
> 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/P7ZJB2NVO5DYARQTEHLMA4WR3T3P6N4N/
___
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/7LALMJF4SQQXLFZUXV2I53YRGX7J7FR6/

___
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/4QMYFBJUMSO7XF2XID4UWY27RMKDV6C4/

___
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/6O7QPVYUHVE7BHHSOVRATSYWJA732RPF/

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 13:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 1:51 PM  wrote:


El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM  wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to configure

one of the

> hosts to support Nested Virtualization, but when installing

the nested

> host it claims it doesn't support hardware virtualization.
>
> On the physical host, we've enabled nested virtualization:
>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the nested

host. I

> try to deploy it but the engine will show it failed because:
>
> 2019-05-10 09:11:32,006+01 ERROR
>



[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

> (VdsDeploy) [6381e662] EVENT_ID:

VDS_INSTALL_IN_PROGRESS_ERROR(511),

> An error has occurred during installation of Host host1:

Failed to

> execute stage 'Setup validation': Hardware does not support
> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in

/var/log/ovirt-engine/host-deploy

(on the engine machine, it's copied there after deploy

finishes).




I had a look at it, but nothing relevant shows up besides this

line:


2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
   File "/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py", line

132,

in _executeMethod
     method['method']()
   File




"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",

line 71, in _validate_virtualization
     _('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization


It's been some time since I configured this myself, so I do not
remember
the details anymore. Did you check some guides/blog posts/etc.

about

this?



I didn't. I just enabled nested virtualization in the host and

tried to

deploy.


What type of CPU did you configure in the VM (and cluster)?



In the Cluster I have the Intel Broadwell Family, and as the VM

CPU I

have the default cluster CPU which is the one I just referenced.

Not

sure if anything else should be done.


To see what checks the code does, you can read [1], although the

log

should be enough IMO.

[1]

/usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py

I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG otopi.ovirt_host_deploy.hardware

hardware._isVirtualizationEnabled:208 virtualization support
GenuineIntel (cpu: False, bios: True)

So the CPU is not able to support virtualization. Why could be
that?


Hi,
can you please share the output of cat /proc/cpuinfo ?
 


Hi Simone,

Please find attached the output (assuming you meant the VM that is meant 
to be added as a host). You'll probably see the model name as Haswell 
because I forced it to test, but the same happens with Broadwell.


Thanks.





Best regards,


>
> Am I missing something here?
>
> Thanks.
> ___
> 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/

[1]

> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/

[2]

> List Archives:
>



https://lists.ovirt.org/archives/list/users@ovirt.org/message/P7ZJB2NVO5DYARQTEHLMA4WR3T3P6N4N/

[3]

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

[1]

oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:




https://lists.ovirt.org/archives/list/users@ovirt.org/message/7LALMJF4SQQXLFZUXV2I53YRGX7J7FR6/

[4]

___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:




https://lists.ovirt.org/archives/list/users@ovirt.org/message/4QMYFBJUMSO7XF2XID4UWY27RMKDV6C4/

[5]
___
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/ [1]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [2]
List Archives:

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 14:30, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:56 PM  wrote:


El 2019-05-24 13:39, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:32 PM  wrote:


El 2019-05-24 13:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 1:51 PM  wrote:


El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM  wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to

configure

one of the

> hosts to support Nested Virtualization, but when

installing

the nested

> host it claims it doesn't support hardware

virtualization.

>
> On the physical host, we've enabled nested

virtualization:

>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the

nested

host. I

> try to deploy it but the engine will show it failed

because:

>
> 2019-05-10 09:11:32,006+01 ERROR
>











[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

> (VdsDeploy) [6381e662] EVENT_ID:

VDS_INSTALL_IN_PROGRESS_ERROR(511),

> An error has occurred during installation of Host host1:

Failed to

> execute stage 'Setup validation': Hardware does not

support

> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in

/var/log/ovirt-engine/host-deploy

(on the engine machine, it's copied there after deploy

finishes).




I had a look at it, but nothing relevant shows up besides

this

line:


2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
   File "/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py",

line

132,

in _executeMethod
     method['method']()
   File












"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",

line 71, in _validate_virtualization
     _('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization


It's been some time since I configured this myself, so I do

not

remember
the details anymore. Did you check some guides/blog

posts/etc.

about

this?



I didn't. I just enabled nested virtualization in the host

and

tried to

deploy.


What type of CPU did you configure in the VM (and cluster)?



In the Cluster I have the Intel Broadwell Family, and as the

VM

CPU I

have the default cluster CPU which is the one I just

referenced.

Not

sure if anything else should be done.


To see what checks the code does, you can read [1], although

the

log

should be enough IMO.

[1]

/usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py

I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG

otopi.ovirt_host_deploy.hardware


hardware._isVirtualizationEnabled:208 virtualization support
GenuineIntel (cpu: False, bios: True)

So the CPU is not able to support virtualization. Why could be
that?


Hi,
can you please share the output of cat /proc/cpuinfo ?
 


Hi Simone,

Please find attached the output (assuming you meant the VM that

is

meant
to be added as a host). You'll probably see the model name as
Haswell
because I forced it to test, but the same happens with

Broadwell.


OK,
vmx flag is not there so this VM doesn't support virtualization

and

for that you have to enable nested virt support on the underlying
level. What (SW) are you using on the underlying layer?

Let's try to recap:
L0 is your physical machine
L1 is the VM you are going to use as a virtualization host for

oVirt

L2 are the VM you are going to create with oVirt

In order to be able to start a L2 VM from oVirt, you have to

enable

nested virtualization support on your L0 physical host.



Ok, the output I sent in the previous e-mail was for L1. For L0 I'm

sending the cpuinfo log now.

I saw in the code, the flag that is returning false at deployment
of L1
is this:

     cpu_ok = self._cpu_has_vmx_support()

Which calls the _cpu_has_vmx_support():

     def _cpu_has_vmx_support(self):
         eax, ebx, ecx, edx = self._cpuid(1)
         # CPUID.1:ECX.VMX[bit 5] -> VT
         ret = ecx & (1 << 5) != 0
         self.logger.debug('vmx support: %s', ret)
         return ret

 From that, am I assuming well that vmx support should be enabled
also
for L1? If so, what could be the reason for not being enabled?


Nested virtualization support on L0 is supposed to enable
virtualization support (vmx flag) on L1.
How you defined and started your L1 VMs?
 


I basically created the L1 VM when L0 had no nested support yet, I 
enabled the nested support once the L1 machine was already created, can 
that make a difference?


I defined the VM like any 

[ovirt-users] Re: Can't run nested virtualization

[nicolas]

El 2019-05-24 14:42, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 3:39 PM  wrote:


El 2019-05-24 14:30, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:56 PM  wrote:


El 2019-05-24 13:39, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 2:32 PM  wrote:


El 2019-05-24 13:22, Simone Tiraboschi escribió:

On Fri, May 24, 2019 at 1:51 PM  wrote:


El 2019-05-24 12:41, nico...@devels.es escribió:

El 2019-05-14 08:19, Yedidyah Bar David escribió:

On Tue, May 14, 2019 at 10:02 AM 

wrote:


Please, any ideas about this?

Thanks.

El 2019-05-10 09:18, nico...@devels.es escribió:
> Hi,
>
> We're running oVirt version 4.3.3, and trying to

configure

one of the

> hosts to support Nested Virtualization, but when

installing

the nested

> host it claims it doesn't support hardware

virtualization.

>
> On the physical host, we've enabled nested

virtualization:

>
> # cat /sys/module/kvm_intel/parameters/nested
> Y
>
> Content of /etc/modprobe.d/kvm.conf:
>
> options kvm_intel nested=1
> options kvm_intel enable_shadow_vmcs=1
> options kvm_intel enable_apicv=1
> options kvm_intel ept=1
>
> I created a VM to run on that host, which will be the

nested

host. I

> try to deploy it but the engine will show it failed

because:

>
> 2019-05-10 09:11:32,006+01 ERROR
>















[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

> (VdsDeploy) [6381e662] EVENT_ID:

VDS_INSTALL_IN_PROGRESS_ERROR(511),

> An error has occurred during installation of Host

host1:

Failed to

> execute stage 'Setup validation': Hardware does not

support

> virtualization.




Hi Yedidyah, sorry for the delayed answer.


You might find some more details in the host-deploy log,
which you should be able to find in

/var/log/ovirt-engine/host-deploy

(on the engine machine, it's copied there after deploy

finishes).




I had a look at it, but nothing relevant shows up besides

this

line:


2019-05-10 09:11:32,628+0100 DEBUG otopi.context
context._executeMethod:145 method exception
Traceback (most recent call last):
   File

"/tmp/ovirt-qPjYkVy6Ys/pythonlib/otopi/context.py",

line

132,

in _executeMethod
     method['method']()
   File
















"/tmp/ovirt-qPjYkVy6Ys/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py",

line 71, in _validate_virtualization
     _('Hardware does not support virtualization')
RuntimeError: Hardware does not support virtualization


It's been some time since I configured this myself, so I

do

not

remember
the details anymore. Did you check some guides/blog

posts/etc.

about

this?



I didn't. I just enabled nested virtualization in the host

and

tried to

deploy.


What type of CPU did you configure in the VM (and

cluster)?




In the Cluster I have the Intel Broadwell Family, and as

the

VM

CPU I

have the default cluster CPU which is the one I just

referenced.

Not

sure if anything else should be done.


To see what checks the code does, you can read [1],

although

the

log

should be enough IMO.

[1]



/usr/lib/python2.7/site-packages/ovirt_host_deploy/hardware.py


I just saw this in the log:

2019-05-24 12:44:56,000+0100 DEBUG

otopi.ovirt_host_deploy.hardware


hardware._isVirtualizationEnabled:208 virtualization support
GenuineIntel (cpu: False, bios: True)

So the CPU is not able to support virtualization. Why could

be

that?


Hi,
can you please share the output of cat /proc/cpuinfo ?
 


Hi Simone,

Please find attached the output (assuming you meant the VM

that

is

meant
to be added as a host). You'll probably see the model name as
Haswell
because I forced it to test, but the same happens with

Broadwell.


OK,
vmx flag is not there so this VM doesn't support virtualization

and

for that you have to enable nested virt support on the

underlying

level. What (SW) are you using on the underlying layer?

Let's try to recap:
L0 is your physical machine
L1 is the VM you are going to use as a virtualization host for

oVirt

L2 are the VM you are going to create with oVirt

In order to be able to start a L2 VM from oVirt, you have to

enable

nested virtualization support on your L0 physical host.



Ok, the output I sent in the previous e-mail was for L1. For L0

I'm


sending the cpuinfo log now.

I saw in the code, the flag that is returning false at

deployment

of L1
is this:

     cpu_ok = self._cpu_has_vmx_support()

Which calls the _cpu_has_vmx_support():

     def _cpu_has_vmx_support(self):
         eax, ebx, ecx, edx = self._cpuid(1)
         # CPUID.1:ECX.VMX[bit 5] -> VT
         ret = ecx & (1 << 5) != 0
         self.logger.debug('vmx support: %s', ret)
         return ret

 From that, am I assuming well that vmx support should be

enabled

also
for L1? If so, what could be the reason for not being enabled?


Nested virtualization support on L0 is supposed to enable
virtualization support (vmx flag) on L1.
How you defined and started your L1 VMs?
 


I basically created the L1 VM when L0 had no nested support yet, I
enabled 

[ovirt-users] Can't run nested virtualization

[nicolas]

Hi,

We're running oVirt version 4.3.3, and trying to configure one of the 
hosts to support Nested Virtualization, but when installing the nested 
host it claims it doesn't support hardware virtualization.


On the physical host, we've enabled nested virtualization:

# cat /sys/module/kvm_intel/parameters/nested
Y

Content of /etc/modprobe.d/kvm.conf:

options kvm_intel nested=1
options kvm_intel enable_shadow_vmcs=1
options kvm_intel enable_apicv=1
options kvm_intel ept=1

I created a VM to run on that host, which will be the nested host. I try 
to deploy it but the engine will show it failed because:


2019-05-10 09:11:32,006+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(VdsDeploy) [6381e662] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An 
error has occurred during installation of Host host1: Failed to execute 
stage 'Setup validation': Hardware does not support virtualization.


Am I missing something here?

Thanks.
___
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/P7ZJB2NVO5DYARQTEHLMA4WR3T3P6N4N/

[ovirt-users] Re: Buy Movie Jackets

[nicolas]

Guys, this is starting to be annoying. Can anything be done to 
unsubscribe users with these security issues?


El 2019-05-03 07:50, deannawillia...@gmail.com escribió:

We are famous in the leather industry with our best quality of leather
and its stuff we are providing service from all over the world with
shipping specially free shipping in the USA, CANADA, AUSTRALIA, and
the UK we have our official website which is
https://www.buymoviejackets.com/
___
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/ZI7TUGIP2YGTVWQAFYRQFISXY2TRKZUT/

___
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/QQ4MX5C5AQYKKGAX4O7E3YYMCMU66V55/

[ovirt-users] Re: distribute storage domains

[nicolas]

Hi Jason,

El 2019-08-06 22:43, Jason M. Stallings escribió:

Nicolas:

Thank you very much for this! Looks like exactly what I was looking
for... The first burst was somewhat frightening but it ended well and
now no storage domain is overused :)



Glad to hear that!


One quick question: Is it possible to limit balancing to more than one
datacenter? I have 3 datacenters and I'd like to exclude one of them.
I see the DATACENTER config variable could do this but I'm not sure
how to define more than one datacenter.



Currently, the DATACENTER parameter only allows one value. When 
developing the code I didn't expect someone having more than two Data 
Centers :-)


As a workaround, if you want to exclude the Storage Domains of an entire 
Data Center, you can exclude them explicitly using the "NOBALANCE" 
parameter of the config file, which does allow several values.


If you consider this is something that should be implemented, feel free 
to fill an issue or extend the code and send a Pull Request.


Regards.


Thanks

El mar., 6 ago. 2019 a las 15:05,  escribió:


Hi Jason,

A time ago I wrote a "Storage Balancer" exactly for that, move
disks
between storage domains to keep them below a maximum threshold of
occupation. You can find the project at [1].

It's not perfect but has been working for us for the last 3 years
with
no issues.

That won't avoid people storing new disks in the first available
storage
domain, but the balancer will distribute them between the less
occupied
storage domains afterwards.

Hope this helps,

Nicolás

   [1]: https://github.com/nkovacne/ovirt-storage-balancer [1]

El 2019-08-04 17:57, Jason M. Stallings escribió:

Hello

I'm trying to figure out a way to automatically distribute our

storage

domain occupation evenly or at least avoid them getting full. We

have

a lot of users creating vms and they seem to select the first
available storage domain, thus one is nearly full and the rest

are

barely used.

Is there a way to accomplish that?

Thank you

Jason
___
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/ [2]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [3]
List Archives:




https://lists.ovirt.org/archives/list/users@ovirt.org/message/F66H6U2CWHUFK2N4IIZWAXBF7ZYDO6KL/

[4]
___
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/ [2]
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/ [3]
List Archives:


https://lists.ovirt.org/archives/list/users@ovirt.org/message/VTWOMW6VMGK6NDV5UTFNZHKOSBP4N66K/

[5]



Links:
--
[1] https://github.com/nkovacne/ovirt-storage-balancer
[2] https://www.ovirt.org/site/privacy-policy/
[3] https://www.ovirt.org/community/about/community-guidelines/
[4]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F66H6U2CWHUFK2N4IIZWAXBF7ZYDO6KL/
[5]
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VTWOMW6VMGK6NDV5UTFNZHKOSBP4N66K/

___
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/R3XG6CX2HTZPPS32L6OHSEK2UXVEIBFP/

[ovirt-users] Re: distribute storage domains

[nicolas]

Hi Jason,

A time ago I wrote a "Storage Balancer" exactly for that, move disks 
between storage domains to keep them below a maximum threshold of 
occupation. You can find the project at [1].


It's not perfect but has been working for us for the last 3 years with 
no issues.


That won't avoid people storing new disks in the first available storage 
domain, but the balancer will distribute them between the less occupied 
storage domains afterwards.


Hope this helps,

Nicolás

  [1]: https://github.com/nkovacne/ovirt-storage-balancer

El 2019-08-04 17:57, Jason M. Stallings escribió:

Hello

I'm trying to figure out a way to automatically distribute our storage
domain occupation evenly or at least avoid them getting full. We have
a lot of users creating vms and they seem to select the first
available storage domain, thus one is nearly full and the rest are
barely used.

Is there a way to accomplish that?

Thank you

Jason
___
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/F66H6U2CWHUFK2N4IIZWAXBF7ZYDO6KL/

___
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/VTWOMW6VMGK6NDV5UTFNZHKOSBP4N66K/

[ovirt-users] iSCSI-based storages won't login to the portals with all IPs on reboot

[nicolas]

Hi,

We're running oVirt 4.3.2. Currently, we have one storage backend 
(cabinet) with two controllers, each of them with 2 network interfaces 
(4 network interfaces in total). When we added the Storage Domain, we 
discovered the target for each of the 4 IPs and marked the LUN so it 
would be added with 4 different IPs.


When we put a host on maintenance, all the paths are deactivated, and 
when we activate it back it discovers all the 4 paths for the storage 
backend. However, if we reboot the host, on activation it only activates 
one path. We can see this running 'multipath -ll'.


We can manually activate the rest of the paths using this command for 
each of the IPs:


   # iscsiadm --mode discovery --type sendtargets --portal 10.X.X.X 
--login


However, we wonder why oVirt wouldn't log into each of the IPs upon a 
boot. Is there something we're missing? Can this be fixed manually? 
Currently we're running a script on boot that will issue the command 
above for each of the IPs of the cabinet.


Thanks for any help!
___
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/ZEZ5BV5XBDRBZOUTKWLQIOHSGTTQMQ2G/

[ovirt-users] Assign permissions from within the VM portal?

[nicolas]

Hi,

We're testing version 4.3.8, we're planning to upgrade to this version 
in production as currently we're still using 4.1.9.


In 4.1.9, users could grant permissions on their created VMs to other 
users from within the VM portal, however I can't find this option on 
version 4.3.8.


Permissions granted to users so they can create and handle their VMs are 
VmCreator and DiskProfileUser on the DataCenter.


Is there a way to allow users grant permissions on their VMs to other 
users in the VM portal?


Thanks
___
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/PFL6QGASKBRPZOA4UAERRJONFRGHLFJH/

[ovirt-users] Re: Websocket-proxy not working after upgrade to 4.3

[nicolas]

El 2020-02-05 13:57, Gianluca Cecchi escribió:

On Wed, Feb 5, 2020 at 2:50 PM  wrote:


A little bit more info on it. I debugged the requests with Chrome
and
seems that the webservice call is made with https://engine:6100 [1]

(literally), instead of https://:6100.

A snapshot is included in this mail.

I don't know why is it trying to connect to this address, seems
like a
missed step on the upgrade process? (we upgraded 4.1 -> 4.2 ->
4.3).

How can I fix this problem?

Thanks!


To get current value stored:

engine-config -g WebSocketProxy

If wrong, to change it:

engine-config -s WebSocketProxy=your_desidred_fqdn:6100

systemctl restart ovirt-engine



Thanks, this helped.

Not sure why the value was changed, since websocket proxy was working 
without an issue on 4.1.9...


Anyway, it works now.

Thanks guys.


HIH,
Gianluca


Links:
--
[1] https://engine:6100

___
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/DDPI7ASCB4HVHNG5E2LHDKQRUCTLJ6ZO/

[ovirt-users] Websocket-proxy not working after upgrade to 4.3

[nicolas]

Hi,

We recently upgraded to 4.3.8 and everything is working fine but the VNC 
Console (Browser).


Once I click on "VNC Console (Browser)" on any machine from the VM 
Portal, I get a message like this:


   Disconnected from Console
   Cannot connect to websocket proxy server. Please check your websocket 
proxy certificate or ask your administrator for help. For further 
information please refer to the console manual.

   Press the 'Connect' button to reconnect the console.

Thing is that everything seems ok to me, and I cannot find further error 
log about it.


/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf content is:

   PROXY_PORT=6100
   SSL_CERTIFICATE=/etc/ssl/certs/fqdn.combined.cert
   SSL_KEY=/etc/ssl/private/fqdn.key
   FORCE_DATA_VERIFICATION=False
   CERT_FOR_DATA_VERIFICATION=/etc/pki/ovirt-engine/certs/engine.cer
   SSL_ONLY=True

On a "status" command on ovirt-websocket-proxy I just see:

   feb 05 12:23:22 fqdn systemd[1]: Starting oVirt Engine websockets 
proxy...
   feb 05 12:23:22 fqdn systemd[1]: Started oVirt Engine websockets 
proxy.
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO daemonContext:434 Using the following 
ciphers: HIGH:!aNULL
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO daemonContext:438 Minimum SSL version 
requested: TLSv1.2
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887 WebSocket server settings:
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887   - Listen on *:6100
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887   - Flash security policy 
server
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887   - SSL/TLS support
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887   - Deny non-SSL/TLS 
connections
   feb 05 12:23:22 fqdn ovirt-websocket-proxy.py[3314]: 
ovirt-websocket-proxy[3314] INFO msg:887   - proxying from *:6100 to 
targets generated by str


On the ovirt-engine.log, I just see this information:

   2020-02-05 12:29:10,085Z INFO  
[org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-110) 
[68218d5b] Running command: SetVmTicketCommand internal: false. Entities 
affected :  ID: 5bf9a0bb-da18-4d07-87da-759c0b045e28 Type: VMAction 
group CONNECT_TO_VM with role type USER
   2020-02-05 12:29:10,095Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] 
(default task-110) [68218d5b] START, SetVmTicketVDSCommand(HostName = 
kvmr01.fqdn, 
SetVmTicketVDSCommandParameters:{hostId='1828d0dc-e953-4d6a-8a95-528bb7aa849a', 
vmId='5bf9a0bb-da18-4d07-87da-759c0b045e28', protocol='VNC', 
ticket='oVoKEtgmDKnM', validTime='120', userName='user', 
userId='66a7a37f-d804-4192-9734-93f01a95dd98', 
disconnectAction='LOCK_SCREEN'}), log id: 596fbfb9
   2020-02-05 12:29:10,167Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] 
(default task-110) [68218d5b] FINISH, SetVmTicketVDSCommand, return: , 
log id: 596fbfb9
   2020-02-05 12:29:10,195Z INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(default task-110) [68218d5b] EVENT_ID: VM_SET_TICKET(164), User 
user@domain-authz initiated console session for VM user.fqdn
   2020-02-05 12:29:10,308Z INFO  
[org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-110) 
[097f6518-5f87-4947-aee6-e76c9b740bcd] Running command: 
SetVmTicketCommand internal: false. Entities affected :  ID: 
5bf9a0bb-da18-4d07-87da-759c0b045e28 Type: VMAction group CONNECT_TO_VM 
with role type USER
   2020-02-05 12:29:10,316Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] 
(default task-110) [097f6518-5f87-4947-aee6-e76c9b740bcd] START, 
SetVmTicketVDSCommand(HostName = kvmr01.fqdn, 
SetVmTicketVDSCommandParameters:{hostId='1828d0dc-e953-4d6a-8a95-528bb7aa849a', 
vmId='5bf9a0bb-da18-4d07-87da-759c0b045e28', protocol='VNC', 
ticket='A7PQWaXupvbZ', validTime='7200', userName='user', 
userId='66a7a37f-d804-4192-9734-93f01a95dd98', 
disconnectAction='LOCK_SCREEN'}), log id: 71e5165c
   2020-02-05 12:29:10,387Z INFO  
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] 
(default task-110) [097f6518-5f87-4947-aee6-e76c9b740bcd] FINISH, 
SetVmTicketVDSCommand, return: , log id: 71e5165c
   2020-02-05 12:29:10,408Z INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(default task-110) [097f6518-5f87-4947-aee6-e76c9b740bcd] EVENT_ID: 
VM_SET_TICKET(164), User user@domain-authz initiated console session for 
VM user.fqdn


Please, any tip on how to debug this? I cannot seem to find the reason 
for this.


Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: 

[ovirt-users] Compatibility version for VmPools

[nicolas]

Hi,

We recently upgraded to 4.3.8 from 4.1.9. In the update process we set 
Cluster and DataCenter compatibility versions to 4.3, but now we're 
facing a problem with VmPools. They cannot be edited and 4.1 as 
compatibility level is still forcibly set.


That means that when new machines are added to the pool, compatibility 
version 4.1 is set on them and they cannot be started as a message 
stating the following pops up:


   Failed to run VM XXX-34 due to a failed validation: [Cannot run VM. 
The Custom Compatibility Version of VM XXX-34 (4.1) is not supported in 
Data Center compatibility version 4.3.] (User: admin@internal).


Is there a workaround to start those machines, or a way to fix the 
problem?


Thanks.
___
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/H3ZJ4SHWD6SZBQ2UHVLLWLSMBXVMTSAR/

[ovirt-users] Cannot activate a Storage Domain after an oVirt crash

[nicolas]

Hi,

We're running oVirt 4.3.8 and we recently had a oVirt crash after moving 
too much disks between storage domains.


Concretely, one of the Storage Domains reports status "Unknown", 
"Total/Free/Guaranteed free spaces" are "[N/A]".


After trying to activate it in the Domain Center we see messages like 
these from all of the hosts:


VDSM hostX command GetVGInfoVDS failed: Volume Group does not exist: 
(u'vg_uuid: Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp',)


I tried putting the Storage Domain in maintenance and it fails with 
messages like:


Storage Domain iaasb13 (Data Center KVMRojo) was deactivated by 
system because it's not visible by any of the hosts.
Failed to update OVF disks 8661acd1-d1c4-44a0-a4d4-ddee834844e9, OVF 
data isn't updated on those OVF stores (Data Center KVMRojo, Storage 
Domain iaasb13).
Failed to update VMs/Templates OVF data for Storage Domain iaasb13 
in Data Center KVMRojo.


I'm sure the storage domain backend is up and running, and the LUN being 
exported.


Any hints how can I debug this problem and restore the Storage 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/UNXKR7HRCRDTTWLEYO6FFM4WOLD6YATW/

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

Hi Roman,

Unfortunately, step 1 returns nothing:

kvmr03:~# vgcfgrestore --list Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp
  No archives found in /etc/lvm/archive

I tried several hosts and noone has a copy.

Any other way to get a backup of the VG?

El 2021-09-16 13:42, Roman Bednar escribió:

Hi Nicolas,

You can try to recover VG metadata from a backup or archive which lvm
automatically creates by default.

1) To list all available backups for given VG:

#vgcfgrestore --list Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

Select the latest one which sounds right, something with a description
along the lines of "Created *before* lvremove".
You might want to select something older than the latest as lvm does a
backup also *after* running some command.

2) Find UUID of your broken PV (filter might not be needed, depends on
your local conf):

#pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304

3) Create a new PV on a different partition or disk (/dev/sdX) using
the UUID found in previous step and restorefile option:

#pvcreate --uuid  --restorefile 


4) Try to display the VG:

# vgdisplay Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

-Roman

On Thu, Sep 16, 2021 at 1:47 PM  wrote:


I can also see...

kvmr03:~# lvs | grep 927f423a-6689-4ddb-8fda-b3375c3bbca3
/dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/36001405063455cf7cd74c20bc06e9304.
Metadata location on
/dev/mapper/36001405063455cf7cd74c20bc06e9304 at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/36001405063455cf7cd74c20bc06e9304
Failed to scan VG from
/dev/mapper/36001405063455cf7cd74c20bc06e9304

Seems to me like metadata from that VG has been corrupted. Is there
a
way to recover?

El 2021-09-16 11:19, nico...@devels.es escribió:

The most relevant log snippet I have found is the following. I

assume

it cannot scan the Storage Domain, but I'm unsure why, as the

storage

domain backend is up and running.

021-09-16 11:16:58,884+0100 WARN  (monitor/219fa16) [storage.LVM]
Command ['/usr/sbin/lvm', 'vgs', '--config', 'devices {
preferred_names=["^/dev/mapper/"]  ignore_suspended_devices=1
write_cache_state=0  disable_after_error_count=3






filter=["a|^/dev/mapper/36001405063455cf7cd74c20bc06e9304$|^/dev/mapper/360014056481868b09dd4d05bee5b4185$|^/dev/mapper/360014057d9d4bc57df046888b8d8b6eb$|^/dev/mapper/360014057e612d2079b649d5b539e5f6a$|^/dev/mapper/360014059b49883b502a4fa9b81add3e4$|^/dev/mapper/36001405acece27e83b547e3a873b19e2$|^/dev/mapper/36001405dc03f6be1b8c42219e8912fbd$|^/dev/mapper/36001405f3ab584afde347d3a8855baf0$|^/dev/mapper/3600c0ff00052a0fe013ec65f0100$|^/dev/mapper/3600c0ff00052a0fe033ec65f0100$|^/dev/mapper/3600c0ff00052a0fe1b40c65f0100$|^/dev/mapper/3600c0ff00052a0fe2294c75f0100$|^/dev/mapper/3600c0ff00052a0fe2394c75f0100$|^/dev/mapper/3600c0ff00052a0fe2494c75f0100$|^/dev/mapper/3600c0ff00052a0fe2594c75f0100$|^/dev/mapper/3600c0ff00052a0fe2694c75f0100$|^/dev/mapper/3600c0ff00052a0fee293c75f0100$|^/dev/mapper/3600c0ff00052a0fee493c75f0100$|^/dev/mapper/3600c0ff00064835b628d30610100$|^/dev/mapper/3600c0ff00064835b628d30610300$|^/dev/mapper/3600c0ff000648







35b628d30610500$|^/dev/mapper/3600c0ff00064835b638d30610100$|^/dev/mapper/3600c0ff00064835b638d30610300$|^/dev/mapper/3600c0ff00064835b638d30610500$|^/dev/mapper/3600c0ff00064835b638d30610700$|^/dev/mapper/3600c0ff00064835b638d30610900$|^/dev/mapper/3600c0ff00064835b638d30610b00$|^/dev/mapper/3600c0ff00064835cb98f30610100$|^/dev/mapper/3600c0ff00064835cb98f30610300$|^/dev/mapper/3600c0ff00064835cb98f30610500$|^/dev/mapper/3600c0ff00064835cb98f30610700$|^/dev/mapper/3600c0ff00064835cb98f30610900$|^/dev/mapper/3600c0ff00064835cba8f30610100$|^/dev/mapper/3600c0ff00064835cba8f30610300$|^/dev/mapper/3600c0ff00064835cba8f30610500$|^/dev/mapper/3600c0ff00064835cba8f30610700$|^/dev/mapper/3634b35410019574796dcb0e30007$|^/dev/mapper/3634b35410019574796dcdffc0008$|^/dev/mapper/3634b354100195747999c2dc50003$|^/dev/mapper/3634b354100195747999c3c4a0004$|^/dev/mapper/3634b3541001957479c2b9c640001$|^/dev/mapper/3634

b3541001957479c2baba50002$|", "r|.*|"] } global {

locking_type=4

prioritise_write_locks=1  wait_for_locks=1  use_lvmetad=0 } backup

{

retain_min=50  retain_days=0 }', '--noheadings', '--units', 'b',
'--nosuffix', '--separator', '|', '--ignoreskippedcluster', '-o',




'uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free,lv_count,pv_count,pv_name',

'--select', 'vg_name = 219fa16f-13c9-44e4-a07d-a40c0a7fe206']
succeeded with warnings: ['
/dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at
offset 2198927383040', "  Couldn't read volume group meta

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

Hi Roman and Nir,

El 2021-09-16 13:42, Roman Bednar escribió:

Hi Nicolas,

You can try to recover VG metadata from a backup or archive which lvm
automatically creates by default.

1) To list all available backups for given VG:

#vgcfgrestore --list Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

Select the latest one which sounds right, something with a description
along the lines of "Created *before* lvremove".
You might want to select something older than the latest as lvm does a
backup also *after* running some command.



You were right. There actually *are* LV backups, I was specifying an 
incorrect ID.


So the correct command would return:

# vgcfgrestore --list 219fa16f-13c9-44e4-a07d-a40c0a7fe206
[...]
  
File:		/etc/lvm/archive/219fa16f-13c9-44e4-a07d-a40c0a7fe206_00202-1152107223.vg

  VG name:  219fa16f-13c9-44e4-a07d-a40c0a7fe206
  Description:	Created *before* executing 'vgs --noheading --nosuffix 
--units b -o +vg_uuid,vg_extent_size'

  Backup Time:  Sat Sep 11 03:41:25 2021
[...]

That one seems ok.


2) Find UUID of your broken PV (filter might not be needed, depends on
your local conf):

#pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304



As I understand it, the PV won't be listed in the 'pvs' command, this is 
just a matter of finding the associated VG. The command above won't list 
a PV associated to the VG in step 1, it just complains the PV cannot be 
read.


# pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]' 
/dev/mapper/36001405063455cf7cd74c20bc06e9304
  /dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/36001405063455cf7cd74c20bc06e9304.
  Metadata location on /dev/mapper/36001405063455cf7cd74c20bc06e9304 at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/36001405063455cf7cd74c20bc06e9304

  Failed to scan VG from /dev/mapper/36001405063455cf7cd74c20bc06e9304
  No physical volume label read from 
/dev/mapper/36001405063455cf7cd74c20bc06e9304.


So, associated PV ID is: 36001405063455cf7cd74c20bc06e9304


3) Create a new PV on a different partition or disk (/dev/sdX) using
the UUID found in previous step and restorefile option:

#pvcreate --uuid  --restorefile 




I have a question here. As I understand it, pvcreate will restore the 
correct metadata on . Then how do you restore that metadata 
on the broken storage domain, so other hosts can see the right 
information as well? Or is this just a step to recover data on 
 and then reattach the disks on the affected VMs?


Thanks so much.


4) Try to display the VG:

# vgdisplay Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

-Roman

On Thu, Sep 16, 2021 at 1:47 PM  wrote:


I can also see...

kvmr03:~# lvs | grep 927f423a-6689-4ddb-8fda-b3375c3bbca3
/dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/36001405063455cf7cd74c20bc06e9304.
Metadata location on
/dev/mapper/36001405063455cf7cd74c20bc06e9304 at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/36001405063455cf7cd74c20bc06e9304
Failed to scan VG from
/dev/mapper/36001405063455cf7cd74c20bc06e9304

Seems to me like metadata from that VG has been corrupted. Is there
a
way to recover?

El 2021-09-16 11:19, nico...@devels.es escribió:

The most relevant log snippet I have found is the following. I

assume

it cannot scan the Storage Domain, but I'm unsure why, as the

storage

domain backend is up and running.

021-09-16 11:16:58,884+0100 WARN  (monitor/219fa16) [storage.LVM]
Command ['/usr/sbin/lvm', 'vgs', '--config', 'devices {
preferred_names=["^/dev/mapper/"]  ignore_suspended_devices=1
write_cache_state=0  disable_after_error_count=3






filter=["a|^/dev/mapper/36001405063455cf7cd74c20bc06e9304$|^/dev/mapper/360014056481868b09dd4d05bee5b4185$|^/dev/mapper/360014057d9d4bc57df046888b8d8b6eb$|^/dev/mapper/360014057e612d2079b649d5b539e5f6a$|^/dev/mapper/360014059b49883b502a4fa9b81add3e4$|^/dev/mapper/36001405acece27e83b547e3a873b19e2$|^/dev/mapper/36001405dc03f6be1b8c42219e8912fbd$|^/dev/mapper/36001405f3ab584afde347d3a8855baf0$|^/dev/mapper/3600c0ff00052a0fe013ec65f0100$|^/dev/mapper/3600c0ff00052a0fe033ec65f0100$|^/dev/mapper/3600c0ff00052a0fe1b40c65f0100$|^/dev/mapper/3600c0ff00052a0fe2294c75f0100$|^/dev/mapper/3600c0ff00052a0fe2394c75f0100$|^/dev/mapper/3600c0ff00052a0fe2494c75f0100$|^/dev/mapper/3600c0ff00052a0fe2594c75f0100$|^/dev/mapper/3600c0ff00052a0fe2694c75f0100$|^/dev/mapper/3600c0ff00052a0fee293c75f0100$|^/dev/mapper/3600c0ff00052a0fee493c75f0100$|^/dev/mapper/3600c0ff00064835b628d30610100$|^/dev/mapper/3600c0ff00064835b628d30610300$|^/dev/mapper/3600c0ff000648







35b628d30610500$|^/dev/mapper/3600c0ff00064835b638d30610100$|^/dev/ma

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

I can also see...

kvmr03:~# lvs | grep 927f423a-6689-4ddb-8fda-b3375c3bbca3
  /dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/36001405063455cf7cd74c20bc06e9304.
  Metadata location on /dev/mapper/36001405063455cf7cd74c20bc06e9304 at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/36001405063455cf7cd74c20bc06e9304

  Failed to scan VG from /dev/mapper/36001405063455cf7cd74c20bc06e9304


Seems to me like metadata from that VG has been corrupted. Is there a 
way to recover?


El 2021-09-16 11:19, nico...@devels.es escribió:

The most relevant log snippet I have found is the following. I assume
it cannot scan the Storage Domain, but I'm unsure why, as the storage
domain backend is up and running.

021-09-16 11:16:58,884+0100 WARN  (monitor/219fa16) [storage.LVM]
Command ['/usr/sbin/lvm', 'vgs', '--config', 'devices {
preferred_names=["^/dev/mapper/"]  ignore_suspended_devices=1
write_cache_state=0  disable_after_error_count=3


filter=["a|^/dev/mapper/36001405063455cf7cd74c20bc06e9304$|^/dev/mapper/360014056481868b09dd4d05bee5b4185$|^/dev/mapper/360014057d9d4bc57df046888b8d8b6eb$|^/dev/mapper/360014057e612d2079b649d5b539e5f6a$|^/dev/mapper/360014059b49883b502a4fa9b81add3e4$|^/dev/mapper/36001405acece27e83b547e3a873b19e2$|^/dev/mapper/36001405dc03f6be1b8c42219e8912fbd$|^/dev/mapper/36001405f3ab584afde347d3a8855baf0$|^/dev/mapper/3600c0ff00052a0fe013ec65f0100$|^/dev/mapper/3600c0ff00052a0fe033ec65f0100$|^/dev/mapper/3600c0ff00052a0fe1b40c65f0100$|^/dev/mapper/3600c0ff00052a0fe2294c75f0100$|^/dev/mapper/3600c0ff00052a0fe2394c75f0100$|^/dev/mapper/3600c0ff00052a0fe2494c75f0100$|^/dev/mapper/3600c0ff00052a0fe2594c75f0100$|^/dev/mapper/3600c0ff00052a0fe2694c75f0100$|^/dev/mapper/3600c0ff00052a0fee293c75f0100$|^/dev/mapper/3600c0ff00052a0fee493c75f0100$|^/dev/mapper/3600c0ff00064835b628d30610100$|^/dev/mapper/3600c0ff00064835b628d30610300$|^/dev/mapper/3600c0ff000648



35b628d30610500$|^/dev/mapper/3600c0ff00064835b638d30610100$|^/dev/mapper/3600c0ff00064835b638d30610300$|^/dev/mapper/3600c0ff00064835b638d30610500$|^/dev/mapper/3600c0ff00064835b638d30610700$|^/dev/mapper/3600c0ff00064835b638d30610900$|^/dev/mapper/3600c0ff00064835b638d30610b00$|^/dev/mapper/3600c0ff00064835cb98f30610100$|^/dev/mapper/3600c0ff00064835cb98f30610300$|^/dev/mapper/3600c0ff00064835cb98f30610500$|^/dev/mapper/3600c0ff00064835cb98f30610700$|^/dev/mapper/3600c0ff00064835cb98f30610900$|^/dev/mapper/3600c0ff00064835cba8f30610100$|^/dev/mapper/3600c0ff00064835cba8f30610300$|^/dev/mapper/3600c0ff00064835cba8f30610500$|^/dev/mapper/3600c0ff00064835cba8f30610700$|^/dev/mapper/3634b35410019574796dcb0e30007$|^/dev/mapper/3634b35410019574796dcdffc0008$|^/dev/mapper/3634b354100195747999c2dc50003$|^/dev/mapper/3634b354100195747999c3c4a0004$|^/dev/mapper/3634b3541001957479c2b9c640001$|^/dev/mapper/3634

b3541001957479c2baba50002$|", "r|.*|"] } global {  locking_type=4
prioritise_write_locks=1  wait_for_locks=1  use_lvmetad=0 } backup {
retain_min=50  retain_days=0 }', '--noheadings', '--units', 'b',
'--nosuffix', '--separator', '|', '--ignoreskippedcluster', '-o',
'uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free,lv_count,pv_count,pv_name',
'--select', 'vg_name = 219fa16f-13c9-44e4-a07d-a40c0a7fe206']
succeeded with warnings: ['
/dev/mapper/36001405063455cf7cd74c20bc06e9304: Checksum error at
offset 2198927383040', "  Couldn't read volume group metadata from
/dev/mapper/36001405063455cf7cd74c20bc06e9304.", '  Metadata location
on /dev/mapper/36001405063455cf7cd74c20bc06e9304 at 2198927383040 has
invalid summary for VG.', '  Failed to read metadata summary from
/dev/mapper/36001405063455cf7cd74c20bc06e9304', '  Failed to scan VG
from /dev/mapper/36001405063455cf7cd74c20bc06e9304'] (lvm:462)
2021-09-16 11:16:58,909+0100 ERROR (monitor/219fa16) [storage.Monitor]
Setting up monitor for 219fa16f-13c9-44e4-a07d-a40c0a7fe206 failed
(monitor:330)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py",
line 327, in _setupLoop
self._setupMonitor()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py",
line 349, in _setupMonitor
self._produceDomain()
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 159, in 
wrapper

value = meth(self, *a, **kw)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py",
line 367, in _produceDomain
self.domain = sdCache.produce(self.sdUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line
110, in produce
domain.getRealDomain()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line
51, in getRealDomain
return self._cache._realProduce(self._sdUUID)
  File 

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

The most relevant log snippet I have found is the following. I assume it 
cannot scan the Storage Domain, but I'm unsure why, as the storage 
domain backend is up and running.


021-09-16 11:16:58,884+0100 WARN  (monitor/219fa16) [storage.LVM] 
Command ['/usr/sbin/lvm', 'vgs', '--config', 'devices {  
preferred_names=["^/dev/mapper/"]  ignore_suspended_devices=1  
write_cache_state=0  disable_after_error_count=3  
filter=["a|^/dev/mapper/36001405063455cf7cd74c20bc06e9304$|^/dev/mapper/360014056481868b09dd4d05bee5b4185$|^/dev/mapper/360014057d9d4bc57df046888b8d8b6eb$|^/dev/mapper/360014057e612d2079b649d5b539e5f6a$|^/dev/mapper/360014059b49883b502a4fa9b81add3e4$|^/dev/mapper/36001405acece27e83b547e3a873b19e2$|^/dev/mapper/36001405dc03f6be1b8c42219e8912fbd$|^/dev/mapper/36001405f3ab584afde347d3a8855baf0$|^/dev/mapper/3600c0ff00052a0fe013ec65f0100$|^/dev/mapper/3600c0ff00052a0fe033ec65f0100$|^/dev/mapper/3600c0ff00052a0fe1b40c65f0100$|^/dev/mapper/3600c0ff00052a0fe2294c75f0100$|^/dev/mapper/3600c0ff00052a0fe2394c75f0100$|^/dev/mapper/3600c0ff00052a0fe2494c75f0100$|^/dev/mapper/3600c0ff00052a0fe2594c75f0100$|^/dev/mapper/3600c0ff00052a0fe2694c75f0100$|^/dev/mapper/3600c0ff00052a0fee293c75f0100$|^/dev/mapper/3600c0ff00052a0fee493c75f0100$|^/dev/mapper/3600c0ff00064835b628d30610100$|^/dev/mapper/3600c0ff00064835b628d30610300$|^/dev/mapper/3600c0ff000648

35b628d30610500$|^/dev/mapper/3600c0ff00064835b638d30610100$|^/dev/mapper/3600c0ff00064835b638d30610300$|^/dev/mapper/3600c0ff00064835b638d30610500$|^/dev/mapper/3600c0ff00064835b638d30610700$|^/dev/mapper/3600c0ff00064835b638d30610900$|^/dev/mapper/3600c0ff00064835b638d30610b00$|^/dev/mapper/3600c0ff00064835cb98f30610100$|^/dev/mapper/3600c0ff00064835cb98f30610300$|^/dev/mapper/3600c0ff00064835cb98f30610500$|^/dev/mapper/3600c0ff00064835cb98f30610700$|^/dev/mapper/3600c0ff00064835cb98f30610900$|^/dev/mapper/3600c0ff00064835cba8f30610100$|^/dev/mapper/3600c0ff00064835cba8f30610300$|^/dev/mapper/3600c0ff00064835cba8f30610500$|^/dev/mapper/3600c0ff00064835cba8f30610700$|^/dev/mapper/3634b35410019574796dcb0e30007$|^/dev/mapper/3634b35410019574796dcdffc0008$|^/dev/mapper/3634b354100195747999c2dc50003$|^/dev/mapper/3634b354100195747999c3c4a0004$|^/dev/mapper/3634b3541001957479c2b9c640001$|^/dev/mapper/3634
b3541001957479c2baba50002$|", 
"r|.*|"] } global {  locking_type=4  prioritise_write_locks=1  
wait_for_locks=1  use_lvmetad=0 } backup {  retain_min=50  retain_days=0 
}', '--noheadings', '--units', 'b', '--nosuffix', '--separator', '|', 
'--ignoreskippedcluster', '-o', 
'uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free,lv_count,pv_count,pv_name', 
'--select', 'vg_name = 219fa16f-13c9-44e4-a07d-a40c0a7fe206'] succeeded 
with warnings: ['  /dev/mapper/36001405063455cf7cd74c20bc06e9304: 
Checksum error at offset 2198927383040', "  Couldn't read volume group 
metadata from /dev/mapper/36001405063455cf7cd74c20bc06e9304.", '  
Metadata location on /dev/mapper/36001405063455cf7cd74c20bc06e9304 at 
2198927383040 has invalid summary for VG.', '  Failed to read metadata 
summary from /dev/mapper/36001405063455cf7cd74c20bc06e9304', '  Failed 
to scan VG from /dev/mapper/36001405063455cf7cd74c20bc06e9304'] 
(lvm:462)
2021-09-16 11:16:58,909+0100 ERROR (monitor/219fa16) [storage.Monitor] 
Setting up monitor for 219fa16f-13c9-44e4-a07d-a40c0a7fe206 failed 
(monitor:330)

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 
327, in _setupLoop

self._setupMonitor()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 
349, in _setupMonitor

self._produceDomain()
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 159, in 
wrapper

value = meth(self, *a, **kw)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/monitor.py", line 
367, in _produceDomain

self.domain = sdCache.produce(self.sdUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 110, 
in produce

domain.getRealDomain()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 51, 
in getRealDomain

return self._cache._realProduce(self._sdUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 134, 
in _realProduce

domain = self._findDomain(sdUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 151, 
in _findDomain

return findMethod(sdUUID)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/sdc.py", line 176, 
in _findUnfetchedDomain

raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist: 
(u'219fa16f-13c9-44e4-a07d-a40c0a7fe206',)



El 2021-09-16 08:28, Vojtech Juranek escribió:

On Wednesday, 15 September 2021 14:52:27 CEST nico...@devels.es wrote:

Hi,

We're running oVirt 4.3.8 and we recently had a 

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

So, I've made several attempts to restore the metadata.

In my last e-mail I said in step 2 that the PV ID is: 
36001405063455cf7cd74c20bc06e9304, which is incorrect.


I'm trying to find out the PV UUID running "pvs -o pv_name,pv_uuid 
--config='devices/filter = ["a|.*|"]' 
/dev/mapper/36001405063455cf7cd74c20bc06e9304". However, it shows no PV 
UUID. All I get from the command output is:


# pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]' 
/dev/mapper/36001405063455cf7cd74c20bc06e9304
  /dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
  Metadata location on /dev/mapper/360014057b367e3a53b44ab392ae0f25f at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f

  Failed to scan VG from /dev/mapper/360014057b367e3a53b44ab392ae0f25f
  /dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
  Metadata location on /dev/mapper/360014057b367e3a53b44ab392ae0f25f at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f

  Failed to scan VG from /dev/mapper/360014057b367e3a53b44ab392ae0f25f
  Failed to find device "/dev/mapper/36001405063455cf7cd74c20bc06e9304".

I tried running a bare "vgcfgrestore 
219fa16f-13c9-44e4-a07d-a40c0a7fe206" command, which returned:


# vgcfgrestore 219fa16f-13c9-44e4-a07d-a40c0a7fe206
  /dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
  Metadata location on /dev/mapper/360014057b367e3a53b44ab392ae0f25f at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f

  Failed to scan VG from /dev/mapper/360014057b367e3a53b44ab392ae0f25f
  Couldn't find device with uuid Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.
  Cannot restore Volume Group 219fa16f-13c9-44e4-a07d-a40c0a7fe206 with 
1 PVs marked as missing.

  Restore failed.

Seems that the PV is missing, however, I assume the PV UUID (from output 
above) is Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.


So I tried running:

# pvcreate --uuid Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb --restore 
/etc/lvm/archive/219fa16f-13c9-44e4-a07d-a40c0a7fe206_00200-1084769199.vg 
/dev/sdb1

  Couldn't find device with uuid Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.
  /dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at 
offset 2198927383040
  Couldn't read volume group metadata from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
  Metadata location on /dev/mapper/360014057b367e3a53b44ab392ae0f25f at 
2198927383040 has invalid summary for VG.
  Failed to read metadata summary from 
/dev/mapper/360014057b367e3a53b44ab392ae0f25f

  Failed to scan VG from /dev/mapper/360014057b367e3a53b44ab392ae0f25f
  Device /dev/sdb1 excluded by a filter.

Either the PV UUID is not the one I specified, or the system can't find 
it (or both).


El 2021-09-20 09:21, nico...@devels.es escribió:

Hi Roman and Nir,

El 2021-09-16 13:42, Roman Bednar escribió:

Hi Nicolas,

You can try to recover VG metadata from a backup or archive which lvm
automatically creates by default.

1) To list all available backups for given VG:

#vgcfgrestore --list Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

Select the latest one which sounds right, something with a description
along the lines of "Created *before* lvremove".
You might want to select something older than the latest as lvm does a
backup also *after* running some command.



You were right. There actually *are* LV backups, I was specifying an
incorrect ID.

So the correct command would return:

# vgcfgrestore --list 219fa16f-13c9-44e4-a07d-a40c0a7fe206
[...]

File:   
/etc/lvm/archive/219fa16f-13c9-44e4-a07d-a40c0a7fe206_00202-1152107223.vg
  VG name:  219fa16f-13c9-44e4-a07d-a40c0a7fe206
  Description:  Created *before* executing 'vgs --noheading --nosuffix
--units b -o +vg_uuid,vg_extent_size'
  Backup Time:  Sat Sep 11 03:41:25 2021
[...]

That one seems ok.


2) Find UUID of your broken PV (filter might not be needed, depends on
your local conf):

#pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304



As I understand it, the PV won't be listed in the 'pvs' command, this
is just a matter of finding the associated VG. The command above won't
list a PV associated to the VG in step 1, it just complains the PV
cannot be read.

# pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304
  /dev/mapper/36001405063455cf7cd74c20bc06e9304: C

[ovirt-users] Failed to update OVF disks / Failed to update VMs/Templates OVF data for Storage Domain

[nicolas]

Hi,

We upgraded from oVirt 4.3.8 to 4.4.8 and sometimes we're finding events 
like these in the event log (3-4 times/day):


Failed to update OVF disks 77818843-f72e-4d40-9354-4e1231da341f, OVF 
data isn't updated on those OVF stores (Data Center KVMRojo, Storage 
Domain pv04-003).
Failed to update VMs/Templates OVF data for Storage Domain pv02-002 
in Data Center KVMRojo.


I found [1], however, it seems not to solve the issue. I restarted all 
the hosts and we're still getting the messages.


We couldn't upgrade hosts to 4.4 yet, FWIW. Maybe it's caused by this?

If someone could shed some light about this, I'd be grateful.

Thanks.

  [1]: https://access.redhat.com/solutions/3353011
___
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/TUZ6JXMWVYZMEOOOAA4NESZK4LZNEC2A/

[ovirt-users] Using third-party certificate: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[nicolas]

Hi,

I'm making a bare metal oVirt installation, version 4.4.8. 
'ovirt-engine' command ends well, however, we're using a third-party 
certificate (from LetsEncrypt) both for the apache server and the 
ovirt-websocket-proxy. So we changed configuration files regarding httpd 
and ovirt-websocket-proxy.


Once changed the configurations, if I try to log in to the oVirt engine, 
I get a "PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to 
find valid certification path to requested target" error.


In prior versions we used to add the chain to the 
/etc/pki/ovirt-engine/.truststore file, however, simply listing the 
current certificates seems not to be working on 4.4.8.


  # LANG=C keytool -list -keystore /etc/pki/ovirt-engine/.truststore 
-alias intermedia_le -storepass mypass

  keytool error: java.io.IOException: Invalid keystore format

Is there something I'm missing here?

Thank
___
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/5VWVBQGIWJSPWVTV5UK2I2VXBNDV6GSS/

[ovirt-users] Re: Using third-party certificate: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[nicolas]

Thanks, this put me in the correct track.

In my case, I just needed to run step 2, as the rest of the 
configuration is being handled in a different way and works well. I also 
tried to restart the host and it still works.


Thanks for the help!

El 2021-10-01 00:13, Edward Berger escribió:

I have an engine with a similar issue.
You might want to revert to the old self signed cert created by
installation, and then follow the instructions at
   https://ovirt.org/documentation/administration_guide/index.html
to try re-installing the third party cert after you're sure the
original cert is working properly.

My temp fix for this (didn't survive an engine VM reboot) was to cat
the cert I was installing with its intermediate-root cert into

a file named full.crt and then running a command as root like...

keytool -import -trustcacerts -keystore /etc/pki/java/cacerts
-storepass changeit -alias "$YOURALIAS" -import -file full.crt
and then systemctl restart ovirt-engine #to pick up the change.

Still trying to track down what's different on this one vs others that
work.

  key size is larger
  cert has alternative name.

On Thu, Sep 30, 2021 at 4:47 PM Nicolás  wrote:


Please, any help with this?

El 29/9/21 a las 13:21, nico...@devels.es escribió:

Hi,

I'm making a bare metal oVirt installation, version 4.4.8.
'ovirt-engine' command ends well, however, we're using a

third-party

certificate (from LetsEncrypt) both for the apache server and the
ovirt-websocket-proxy. So we changed configuration files regarding



httpd and ovirt-websocket-proxy.

Once changed the configurations, if I try to log in to the oVirt
engine, I get a "PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable

to

find valid certification path to requested target" error.

In prior versions we used to add the chain to the
/etc/pki/ovirt-engine/.truststore file, however, simply listing

the

current certificates seems not to be working on 4.4.8.

# LANG=C keytool -list -keystore

/etc/pki/ovirt-engine/.truststore

-alias intermedia_le -storepass mypass
keytool error: java.io.IOException: Invalid keystore format

Is there something I'm missing here?

Thank
___
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/5VWVBQGIWJSPWVTV5UK2I2VXBNDV6GSS/

___
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/VKYBE6TJZFMAXX2G6GPMXIQYW7F5LABY/

___
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/HQJS3WEZPYJV3DTI4FNNWK4FC4GFD3HV/

[ovirt-users] Re: Cannot activate a Storage Domain after an oVirt crash

[nicolas]

lvm2 packages on all machines are the same as Nir suggested. I tried the 
pvck command, but it said the PV UUID did not exist. Finally ended up 
forcibly removing the storage domain.


Thanks anyway.

El 2021-09-20 15:13, Roman Bednar escribió:

Did you update the packages as suggested by Nir? If so and it still
does not work, maybe try the pvck recovery that Nir described too.

If that still does not work consider filing a bug for lvm and
providing a failing command(s) output with - option in the
description or attachment. Perhaps there is a better way or a known
workaround.

-Roman

On Mon, Sep 20, 2021 at 2:22 PM  wrote:


So, I've made several attempts to restore the metadata.

In my last e-mail I said in step 2 that the PV ID is:
36001405063455cf7cd74c20bc06e9304, which is incorrect.

I'm trying to find out the PV UUID running "pvs -o pv_name,pv_uuid
--config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304". However, it shows no
PV
UUID. All I get from the command output is:

# pvs -o pv_name,pv_uuid --config='devices/filter = ["a|.*|"]'
/dev/mapper/36001405063455cf7cd74c20bc06e9304
/dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
Metadata location on
/dev/mapper/360014057b367e3a53b44ab392ae0f25f at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Failed to scan VG from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
/dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
Metadata location on
/dev/mapper/360014057b367e3a53b44ab392ae0f25f at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Failed to scan VG from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Failed to find device
"/dev/mapper/36001405063455cf7cd74c20bc06e9304".

I tried running a bare "vgcfgrestore
219fa16f-13c9-44e4-a07d-a40c0a7fe206" command, which returned:

# vgcfgrestore 219fa16f-13c9-44e4-a07d-a40c0a7fe206
/dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
Metadata location on
/dev/mapper/360014057b367e3a53b44ab392ae0f25f at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Failed to scan VG from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Couldn't find device with uuid
Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.
Cannot restore Volume Group 219fa16f-13c9-44e4-a07d-a40c0a7fe206
with
1 PVs marked as missing.
Restore failed.

Seems that the PV is missing, however, I assume the PV UUID (from
output
above) is Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.

So I tried running:

# pvcreate --uuid Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb --restore


/etc/lvm/archive/219fa16f-13c9-44e4-a07d-a40c0a7fe206_00200-1084769199.vg

[1]
/dev/sdb1
Couldn't find device with uuid
Q3xkre-25cg-L3Do-aeMD-iLem-wOHh-fb8fzb.
/dev/mapper/360014057b367e3a53b44ab392ae0f25f: Checksum error at
offset 2198927383040
Couldn't read volume group metadata from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f.
Metadata location on
/dev/mapper/360014057b367e3a53b44ab392ae0f25f at
2198927383040 has invalid summary for VG.
Failed to read metadata summary from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Failed to scan VG from
/dev/mapper/360014057b367e3a53b44ab392ae0f25f
Device /dev/sdb1 excluded by a filter.

Either the PV UUID is not the one I specified, or the system can't
find
it (or both).

El 2021-09-20 09:21, nico...@devels.es escribió:

Hi Roman and Nir,

El 2021-09-16 13:42, Roman Bednar escribió:

Hi Nicolas,

You can try to recover VG metadata from a backup or archive which

lvm

automatically creates by default.

1) To list all available backups for given VG:

#vgcfgrestore --list Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp

Select the latest one which sounds right, something with a

description

along the lines of "Created *before* lvremove".
You might want to select something older than the latest as lvm

does a

backup also *after* running some command.



You were right. There actually *are* LV backups, I was specifying

an

incorrect ID.

So the correct command would return:

# vgcfgrestore --list 219fa16f-13c9-44e4-a07d-a40c0a7fe206
[...]

File:



/etc/lvm/archive/219fa16f-13c9-44e4-a07d-a40c0a7fe206_00202-1152107223.vg

[2]

VG name:219fa16f-13c9-44e4-a07d-a40c0a7fe206
Description:Created *before* executing 'vgs --noheading

--nosuffix

--units b -o +vg_uuid,vg_extent_size'
Backup Time:Sat Sep 11 03:41:25 2021
[...]

That one seems ok.


2) Find UUID of your broken 

[ovirt-users] Cannot add Virtual Disk. Disk configuration (RAW Sparse backup-None) is incompatible with the storage domain type.

[nicolas]

Hi,

We're using oVirt 4.4.8.6. We make an intensive use of the VM portal 
because we've hundreds of students creating their own VMs. Recently, one 
of the professors reported that they are encountering an error when 
adding a disk to a newly created VM.


They are creating ISO based VMs (CentOS-8-Stream in this case), 
everything goes smoothly but when adding a thin-provisioned disk, this 
error shows up:


  2022-02-17 09:56:28,073Z INFO  
[org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default 
task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Lock Acquired to 
object 
'EngineLock:{exclusiveLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM_DISK_BOOT]', 
sharedLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM]'}'
  2022-02-17 09:56:28,446Z WARN  
[org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default 
task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Validation of action 
'AddDisk' failed for user aluX@domain-authz. Reasons: 
VAR__ACTION__ADD,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_CONFIGURATION_NOT_SUPPORTED,$volumeFormat 
RAW,$volumeType Sparse,$backup None
  2022-02-17 09:56:28,446Z INFO  
[org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default 
task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Lock freed to object 
'EngineLock:{exclusiveLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM_DISK_BOOT]', 
sharedLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM]'}'
  2022-02-17 09:56:28,504Z ERROR 
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default 
task-39078) [] Operation Failed: [Cannot add Virtual Disk. Disk 
configuration (RAW Sparse backup-None) is incompatible with the storage 
domain type.]


However, changing the provisioning to thick does work and the disk can 
be added.


I found [1] which talks about this but I'm not sure if it's the same 
issue, nor it has a solution yet.


Is this a known bug? Does it have any workaround beyond creating 
thick-provisioned disks?


Thanks.

Nicolás

  [1]: https://access.redhat.com/solutions/6022811
___
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/OPGUDWMDPHWTTTECVEYH57XL5RPXJ7CY/

[ovirt-users] No bootable device

[nicolas]

Hi,

We're running oVirt 4.4.8.6. We have uploaded a qcow2 image (metasploit 
v.3, FWIW) using the GUI (Storage -> Disks -> Upload -> Start). The 
image is in qcow2 format. No options on the right side were checked. The 
upload went smoothly, so we now tried to attach the disk to a VM.


To do that, we opened the VM -> Disks -> Attach and selected the disk. 
As interface, VirtIO-iSCSI was chosen, and the disk was marked as OS, so 
the "bootable" checkbox was selected.


The VM was later powered on, but when accessing the console the message 
"No bootable device." appears. We're pretty sure this is a bootable 
image, because it was tested on other virtualization infrastructure and 
it boots well. We also tried to upload the image in RAW format but the 
result is the same.


What are we missing here? Is anything else needed to do so the disk is 
bootable?


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/66MPXOVY62HCGBDOZGQKMNEE54FG6X6F/

[ovirt-users] Re: No bootable device

[nicolas]

Hi _isi_,

I already tried with all chipset/firmwares available. Still I get the 
same result, it cannot boot with that disk. Not sure what the problem 
actually is, as I said, I'm pretty sure the disk is bootable under 
VirtualBox.


Thanks.

El 2022-03-23 14:50, uli.i...@elkb.de escribió:

Hi,

I guess you should check Chipset / Firmware Type Setting of VM. If it
is UEFI or BIOS boot.

_isi_
___
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/FUMIPVESOS4LVHQ24R4IAAE3S6L7NH5Z/

___
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/KGJWLIC7S3LTRPHN2VNGVVFL5REBCQFX/

[ovirt-users] Re: No bootable device

[nicolas]

Hi Abe,

Yes, it was set as bootable. I tried your approach, however I get the 
same results; converted the disk with qemu-img from vmdk to qcow2, tried 
any disk driver (SATA, VirtIO, VirtIO-SCSI) and also tried all 
chipset/firmwares available. Still I get the same result, it cannot boot 
with that disk.


Thanks.

El 2022-03-24 18:33, Abe E escribió:
Is it set as bootable? I have seen some QCOWs not be read correctly by 
ovirt.

In that case I would take an OVA file and convert it manually to QCOW
using the CLI, sometimes the QCOW works only with IDE from what I have
seen.

My way is somewhat long but usually works for me:
Upload to Disk page in GUI and attach to a premade VM -- If it fails 
use CLI:

CLI:
tar -xvf .ova
it will extract to .vmdk files
OR if you have a VMDK already

qemu-img convert -disk001.vmdk .qcow2 -O qcow2

Once completed, you should verify that the file is successfully a QEMU
QCOW2 Image.
file .qcow2

You can then download over winscp and upload to the GUI Disks page and
attach to a VM -- Sometimes if you have errors on boot you need to
choose a different CPU or set HDD to IDE or virtIO-Sata.
___
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/GZ526EVNG5Q4TU75BS6ICNBIF3JL2VWR/

___
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/ABRBPC3OIRJ2WFER62F7VJKU2DZ75O26/

[ovirt-users] Re: Correct way to search VM by mac

[nicolas]

Hi,

We have a Python-SDK script to find MAC dupes in our infrastructure.

I'm attaching the script, you just need to set the URI, USERNAME, 
PASSWORD, CERTPATH and MACPOOLS variables.


Hope this helps.

Regards,

Nicolás

El 2022-03-25 14:35, Gianluca Cecchi escribió:

Sorry, incomplete message sent...

today I had a problem about conflicting MAC between two different VMs.
The source of the problem was a VM created on env1 managed by engine1
and then transferred some weeks ago to env2 managed by engine2.
The two envs share some networks and during migration I didn't change
the mac of the vnic after completing it.
So the mac was left free from env1 and used in env2.

The default mac pools are different ones between env1 and env2.
So today in env1 I created a new vm on the same vlan as the previous
one and oVirt assigned the previous one mac, now freed on it,
originating big problems...
I found an article (https://access.redhat.com/solutions/695383) to
search in the engine web admin by mac, but it was for version 3.2 and
it seems it doesn't work in 4.4.10.
In VMs page I search filling the query with

mac = my_mac
or

Vms: mac = my_mac

but it keeps thinking with 3 squares blinking in the page. I have not
so many VMs to justify time elapsing... (less then 50)

Can I search for mac? How?

Thanks,

Gianluca

On Fri, Mar 25, 2022 at 3:27 PM Gianluca Cecchi
 wrote:


Hello,
today I had a problem about conflicting MAC.
The source of problem was a VM transferred from an engine
environment

___
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/2UN4APDMFAJEWXKAIEKREIFERH2WHAS4/
#!/usr/bin/env python

import os.path
from sys import exit

from ovirtsdk4 import Connection, types

URI = 'https://your-fqdn/ovirt-engine/api'
USERNAME = 'admin@internal'
PASSWORD = 'your-pass'
CERTPATH = '/etc/ssl/certs/your-cert-path.cert'

# Don't touch
MACOCTETS = ['00', '01', '02', '03', '04', '05', '06', '07', '08', '09', '0a', '0b', '0c', '0d', '0e', '0f',
 '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '1a', '1b', '1c', '1d', '1e', '1f',
 '20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '2a', '2b', '2c', '2d', '2e', '2f',
 '30', '31', '32', '33', '34', '35', '36', '37', '38', '39', '3a', '3b', '3c', '3d', '3e', '3f',
 '40', '41', '42', '43', '44', '45', '46', '47', '48', '49', '4a', '4b', '4c', '4d', '4e', '4f',
 '50', '51', '52', '53', '54', '55', '56', '57', '58', '59', '5a', '5b', '5c', '5d', '5e', '5f',
 '60', '61', '62', '63', '64', '65', '66', '67', '68', '69', '6a', '6b', '6c', '6d', '6e', '6f',
 '70', '71', '72', '73', '74', '75', '76', '77', '78', '79', '7a', '7b', '7c', '7d', '7e', '7f',
 '80', '81', '82', '83', '84', '85', '86', '87', '88', '89', '8a', '8b', '8c', '8d', '8e', '8f',
 '90', '91', '92', '93', '94', '95', '96', '97', '98', '99', '9a', '9b', '9c', '9d', '9e', '9f',
 'a0', 'a1', 'a2', 'a3', 'a4', 'a5', 'a6', 'a7', 'a8', 'a9', 'aa', 'ab', 'ac', 'ad', 'ae', 'af',
 'b0', 'b1', 'b2', 'b3', 'b4', 'b5', 'b6', 'b7', 'b8', 'b9', 'ba', 'bb', 'bc', 'bd', 'be', 'bf',
 'c0', 'c1', 'c2', 'c3', 'c4', 'c5', 'c6', 'c7', 'c8', 'c9', 'ca', 'cb', 'cc', 'cd', 'ce', 'cf',
 'd0', 'd1', 'd2', 'd3', 'd4', 'd5', 'd6', 'd7', 'd8', 'd9', 'da', 'db', 'dc', 'dd', 'de', 'df',
 'e0', 'e1', 'e2', 'e3', 'e4', 'e5', 'e6', 'e7', 'e8', 'e9', 'ea', 'eb', 'ec', 'ed', 'ee', 'ef',
 'f0', 'f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8', 'f9', 'fa', 'fb', 'fc', 'fd', 'fe', 'ff']


# Replace this with your active MAC address pools, WITHOUT the last octet
MACPOOLS = ['00:11:22:33:44', '00:55:66:77:88']

conn = Connection(
   url=URI,
   username=USERNAME,
   password=PASSWORD,
   ca_file=CERTPATH
)

if not conn.test(raise_exception=False):
print("ERROR: Can't connect (credentials?)")
exit(1)

vms_macs = {}

sys_serv = conn.system_service()
vms_serv = sys_serv.vms_service()

macs = []
for vm in vms_serv.list():
nics = conn.follow_link(vm.nics)
for nic in nics:
if nic.mac.address in vms_macs:
vms_macs[nic.mac.address].append(vm.name)
else:
vms_macs[nic.mac.address] = [vm.name]
macs.append(nic.mac.address)

def find_unused_mac():
global MACOCTETS, MACPOOLS, macs

for pool in MACPOOLS:
for octet in MACOCTETS:
mac = "%s:%s" % (pool, octet)
if mac not in macs:
macs.append(mac)
return mac
return None

have_dupes = False
for mac, vms in vms_macs.items():
if len(vms) > 1:
have_dupes = True
print("Dupe 

[ovirt-users] Re: No bootable device

[nicolas]

Hi,

The checkbox is already checked, when you mark a disk as "OS" it's 
marked automatically. Still it won't boot.


Thanks.

El 2022-03-23 15:23, Angus Clarke escribió:

Hi Nicolas

 In oVirt 4.3:

 Compute -> Virtual Machines -> Select VM

 On the VM screen:

 Disks -> Highlight disk -> Edit

 Check the bootable tick box

 Hope that helps
 Angus

-

FROM: nico...@devels.es 
SENT: 23 March 2022 14:00
TO: users@ovirt.org 
SUBJECT: [ovirt-users] No bootable device

Hi,

We're running oVirt 4.4.8.6. We have uploaded a qcow2 image
(metasploit
v.3, FWIW) using the GUI (Storage -> Disks -> Upload -> Start). The
image is in qcow2 format. No options on the right side were checked.
The
upload went smoothly, so we now tried to attach the disk to a VM.

To do that, we opened the VM -> Disks -> Attach and selected the disk.

As interface, VirtIO-iSCSI was chosen, and the disk was marked as OS,
so
the "bootable" checkbox was selected.

The VM was later powered on, but when accessing the console the
message
"No bootable device." appears. We're pretty sure this is a bootable
image, because it was tested on other virtualization infrastructure
and
it boots well. We also tried to upload the image in RAW format but the

result is the same.

What are we missing here? Is anything else needed to do so the disk is

bootable?

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.htmldata=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FRPdEWdd3CYyCPcn8khKsx%2BSUvPy%2BkbhoYvNTJUAhPQ%3Dreserved=0
[1]
oVirt Code of Conduct:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Xu5G3BJFH8T0NMxR3jCfUKS0vNu81Ud3cLwIpNYYkR0%3Dreserved=0
[2]
List Archives:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F66MPXOVY62HCGBDOZGQKMNEE54FG6X6F%2Fdata=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=hVp2qxt9fS2pA71HvQbZEqpRT26dSLgGk%2FoFLFbSG5I%3Dreserved=0
[3]


Links:
--
[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.htmlamp;data=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000amp;sdata=%2FRPdEWdd3CYyCPcn8khKsx%2BSUvPy%2BkbhoYvNTJUAhPQ%3Damp;reserved=0
[2]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Famp;data=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000amp;sdata=Xu5G3BJFH8T0NMxR3jCfUKS0vNu81Ud3cLwIpNYYkR0%3Damp;reserved=0
[3]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F66MPXOVY62HCGBDOZGQKMNEE54FG6X6F%2Famp;data=04%7C01%7C%7C21fb97dc59c24afe3c9908da0cce9079%7C84df9e7fe9f640afb435%7C1%7C0%7C637836378581024566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000amp;sdata=hVp2qxt9fS2pA71HvQbZEqpRT26dSLgGk%2FoFLFbSG5I%3Damp;reserved=0

___
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/VI6RFDZDUEOZJ6NCJRKRY6HAQE3CX3M7/

[ovirt-users] Re: No bootable device

[nicolas]

Hi Nir,

El 2022-03-27 10:23, Nir Soffer escribió:

On Wed, Mar 23, 2022 at 3:09 PM  wrote:
We're running oVirt 4.4.8.6. We have uploaded a qcow2 image 
(metasploit

v.3, FWIW)


Is it Metasploitable3-0.1.4.ova from the github releases page?
https://github.com/brimstone/metasploitable3/releases



Actually, the disk has been shared with us by one of our professors. It 
has been provided in qcow2, vmdk and raw formats, still the result was 
the same. I don't actually know which exact version is it, I just know 
the version is "3".


If not, can you share the image? It will help if we can reproduce this 
problem

locally with the same image you are using.


I will provide the link off-list because it belongs to the professor.



using the GUI (Storage -> Disks -> Upload -> Start). The
image is in qcow2 format.


Did you convert the vmdk file from the ova to qcow2?


Yes, I also tried these steps with the same result.




No options on the right side were checked. The
upload went smoothly, so we now tried to attach the disk to a VM.

To do that, we opened the VM -> Disks -> Attach and selected the disk.
As interface, VirtIO-iSCSI was chosen, and the disk was marked as OS, 
so

the "bootable" checkbox was selected.

The VM was later powered on, but when accessing the console the 
message

"No bootable device." appears. We're pretty sure this is a bootable
image, because it was tested on other virtualization infrastructure 
and

it boots well. We also tried to upload the image in RAW format but the
result is the same.

What are we missing here? Is anything else needed to do so the disk is
bootable?


It sounds like you converted an image from another virtualization
system (virtualbox)
to qcow2 format, which may not be good enough to use the virtual 
machine.


oVirt supports importing OVA, but based on the UI, it supports only OVA 
created

by oVirt.

You can try virt-v2v - this is an example command, you need
to fill in the {} parts:

virt-v2v \
-i ova {path-to-ova-file} \
-o rhv-upload \
-oc https://{engine-address}/ovirt-engine/api \
-op {engine-password-file} \
-on {vm-name} \
-os {storrage-domain-name} \
-of qcow2 \
-oo rhv-cafile={engine-ca-file} \
-oo rhv-cluster={cluster-name}

I tried to import the Metasploitable3-0.1.4.ova, and virt-v2 fails
with this error:

virt-v2v: error: inspection could not detect the source guest (or
physical machine).

attached virt-v2v log.



Actually, the professor also provided the OVA from which he extracted 
the disk files and the import process in oVirt worked with no issues. I 
can now boot the VM, not sure what difference made the OVA but now it 
works.


Thanks!

Nicolás


Nir

___
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/INQ4MHEICMNM5MJXEBU6MYR2CDKJSTNF/

[ovirt-users] Re: No bootable device

[nicolas]

El 2022-03-28 13:12, Nir Soffer escribió:

On Mon, Mar 28, 2022 at 11:01 AM  wrote:


Hi Nir,

El 2022-03-27 10:23, Nir Soffer escribió:
> On Wed, Mar 23, 2022 at 3:09 PM  wrote:
>> We're running oVirt 4.4.8.6. We have uploaded a qcow2 image
>> (metasploit
>> v.3, FWIW)
>
> Is it Metasploitable3-0.1.4.ova from the github releases page?
> https://github.com/brimstone/metasploitable3/releases
>

Actually, the disk has been shared with us by one of our professors. 
It

has been provided in qcow2, vmdk and raw formats, still the result was
the same. I don't actually know which exact version is it, I just know
the version is "3".

> If not, can you share the image? It will help if we can reproduce this
> problem
> locally with the same image you are using.

I will provide the link off-list because it belongs to the professor.
>
>> using the GUI (Storage -> Disks -> Upload -> Start). The
>> image is in qcow2 format.
>
> Did you convert the vmdk file from the ova to qcow2?

Yes, I also tried these steps with the same result.

>
>> No options on the right side were checked. The
>> upload went smoothly, so we now tried to attach the disk to a VM.
>>
>> To do that, we opened the VM -> Disks -> Attach and selected the disk.
>> As interface, VirtIO-iSCSI was chosen, and the disk was marked as OS,
>> so
>> the "bootable" checkbox was selected.
>>
>> The VM was later powered on, but when accessing the console the
>> message
>> "No bootable device." appears. We're pretty sure this is a bootable
>> image, because it was tested on other virtualization infrastructure
>> and
>> it boots well. We also tried to upload the image in RAW format but the
>> result is the same.
>>
>> What are we missing here? Is anything else needed to do so the disk is
>> bootable?
>
> It sounds like you converted an image from another virtualization
> system (virtualbox)
> to qcow2 format, which may not be good enough to use the virtual
> machine.
>
> oVirt supports importing OVA, but based on the UI, it supports only OVA
> created
> by oVirt.
>
> You can try virt-v2v - this is an example command, you need
> to fill in the {} parts:
>
> virt-v2v \
> -i ova {path-to-ova-file} \
> -o rhv-upload \
> -oc https://{engine-address}/ovirt-engine/api \
> -op {engine-password-file} \
> -on {vm-name} \
> -os {storrage-domain-name} \
> -of qcow2 \
> -oo rhv-cafile={engine-ca-file} \
> -oo rhv-cluster={cluster-name}
>
> I tried to import the Metasploitable3-0.1.4.ova, and virt-v2 fails
> with this error:
>
> virt-v2v: error: inspection could not detect the source guest (or
> physical machine).
>
> attached virt-v2v log.
>

Actually, the professor also provided the OVA from which he extracted
the disk files and the import process in oVirt worked with no issues. 
I

can now boot the VM, not sure what difference made the OVA but now it
works.


Great that you solved this issue.

For the benefit of the community, can you explain how you imported the 
OVA?


I uploaded the OVA to one of the hosts. Then in the GUI, went to Compute 
> Virtual Machines and chose the '...' icon on the right, and clicked on 'Import'. As the source, I chose "Virtual Appliance (OVA)" and wrote down the path of the OVA I uploaded before. Then I just dragged the VM to the right and clicked ok, the import process went perfectly.


Thanks.

Regards.
___
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/RJC7WG2QXOTOYXPB4Q6Q747TJE62A6LX/

[ovirt-users] [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for

[nicolas]

Hi,

We're running oVirt 4.5.4, recently we had a problem due to /var 
partition being full, and we realized the 
/var/log/ovirt-engine/engine.log was pretty huge, approximately 16GB in 
size, despite it's configured to rotate daily.


Checking the log, we have a lot (about 53000 at the time of this mail) 
of WARN events in this form:


2023-10-17 03:34:51,347+01 WARN  
[org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not 
able to update response for "d6cc2209-3126-48e1-97c8-97ca84d00f3a" result: 
[{"statusTime":"3329996823","status":"Up","vmId":"0fad0aa4-ec91-4beb-82a3-5641f0da674f","vmName":"SYTW-Backend-aluX","vmType":"kvm","kvmEnable":"true","acpiEnable":"true","elapsedTime":"285568","monitorResponse":"0","clientIp":"","timeOffset":"2","cpuUser":"-0.04","cpuSys": 
"0.40","cpuUsage":"1236941000","cpuActual":true,"network":{"vnet3":{"macAddr":"00:1a:4a:4d:cc:d5","name":"vnet3","speed":"1000","state" 
...


This is just a chunk of the full line, which is actually pretty big as 
it contains a lot of parameters. So about 53.000 times this long line 
makes the log huge.


Why are we getting such a big amount of these WARNings and what can we 
do to solve them?


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/LTXCFLALUE53GQ2PVPX5252E4U3JXNCC/

[ovirt-users] Cannot remove template because a disk is based on it

[nicolas]

Hi,

We're running oVirt 4.5. We have a template which we'd like to get rid 
of, there are no VMs based on it. However, trying to remove it oVirt 
states that:


  Cannot remove Template. The following Disk(s) are based on it: 
(b54ee1cb-ed64-4db4-bd3d-eac8b22ea095) .


When opening the 'Disks' subtab in the template, it appears a disk 
(screenshot attached).


However, when opening the oVirt Storage->Disks option, I cannot find the 
disk by the ID, not even ordering the ID column and trying to find it 
visually.


Can anyone point to the problem and a possible solution/workaround?

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/X5DNN4IMTA77RWPLP4KHL62IXYZC23MS/

[ovirt-users] Re: Cannot remove template because a disk is based on it

[nicolas]

Hi Arik,

El 2023-10-01 07:41, Arik Hadas escribió:

On Fri, Sep 29, 2023 at 1:36 PM  wrote:


Hi,

We're running oVirt 4.5. We have a template which we'd like to get
rid
of, there are no VMs based on it. However, trying to remove it oVirt

states that:

Cannot remove Template. The following Disk(s) are based on it:
(b54ee1cb-ed64-4db4-bd3d-eac8b22ea095) .

When opening the 'Disks' subtab in the template, it appears a disk
(screenshot attached).

However, when opening the oVirt Storage->Disks option, I cannot find
the
disk by the ID, not even ordering the ID column and trying to find
it
visually.



Can anyone point to the problem and a possible solution/workaround?


Can you share the output of the following DB queries:
1. select * from base_disks where
disk_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';



engine=# select * from base_disks where 
disk_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
 disk_id | wipe_after_delete | propagate_errors | disk_alias | 
disk_description | shareable | sgio | disk_storage_type | 
cinder_volume_type | disk_content_type | backup | backup_mode

-+---+--++--+---+--+---++---++-
(0 filas)


2. select * from images where
image_group_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';


engine=# select * from images where 
image_group_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
  image_guid  |   creation_date|
size |   it_guid|   parentid 
  | imagestatus |lastmodified|
vm_snapshot_id| volume_type | volume_format |
image_group_id| _create_date  | _update_date 
| active | volume_classification | qcow_compat | sequence_number

--++-+--+--+-++
--+-+---+--+---+--++---+-+-
 987fcd68-d48e-4314-bb4e-363671d222be | 2023-01-16 03:24:35.827+00 | 
26843545600 | bc5c67f5-503e-4482-9628-48fcf70aa055 | 
bc5c67f5-503e-4482-9628-48fcf70aa055 |   1 | 2023-01-16 
03:24:35.827+00 | 67beb3b
2-3e84-4fe8-8334-9c93e8c0fff9 |   2 | 4 | 
b54ee1cb-ed64-4db4-bd3d-eac8b22ea095 | 2023-01-16 03:24:37.054541+00 |   
   | t  | 0 |   0 |  
 0

(1 fila)



3. select * from disk_vm_element where disk_id
='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';



engine=# select * from disk_vm_element where disk_id 
='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
 disk_id | vm_id | is_boot | disk_interface | is_using_scsi_reservation 
| pass_discard

-+---+-++---+--
(0 filas)


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/X5DNN4IMTA77RWPLP4KHL62IXYZC23MS/

___
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/R3HGYT7M5H6JRWK5H5GSGUSIKFQ743RN/

[ovirt-users] Re: Cannot remove template because a disk is based on it

[nicolas]

El 2023-10-03 16:35, Arik Hadas escribió:

On Mon, Oct 2, 2023 at 11:26 AM  wrote:


Hi Arik,

El 2023-10-01 07:41, Arik Hadas escribió:

On Fri, Sep 29, 2023 at 1:36 PM  wrote:


Hi,

We're running oVirt 4.5. We have a template which we'd like to

get

rid
of, there are no VMs based on it. However, trying to remove it

oVirt


states that:

Cannot remove Template. The following Disk(s) are based on it:
(b54ee1cb-ed64-4db4-bd3d-eac8b22ea095) .

When opening the 'Disks' subtab in the template, it appears a

disk

(screenshot attached).

However, when opening the oVirt Storage->Disks option, I cannot

find

the
disk by the ID, not even ordering the ID column and trying to

find

it
visually.



Can anyone point to the problem and a possible

solution/workaround?


Can you share the output of the following DB queries:
1. select * from base_disks where
disk_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';



engine=# select * from base_disks where
disk_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
disk_id | wipe_after_delete | propagate_errors | disk_alias |
disk_description | shareable | sgio | disk_storage_type |
cinder_volume_type | disk_content_type | backup | backup_mode


-+---+--++--+---+--+---++---++-

(0 filas)


2. select * from images where
image_group_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';


engine=# select * from images where
image_group_id='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
image_guid  |   creation_date
|
size |   it_guid|
parentid
| imagestatus |lastmodified|
vm_snapshot_id| volume_type | volume_format |

image_group_id| _create_date  |
_update_date
| active | volume_classification | qcow_compat | sequence_number


--++-+--+--+-++



--+-+---+--+---+--++---+-+-

987fcd68-d48e-4314-bb4e-363671d222be | 2023-01-16 03:24:35.827+00
|
26843545600 | bc5c67f5-503e-4482-9628-48fcf70aa055 |
bc5c67f5-503e-4482-9628-48fcf70aa055 |   1 | 2023-01-16
03:24:35.827+00 | 67beb3b
2-3e84-4fe8-8334-9c93e8c0fff9 |   2 | 4 |
b54ee1cb-ed64-4db4-bd3d-eac8b22ea095 | 2023-01-16 03:24:37.054541+00
|
| t  | 0 |   0 |

0
(1 fila)


3. select * from disk_vm_element where disk_id
='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';



engine=# select * from disk_vm_element where disk_id
='b54ee1cb-ed64-4db4-bd3d-eac8b22ea095';
disk_id | vm_id | is_boot | disk_interface |
is_using_scsi_reservation
| pass_discard


-+---+-++---+--

(0 filas)


I don't think I ever saw this situation of having an image that is not
correlated with a base_disk
I'd suggest to run another query:
select * from images where
parentid='987fcd68-d48e-4314-bb4e-363671d222be';

If it doesn't return any result, take a backup of the database (just
in case) and then remove the image from the database:
delete from images where
image_guid='987fcd68-d48e-4314-bb4e-363671d222be';

This should make it possible to remove the template.


Indeed, that did the trick.

Thanks.




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/X5DNN4IMTA77RWPLP4KHL62IXYZC23MS/

___
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/XB5IMTPLS5NXRAI6Q4F7X5HTAMPE2Y4F/