From 9260319e7411ff8281700a532caa436f40120ec4 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Fri, 30 May 2025 16:52:07 +0200 Subject: gitlab scraper: download in toml and text format --- .../target_missing/host_missing/accel_missing/1935.toml | 17 ----------------- 1 file changed, 17 deletions(-) delete mode 100644 gitlab/issues/target_missing/host_missing/accel_missing/1935.toml (limited to 'gitlab/issues/target_missing/host_missing/accel_missing/1935.toml') diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/1935.toml b/gitlab/issues/target_missing/host_missing/accel_missing/1935.toml deleted file mode 100644 index bab7f317..00000000 --- a/gitlab/issues/target_missing/host_missing/accel_missing/1935.toml +++ /dev/null @@ -1,17 +0,0 @@ -id = 1935 -title = "migrate problem when add SCSI reservations with iSCSI backed disks" -state = "opened" -created_at = "2023-10-13T07:43:12.625Z" -closed_at = "n/a" -labels = ["Migration", "Storage"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1935" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = """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?""" -reproduce = "n/a" -additional = "n/a" -- cgit 1.4.1