On Thu, Jan 15, 2026 at 06:11:37PM +0100, Paolo Bonzini wrote:
> On 1/13/26 22:53, Stefan Hajnoczi wrote:
> > Live migration does not work for SCSI Persistent Reservations acquired on
> > scsi-block devices. This patch series migrates the reservation key and
> > reservation type so that the destination QEMU can take over the persistent
> > reservation with the PREEMPT service action upon live migration.
> >
> > The approach involves snooping PERSISTENT RESERVE OUT replies and tracking the
> > scsi-block device's current reservation key and reservation type. In most cases
> > this involves no additional SCSI commands. This approach isn't perfect: if
> > another machine modifies the reservation on the physical LUN, then QEMU's state
> > becomes stale. Persistent reservations are inherently cooperative, so this is
> > acceptable as long as real applications don't run into problems.
>
> One issue is that this would not transfer reservations done from a previous
> invocation of the VM. Are you assuming that the restarted VM won't assume
> to still have the reservation? I think this is fine, but it has to be
> documented, or maybe QEMU could issue a PR IN command at startup?
Good point. The reason for this limitation is that I don't see a
reliable way to detect reservation keys and reservations that belong to
a guest. This is why the patch series uses the snooping approach.
The basic READ KEYS and READ RESERVATION service actions for PERSISTENT
RESERVATION IN only report the list of reservation keys that have been
registered and the key of the current reservation holder. There is no
way of tying that information back to the guest or even the host. It
would be necessary to know the guest's unique reservation key, but that
can be chosen by the guest at runtime. In addition, keys are not
guaranteed to be unique so there is no way to tell whether this host is
actually the reservation holder without potentially destructive probing
(e.g. attempting a command and seeing if it results in a RESERVATION
CONFLICT).
The optional READ FULL STATUS service action improves the situation by
identifying the initiator together with the reservation holder's key,
but it is not universally available. The hardware I'm testing on doesn't
implement this service action.
Therefore the assumption is that the guest configures persistent
reservations and if it is shut down, it reclaims the reservation while
starting up again. It also means that an administrator cannot configure
persistent reservations outside the guest and expect live migration to
move those persistent reservations with the guest.
The clean way to handle persistent reservation migration is using Fibre
Channel N_Port ID Virtualization (NPIV) so that each guest is a distinct
initiator that can migrate to another host without messing with the
persistent reservation state. NPIV requires the storage administrator to
set up the initiators and their zoning - something that few users go
through the trouble of doing.
Having said all this, if someone knows about a better way or I'm wrong
about how this works, please let me know!
Stefan