From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org,
"Daniel P . Berrangé" <berrange@redhat.com>,
devel@lists.libvirt.org
Subject: Re: [PATCH v2 6/6] migration: Deprecate fd: for file migration
Date: Mon, 29 Apr 2024 15:47:39 -0300 [thread overview]
Message-ID: <87zftcdn04.fsf@suse.de> (raw)
In-Reply-To: <Zi_puGn7Y1ArcLCL@x1n>
Peter Xu <peterx@redhat.com> writes:
> On Fri, Apr 26, 2024 at 10:14:08AM -0300, Fabiano Rosas wrote:
>> The fd: URI can currently trigger two different types of migration, a
>> TCP migration using sockets and a file migration using a plain
>> file. This is in conflict with the recently introduced (8.2) QMP
>> migrate API that takes structured data as JSON-like format. We cannot
>> keep the same backend for both types of migration because with the new
>> API the code is more tightly coupled to the type of transport. This
>> means a TCP migration must use the 'socket' transport and a file
>> migration must use the 'file' transport.
>>
>> If we keep allowing fd: when using a file, this creates an issue when
>> the user converts the old-style (fd:) to the new style ("transport":
>> "socket") invocation because the file descriptor in question has
>> previously been allowed to be either a plain file or a socket.
>>
>> To avoid creating too much confusion, we can simply deprecate the fd:
>> + file usage, which is thought to be rarely used currently and instead
>> establish a 1:1 correspondence between fd: URI and socket transport,
>> and file: URI and file transport.
>>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>> docs/about/deprecated.rst | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 0fb5c82640..813f7996fe 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -464,3 +464,17 @@ both, older and future versions of QEMU.
>> The ``blacklist`` config file option has been renamed to ``block-rpcs``
>> (to be in sync with the renaming of the corresponding command line
>> option).
>> +
>> +Migration
>> +---------
>> +
>> +``fd:`` URI when used for file migration (since 9.1)
>> +''''''''''''''''''''''''''''''''''''''''''''''''''''
>> +
>> +The ``fd:`` URI can currently provide a file descriptor that
>> +references either a socket or a plain file. These are two different
>> +types of migration. In order to reduce ambiguity, the ``fd:`` URI
>> +usage of providing a file descriptor to a plain file has been
>> +deprecated in favor of explicitly using the ``file:`` URI with the
>> +file descriptor being passed as an ``fdset``. Refer to the ``add-fd``
>> +command documentation for details on the ``fdset`` usage.
>
> Wanna do some warn_report() when detected non-socket fds alongside? Looks
> like we previously do this for all deprecations.
Yes, good point.
>
> What's the plan when it's support removed? I'm imaginging that we sanity
> check fstat() + S_ISSOCK on the fd and fail otherwise? In that case we can
> have the code there, dump warn_report(), then switch to failing qmp migrate
> (and incoming side) later on?
Something along those lines. We currently use fd_is_socket():
bool fd_is_socket(int fd)
{
int optval;
socklen_t optlen = sizeof(optval);
return !getsockopt(fd, SOL_SOCKET, SO_TYPE, &optval, &optlen);
}
I'm thinking of this in fd_start_outgoing_migation():
if (!fd_is_socket(fd)) {
warn_report("fd: migration to a file is deprecated."
" Use file: instead.");
}
next prev parent reply other threads:[~2024-04-29 18:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 13:14 [PATCH v2 0/6] migration removals & deprecations Fabiano Rosas
2024-04-26 13:14 ` [PATCH v2 1/6] migration: Remove 'skipped' field from MigrationStats Fabiano Rosas
2024-04-29 19:50 ` Peter Xu
2024-04-26 13:14 ` [PATCH v2 2/6] migration: Remove 'inc' option from migrate command Fabiano Rosas
2024-04-29 19:51 ` Peter Xu
2024-04-26 13:14 ` [PATCH v2 3/6] migration: Remove 'blk/-b' option from migrate commands Fabiano Rosas
2024-04-29 15:52 ` Peter Xu
2024-04-29 17:18 ` Fabiano Rosas
2024-04-29 18:27 ` Peter Xu
2024-04-29 18:35 ` Fabiano Rosas
2024-04-29 18:53 ` Peter Xu
2024-04-26 13:14 ` [PATCH v2 4/6] migration: Remove block migration Fabiano Rosas
2024-04-26 13:14 ` [PATCH v2 5/6] migration: Remove non-multifd compression Fabiano Rosas
2024-04-29 19:52 ` Peter Xu
2024-04-26 13:14 ` [PATCH v2 6/6] migration: Deprecate fd: for file migration Fabiano Rosas
2024-04-29 18:40 ` Peter Xu
2024-04-29 18:47 ` Fabiano Rosas [this message]
2024-04-29 19:07 ` Peter Xu
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=87zftcdn04.fsf@suse.de \
--to=farosas@suse.de \
--cc=berrange@redhat.com \
--cc=devel@lists.libvirt.org \
--cc=peterx@redhat.com \
--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.