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.
I believe you've hit this bug: https://bugzilla.redhat.c om/show_bug.cgi?id=1565040 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, <nicolas@devels.es> 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-leave@ovirt.org
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': '00000000-0000-0000- 0000-000000000000', '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 <bzlotnik@redhat.com> wrote:
I believe you've hit this bug: https://bugzilla.redhat.c om/show_bug.cgi?id=1565040
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, <nicolas@devels.es> 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-leave@ovirt.org
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': '00000000-0000-0000- 0000-000000000000', '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 <bzlotnik@redhat.com> 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, <nicolas@devels.es> 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-leave@ovirt.org
Links: ------ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
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/ On Thu, 17 May 2018, 13:10 , <nicolas@devels.es> 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': '00000000-0000-0000- 0000-000000000000', '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 <bzlotnik@redhat.com> 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, <nicolas@devels.es> 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-leave@ovirt.org
Links: ------ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
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 <bzlotnik@redhat.com> 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/
On Thu, 17 May 2018, 13:10 , <nicolas@devels.es> 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': '00000000-0000-0000- 0000-000000000000', '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 <bzlotnik@redhat.com> 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, <nicolas@devels.es> 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-leave@ovirt.org
Links: ------ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
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 <bzlotnik@redhat.com> 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 , <nicolas@devels.es> 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.
In the vdsm log you will find the volumeInfo log which looks
El 2018-05-17 10:01, Benny Zlotnik escribió: 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': '00000000-0000-0000- 0000-000000000000', '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 <bzlotnik@redhat.com> 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, <nicolas@devels.es> 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-leave@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/
participants (2)
-
Benny Zlotnik -
nicolas＠devels.es