Open maxcuttins opened 7 years ago
3 VDI
I got this after a xe sr-scan on the Ceph Storage:
`There was an SR backend failure.
status: non-zero exit
stdout:
stderr: Traceback (most recent call last):
File "/opt/xensource/sm/RBDSR", line 774, in
[root@xenserver-11 archive]# xe sr-scan uuid=51a45fd8-a4d1-4202-899c-00a0f81054cc
Broadcast message from systemd-journald@xenserver-11 (Sun 2017-06-25 05:34:16 CEST):
tapdisk[4632]: tapdisk-syslog: 1 messages dropped
Broadcast message from systemd-journald@xenserver-11 (Sun 2017-06-25 05:34:16 CEST):
tapdisk[4632]: tapdisk-syslog: 3 messages dropped
Broadcast message from systemd-journald@xenserver-11 (Sun 2017-06-25 05:34:16 CEST):
tapdisk[4632]: tapdisk-syslog: 1 messages dropped `
Hi, Could you please run xe sr-scan again and send me the files /var/log/SMlog and /var/log/xensource.log Thanks
The reason of this error is that for some operations (resize, update, snapshot, clone etc.) it is required to unmap rbd-nbd device, execute operation, and mount again. If at the certain moment only one unmap/map operation is executed you don't have problem. But if several Vdi is mapped simultaneously, then the rbd-nbd device that was unmapped previously (for resize, update operation etc.) may be mapped again with other device instance number that differs the number that it had before unmap. As result the Vdi can't be unpaused after operation and we have error mentioned above.
Last update should fix this problem.
I don't know if it's a good way to fix the issue. Thinking about it probably the best way is to stop using cache in order to expect some results that are unattended by system. Probably it's better to create a function that runned retrieve automatically the nbd-device everytime we need to issue a new command. Having no-cache probably means less speed but up-to-date data and references. Probably a simple function that parse the UUID of the VDI on the fly and retrieve the right NBD-device should be a really thin and light piece of function.
Hi, It's not a cache. The registry just track the attached vdi and store the reference to nbd device corresponding to the attached vdi. On vdi attach the reference is created and on vdi detach the reference is deleted. Also the registry is cleared if SR is detached. So the registry should always have an actual info about attached vdis, i hope.
a workaround is to detach, rename the UUID of the rbd image, then set :uuid with image-meta set ... rescan and attach. Boot then works... it seems if the unmap is interrupted or anything other does not unlock -> with renaming its fixed without rebooting / re attaching the whole SR
for v2.0 rbd nbd i created a patch to use the names instead of /dev/nbdXX numbers: https://github.com/rposudnevskiy/RBDSR/pull/79
I have an issue with one VDI. Suddenly stop and show: