diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 16:27:09 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 16:27:09 +0000 |
| commit | 4d9e26c0333abd39bdbd039dcdb30ed429c475ba (patch) | |
| tree | 4010d5fb3e8bc48c110a2c1ff2a16b8648cb86bb /results/classifier/accel-gemma3:12b/kvm/1935 | |
| parent | 5541099586dbd6018574cb44e1934907c121526f (diff) | |
| download | qemu-analysis-4d9e26c0333abd39bdbd039dcdb30ed429c475ba.tar.gz qemu-analysis-4d9e26c0333abd39bdbd039dcdb30ed429c475ba.zip | |
add gemma accelerator classification results
Diffstat (limited to 'results/classifier/accel-gemma3:12b/kvm/1935')
| -rw-r--r-- | results/classifier/accel-gemma3:12b/kvm/1935 | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/results/classifier/accel-gemma3:12b/kvm/1935 b/results/classifier/accel-gemma3:12b/kvm/1935 new file mode 100644 index 000000000..f04fb102a --- /dev/null +++ b/results/classifier/accel-gemma3:12b/kvm/1935 @@ -0,0 +1,6 @@ + +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? |