Re: [PATCH v2 4/5] scsi: save/load SCSI reservation state

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jan 27, 2026 at 09:41:59AM -0500, Stefan Hajnoczi wrote:
> On Tue, Jan 27, 2026 at 08:54:24AM +0000, Daniel P. Berrangé wrote:
> > On Mon, Jan 26, 2026 at 05:13:43PM -0500, Stefan Hajnoczi wrote:
> > > On Mon, Jan 26, 2026 at 07:59:55PM +0000, Daniel P. Berrangé wrote:
> > > > On Mon, Jan 26, 2026 at 02:47:34PM -0500, Stefan Hajnoczi wrote:
> > > > > Add a vmstate subsection to SCSIDiskState so that scsi-block devices can
> > > > > transfer their reservation state during live migration. Upon loading the
> > > > > subsection, the destination QEMU invokes the PERSISTENT RESERVE OUT
> > > > > command's PREEMPT service action to atomically move the reservation from
> > > > > the source I_T nexus to the destination I_T nexus. This results in
> > > > > transparent live migration of SCSI reservations.
> > > > > 
> > > > > This approach is incomplete since SCSI reservations are cooperative and
> > > > > other hosts could interfere. Neither the source QEMU nor the destination
> > > > > QEMU are aware of changes made by other hosts. The assumption is that
> > > > > reservation is not taken over by a third host without cooperation from
> > > > > the source host.
> > > > > 
> > > > > I considered adding the vmstate subsection to SCSIDevice instead of
> > > > > SCSIDiskState, since reservations are part of the SCSI Primary Commands
> > > > > that other devices apart from disks could support. However, due to
> > > > > fragility of migrating reservations, we will probably limit support to
> > > > > scsi-block and maybe scsi-disk in the future. In the end, I think it
> > > > > makes sense to place this within scsi-disk.c.
> > > > > 
> > > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > > > ---
> > > > >  include/hw/scsi/scsi.h |  1 +
> > > > >  hw/core/machine.c      |  4 ++-
> > > > >  hw/scsi/scsi-disk.c    | 81 ++++++++++++++++++++++++++++++++++++++++-
> > > > >  hw/scsi/scsi-generic.c | 82 ++++++++++++++++++++++++++++++++++++++++++
> > > > >  hw/scsi/trace-events   |  1 +
> > > > >  5 files changed, 167 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
> > > > > index c5ec58089b..a3e246dbd9 100644
> > > > > --- a/include/hw/scsi/scsi.h
> > > > > +++ b/include/hw/scsi/scsi.h
> > > > > @@ -253,6 +253,7 @@ SCSIDevice *scsi_device_get(SCSIBus *bus, int channel, int target, int lun);
> > > > >  
> > > > >  /* scsi-generic.c. */
> > > > >  extern const SCSIReqOps scsi_generic_req_ops;
> > > > > +bool scsi_generic_pr_state_preempt(SCSIDevice *s, Error **errp);
> > > > >  
> > > > >  /* scsi-disk.c */
> > > > >  #define SCSI_DISK_QUIRK_MODE_PAGE_APPLE_VENDOR             0
> > > > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > > > index 6411e68856..16134f8ce5 100644
> > > > > --- a/hw/core/machine.c
> > > > > +++ b/hw/core/machine.c
> > > > > @@ -38,7 +38,9 @@
> > > > >  #include "hw/acpi/generic_event_device.h"
> > > > >  #include "qemu/audio.h"
> > > > >  
> > > > > -GlobalProperty hw_compat_10_2[] = {};
> > > > > +GlobalProperty hw_compat_10_2[] = {
> > > > > +    { "scsi-block", "migrate-pr", "off" },
> > > > > +};
> > > > >  const size_t hw_compat_10_2_len = G_N_ELEMENTS(hw_compat_10_2);
> > > > >  
> > > > >  GlobalProperty hw_compat_10_1[] = {
> > > > > diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> > > > > index 76fe5f085b..8845ab1192 100644
> > > > > --- a/hw/scsi/scsi-disk.c
> > > > > +++ b/hw/scsi/scsi-disk.c
> > > > > @@ -28,6 +28,7 @@
> > > > >  #include "qemu/hw-version.h"
> > > > >  #include "qemu/memalign.h"
> > > > >  #include "hw/scsi/scsi.h"
> > > > > +#include "migration/misc.h"
> > > > >  #include "migration/qemu-file-types.h"
> > > > >  #include "migration/vmstate.h"
> > > > >  #include "hw/scsi/emulation.h"
> > > > > @@ -122,6 +123,7 @@ struct SCSIDiskState {
> > > > >       */
> > > > >      uint16_t rotation_rate;
> > > > >      bool migrate_emulated_scsi_request;
> > > > > +    NotifierWithReturn migration_notifier;
> > > > >  };
> > > > >  
> > > > >  static void scsi_free_request(SCSIRequest *req)
> > > > > @@ -2737,6 +2739,25 @@ static SCSIRequest *scsi_new_request(SCSIDevice *d, uint32_t tag, uint32_t lun,
> > > > >  }
> > > > >  
> > > > >  #ifdef __linux__
> > > > > +/*
> > > > > + * Preempt on the SCSI Persistent Reservation on the source when migration
> > > > > + * fails because the destination may have already preempted and we need to get
> > > > > + * the reservation back.
> > > > > + */
> > > > > +static int scsi_block_migration_notifier(NotifierWithReturn *notifier,
> > > > > +                                         MigrationEvent *e, Error **errp)
> > > > > +{
> > > > > +    if (e->type == MIG_EVENT_PRECOPY_FAILED) {
> > > > > +        SCSIDiskState *s =
> > > > > +            container_of(notifier, SCSIDiskState, migration_notifier);
> > > > > +        SCSIDevice *d = &s->qdev;
> > > > > +
> > > > > +        /* MIG_EVENT_PRECOPY_FAILED cannot fail, so ignore errors */
> > > > > +        scsi_generic_pr_state_preempt(d, NULL);
> > > > 
> > > > I feel like we ought to 'warn_report'  any errors related to failing
> > > > to acquire persistent reservations.
> > > > 
> > > > In the unlikely event an error occurs, whomever has to deal with
> > > > the resulting support ticket will want to know something went wrong
> > > > from the QEMU logs.
> > > 
> > > Good idea.
> > > 
> > > I'm also not sure how to best approach logging in general. Usually QEMU
> > > does little logging when the VM is running, but it has become
> > > increasingly difficult to get information out of QEMU via tracing or
> > > monitor commands since nowadays QEMU might be running in a locked down
> > > container. Debugging PR migration issues would be easiest if the trace
> > > events introduced in this series were actually printfs to stderr, but
> > > that's not traditionally how QEMU did things.
> > 
> > I wouldn't overthink this - just pass a locall "Error *err" object
> > instead of NULL, and then warn_report_err on the result. Just needs
> > to be a marker in the that something has gone wrong, which we could
> > not propagate to the mgmt app in the normal manner since we have no
> > error path here.
> 
> Yes, sounds good.
> 
> > 
> > Debugging /anything/ in QEMU is easiest if the trace events were
> > actually prints, but that thinking leads to us enabling tracing
> > all the time, everywhere which is impractical
> > 
> > At the same time it is common for apps to have some level of
> > "always on" debugging collected and so we perhaps do have a
> > general conceptual gap in QEMU.
> > 
> > If we thinking of trace events as being equiv to "DEBUG" level
> > log events, would it help if we could annotate a subset of
> > trace events as "INFO" level and do something with them by
> > default. eg perhaps we have an ring buffer tracing target that
> > collects "INFO" events continuously and can be asked to dump
> > out its state in error scenarios ?
> 
> I need to research SystemTap inside container scenarios more first.
> Ideally we could rely on the DTrace probes, but it needs to be easy for
> users to collect information from their containers. I suspect there will
> be permission problems as well as multiple steps required to just find
> the container where QEMU is running, which makes this hard for users.

Agreed, I'd expect to use systemtap with a containerized QEMU would
generally involve an account outside the container on the host OS.
While it might be possible to open up the kernel / seccomp perms
in just the right way to get things working inside the container,
that's unlikely to be permitted in any public cloud solution, and
probably also blocked in many other places. I think this pushes
towards the need for a more traditional "logging" like facility.

We do have the "log" backend already of course but not neccessarily
enabled by distros, but that's something they need to consider.

An always-on ring buffer would be more like a "flight recorder"
scenario to reduce the overheads compared to actually logging to
disk / external service until a failure scenario arrives.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|