blob: dda7c07e10ade056d7a96585c5a3294b9da09469 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
device: 0.860
ppc: 0.711
graphic: 0.700
risc-v: 0.662
vnc: 0.645
PID: 0.634
socket: 0.600
boot: 0.571
register: 0.548
performance: 0.544
files: 0.521
architecture: 0.508
network: 0.478
VMM: 0.470
debug: 0.468
TCG: 0.377
arm: 0.368
kernel: 0.367
semantic: 0.309
permissions: 0.297
mistranslation: 0.260
i386: 0.204
x86: 0.181
KVM: 0.166
hypervisor: 0.159
peripherals: 0.155
user-level: 0.074
virtual: 0.065
assembly: 0.064
migrate problem when add SCSI reservations with iSCSI backed disks
Description of problem:
When performing migrations with QEMU using iSCSI as the backend, it's common for the migration to start successfully. However, in scenarios where Persistent Reservations are added in the guest, the target host, under the precopy mode, preempts the Persistent Reservations right from the beginning, causing migration issues. Is there a way to control the Persistent Reservations lock within QEMU at an appropriate time, ensuring that it's only preempted during the switchover phase？
Isn't libiscsi thread-safe? Can multiple threads operate on Persistent Reservations lock simultaneously?
|