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 wi
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-0
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', 'descri
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:
Th
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/
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'b401
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
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/d
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 , 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
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
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':
'{"DiskAlia
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
12 matches
Mail list logo
