From: Juan Quintela <quintela@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Anton Kuchin <antonkuchin@yandex-team.ru>,
qemu-devel <qemu-devel@nongnu.org>,
"open list:virtiofs" <virtio-fs@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Eric Blake <eblake@redhat.com>,
yc-core@yandex-team.ru
Subject: Re: [Virtio-fs] [PATCH] vhost-user-fs: add capability to allow migration
Date: Wed, 01 Feb 2023 15:37:10 +0100 [thread overview]
Message-ID: <87cz6te9k9.fsf@secure.mitica> (raw)
In-Reply-To: <CAJSP0QUANuLkOjkLsB4LqKdi5_sJj+y6zK5vgcNmYZ5BLQ73rQ@mail.gmail.com> (Stefan Hajnoczi's message of "Tue, 24 Jan 2023 07:48:12 -0500")
Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Tue, Jan 24, 2023, 04:50 Dr. David Alan Gilbert <dgilbert@redhat.com>
> wrote:
[...]
>> > I checked how bad the situation is. libvhost-user currently enables
>> > LOG_ALL by default. :(
>> >
>> > So I don't think the front-end can use LOG_ALL alone to determine
>> > whether or not migration is supported by the back-end.
>> >
>> > There are several existing back-ends based on libvhost-user that have
>> > no concept of reconnection or migration but report the LOG_ALL feature
>> > bit.
>>
>> Ouch, yes that's messy.
>>
>> Going back to the original question; I don't think a command line flag
>> will work though, because even for a given VM there's the possibility
>> of some (local) migrations working but other (remote) migrations not
>> working; so you don't know at the point you start the VM whether
>> your migrations are going to work.
>>
>
> The user or management tool should know which types of migration a
> vhost-user-fs backend supports. That can be passed in as a per-device
> parameter.
>
> Then a migration parameter can be used to distinguish between same host and
> remote host migration? QEMU already distinguishes between pre-copy and
> post-copy migration, so this can be thought of as yet another type of
> migration.
I was going to suggest this (my previous answer was after reading only
the other part of the comments).
What we have here is that this device has "three" states:
- You can't migrate it to other host (now and the default behaviour)
- You can migrate some of the backends if you are migrating in the same
host (note, we don't know directly that we are migrating inside the
same host, so I would agree to add _that_ migration capability, that
is related to migration, and it makes sense for migration code and
devices to know that is happening)
- In the future, perhaps, you can migrate "always" some vhost-use-fs,
that would be a property on my opinion.
Later, Juan.
WARNING: multiple messages have this Message-ID (diff)
From: Juan Quintela <quintela@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Anton Kuchin <antonkuchin@yandex-team.ru>,
qemu-devel <qemu-devel@nongnu.org>,
"open list:virtiofs" <virtio-fs@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Eric Blake <eblake@redhat.com>,
yc-core@yandex-team.ru
Subject: Re: [PATCH] vhost-user-fs: add capability to allow migration
Date: Wed, 01 Feb 2023 15:37:10 +0100 [thread overview]
Message-ID: <87cz6te9k9.fsf@secure.mitica> (raw)
In-Reply-To: <CAJSP0QUANuLkOjkLsB4LqKdi5_sJj+y6zK5vgcNmYZ5BLQ73rQ@mail.gmail.com> (Stefan Hajnoczi's message of "Tue, 24 Jan 2023 07:48:12 -0500")
Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Tue, Jan 24, 2023, 04:50 Dr. David Alan Gilbert <dgilbert@redhat.com>
> wrote:
[...]
>> > I checked how bad the situation is. libvhost-user currently enables
>> > LOG_ALL by default. :(
>> >
>> > So I don't think the front-end can use LOG_ALL alone to determine
>> > whether or not migration is supported by the back-end.
>> >
>> > There are several existing back-ends based on libvhost-user that have
>> > no concept of reconnection or migration but report the LOG_ALL feature
>> > bit.
>>
>> Ouch, yes that's messy.
>>
>> Going back to the original question; I don't think a command line flag
>> will work though, because even for a given VM there's the possibility
>> of some (local) migrations working but other (remote) migrations not
>> working; so you don't know at the point you start the VM whether
>> your migrations are going to work.
>>
>
> The user or management tool should know which types of migration a
> vhost-user-fs backend supports. That can be passed in as a per-device
> parameter.
>
> Then a migration parameter can be used to distinguish between same host and
> remote host migration? QEMU already distinguishes between pre-copy and
> post-copy migration, so this can be thought of as yet another type of
> migration.
I was going to suggest this (my previous answer was after reading only
the other part of the comments).
What we have here is that this device has "three" states:
- You can't migrate it to other host (now and the default behaviour)
- You can migrate some of the backends if you are migrating in the same
host (note, we don't know directly that we are migrating inside the
same host, so I would agree to add _that_ migration capability, that
is related to migration, and it makes sense for migration code and
devices to know that is happening)
- In the future, perhaps, you can migrate "always" some vhost-use-fs,
that would be a property on my opinion.
Later, Juan.
next prev parent reply other threads:[~2023-02-01 14:37 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 17:09 [Virtio-fs] [PATCH] vhost-user-fs: add capability to allow migration Anton Kuchin
2023-01-15 17:09 ` Anton Kuchin
2023-01-18 15:52 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-18 15:52 ` Stefan Hajnoczi
2023-01-19 12:43 ` [Virtio-fs] " Anton Kuchin
2023-01-19 12:43 ` Anton Kuchin
2023-01-19 14:30 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-19 14:30 ` Stefan Hajnoczi
2023-01-19 15:29 ` [Virtio-fs] " Anton Kuchin
2023-01-19 15:29 ` Anton Kuchin
2023-01-19 16:02 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-19 16:02 ` Stefan Hajnoczi
2023-01-19 16:58 ` [Virtio-fs] " Anton Kuchin
2023-01-19 16:58 ` Anton Kuchin
2023-01-19 20:40 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-19 20:40 ` Stefan Hajnoczi
2023-02-01 14:26 ` [Virtio-fs] " Juan Quintela
2023-02-01 14:26 ` Juan Quintela
2023-02-02 0:54 ` [Virtio-fs] " Anton Kuchin
2023-02-02 0:54 ` Anton Kuchin
2023-02-02 9:59 ` [Virtio-fs] " Juan Quintela
2023-02-02 9:59 ` Juan Quintela
2023-02-10 14:09 ` [Virtio-fs] " Anton Kuchin
2023-02-10 14:09 ` Anton Kuchin
2023-02-10 16:08 ` [Virtio-fs] " Juan Quintela
2023-02-10 16:08 ` Juan Quintela
2023-02-16 21:00 ` [Virtio-fs] " Stefan Hajnoczi
2023-02-16 21:00 ` Stefan Hajnoczi
2023-01-19 12:51 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-19 12:51 ` Michael S. Tsirkin
2023-01-19 13:45 ` [Virtio-fs] " Anton Kuchin
2023-01-19 13:45 ` Anton Kuchin
2023-01-19 19:00 ` [Virtio-fs] " Dr. David Alan Gilbert
2023-01-19 19:00 ` Dr. David Alan Gilbert
2023-01-19 20:47 ` [Virtio-fs] " Anton Kuchin
2023-01-19 20:47 ` Anton Kuchin
2023-01-20 13:58 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-20 13:58 ` Michael S. Tsirkin
2023-01-20 17:37 ` [Virtio-fs] " Anton Kuchin
2023-01-20 17:37 ` Anton Kuchin
2023-01-22 8:16 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-22 8:16 ` Michael S. Tsirkin
2023-01-22 12:36 ` [Virtio-fs] " Anton Kuchin
2023-01-22 12:36 ` Anton Kuchin
2023-01-22 14:46 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-22 14:46 ` Michael S. Tsirkin
2023-01-22 16:09 ` [Virtio-fs] " Anton Kuchin
2023-01-22 16:09 ` Anton Kuchin
2023-01-22 16:17 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-22 16:17 ` Michael S. Tsirkin
2023-01-23 14:09 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-23 14:09 ` Stefan Hajnoczi
2023-01-23 15:52 ` [Virtio-fs] " Anton Kuchin
2023-01-23 15:52 ` Anton Kuchin
2023-01-23 19:49 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-23 19:49 ` Stefan Hajnoczi
2023-01-23 21:00 ` [Virtio-fs] " Michael S. Tsirkin
2023-01-23 21:00 ` Michael S. Tsirkin
2023-01-23 21:56 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-23 21:56 ` Stefan Hajnoczi
2023-01-23 18:27 ` [Virtio-fs] " Dr. David Alan Gilbert
2023-01-23 18:27 ` Dr. David Alan Gilbert
2023-01-23 19:53 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-23 19:53 ` Stefan Hajnoczi
2023-01-24 1:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-24 1:46 ` Stefan Hajnoczi
2023-01-24 9:50 ` [Virtio-fs] " Dr. David Alan Gilbert
2023-01-24 9:50 ` Dr. David Alan Gilbert
2023-01-24 12:48 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-24 12:48 ` Stefan Hajnoczi
2023-02-01 14:37 ` Juan Quintela [this message]
2023-02-01 14:37 ` Juan Quintela
2023-01-25 19:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-25 19:46 ` Stefan Hajnoczi
2023-01-26 14:20 ` [Virtio-fs] " Anton Kuchin
2023-01-26 14:20 ` Anton Kuchin
2023-01-26 15:13 ` [Virtio-fs] " Stefan Hajnoczi
2023-01-26 15:13 ` Stefan Hajnoczi
2023-01-26 15:21 ` [Virtio-fs] " Anton Kuchin
2023-01-26 15:21 ` Anton Kuchin
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=87cz6te9k9.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=antonkuchin@yandex-team.ru \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
--cc=yc-core@yandex-team.ru \
/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.