All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	afaria@redhat.com, qemu-devel@nongnu.org,
	Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h>
Date: Thu, 5 Feb 2026 09:28:44 -0500	[thread overview]
Message-ID: <20260205142844.GB36872@fedora> (raw)
In-Reply-To: <d6cfd9a22c397e3811eaa73409f4ab1499e3e63f.camel@suse.com>

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On Thu, Feb 05, 2026 at 12:52:33PM +0100, Martin Wilck wrote:
> On Wed, 2026-02-04 at 13:32 -0500, Stefan Hajnoczi wrote:
> > On Wed, Feb 04, 2026 at 02:19:48PM +0100, Martin Wilck wrote:
> > Getting back to the application vs DM-Multipath advantages: I think
> > it's
> > worth simplifying things for applications because there are many
> > applications and only one DM-Multipath.
> 
> TBH, I don't see so many applications. Actually I am having trouble
> finding any application at all that uses the generic linux PR
> functionality. I haven't even found a basic command line tool that
> encapsulates the ioctls, are you aware of one? That would be the first
> thing we need, be it only for testing the kernel.

blkpr(8) is part of util-linux:
https://github.com/util-linux/util-linux/blob/master/sys-utils/blkpr.c

> As for applications using SCSI/NVMe PRs, I also don't see many, at
> least not in the Linux / open source realm. Actually, qemu is the only
> one that immediately comes to my mind. I can imagine that storage
> management tools for e.g. OpenStack or Kubernetes would want to use
> PRs, but I don't know any details.

HA/clustering frameworks as well.

> Wrt sockets, not sure what's so painful about them. multipathd recently
> enabled a pathname sockets for qemu-pr-helper in KubeVirt [1].

This is a good example. KubeVirt has code to:
- Create a pr-helper container image with qemu-pr-helper,
  libmpathpersist, and a multipath.conf file.
- Run the pr-helper container with the host's multipathd socket and
  /etc/multipath directory passed through.
- Run a multipath-monitor daemon that remounts the multipathd UNIX
  domain socket bind mount when it changes (multipathd restart?).

And that's just at the KubeVirt level. Libvirt and QEMU also have code
to make this possible.

That is a lot of setup! All of this goes away if QEMU can use
<linux/pr.h> ioctls instead of libmpathpersist. It's just not needed.

Stefan

> 
> Thanks,
> Martin
> 
> [1] https://github.com/opensvc/multipath-tools/issues/111
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      parent reply	other threads:[~2026-02-05 14:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 18:47 Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h> Stefan Hajnoczi
2026-01-27 19:45 ` Paolo Bonzini
2026-01-28 14:18   ` Stefan Hajnoczi
2026-01-28 15:30     ` Hannes Reinecke
2026-01-28 16:13       ` Stefan Hajnoczi
2026-01-27 21:06 ` Benjamin Marzinski
2026-02-03 15:09   ` Stefan Hajnoczi
2026-02-03 17:53     ` Benjamin Marzinski
2026-02-03 18:04       ` Stefan Hajnoczi
2026-02-04 13:19         ` Martin Wilck
2026-02-04 18:32           ` Stefan Hajnoczi
2026-02-04 23:57             ` Hannes Reinecke
2026-02-05  1:03               ` Benjamin Marzinski
2026-02-05 10:20                 ` Martin Wilck
2026-02-05 11:52             ` Martin Wilck
2026-02-05 12:01               ` Daniel P. Berrangé
2026-02-05 13:39                 ` Stefan Hajnoczi
2026-02-06  0:03                   ` Hannes Reinecke
2026-02-06 14:08                     ` Stefan Hajnoczi
2026-02-09 12:50                       ` Hannes Reinecke
2026-02-09 14:23                         ` Stefan Hajnoczi
2026-02-10 10:23                           ` Martin Wilck
2026-02-10 13:59                             ` Stefan Hajnoczi
2026-02-10 14:29                               ` Martin Wilck
2026-02-05 14:28               ` Stefan Hajnoczi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260205142844.GB36872@fedora \
    --to=stefanha@redhat.com \
    --cc=afaria@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=hare@suse.de \
    --cc=kwolf@redhat.com \
    --cc=mpatocka@redhat.com \
    --cc=mwilck@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.