All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Anton Kuchin <antonkuchin@yandex-team.ru>
Cc: qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	yc-core@yandex-team.ru, "Stefan Hajnoczi" <stefanha@redhat.com>,
	virtio-fs@redhat.com, "Eric Blake" <eblake@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v2 1/1] vhost-user-fs: add property to allow migration
Date: Thu, 16 Feb 2023 15:14:05 +0100	[thread overview]
Message-ID: <87v8k1itoy.fsf@secure.mitica> (raw)
In-Reply-To: <20230216140003.1103681-2-antonkuchin@yandex-team.ru> (Anton Kuchin's message of "Thu, 16 Feb 2023 16:00:03 +0200")

Anton Kuchin <antonkuchin@yandex-team.ru> wrote:
> Now any vhost-user-fs device makes VM unmigratable, that also prevents
> qemu update without stopping the VM. In most cases that makes sense
> because qemu has no way to transfer FUSE session state.
>
> But it is good to have an option for orchestrator to tune this according to
> backend capabilities and migration configuration.
>
> This patch adds device property 'migration' that is 'none' by default
> to keep old behaviour but can be set to 'external' to explicitly allow
> migration with minimal virtio device state in migration stream if daemon
> has some way to sync FUSE state on src and dst without help from qemu.
>
> Signed-off-by: Anton Kuchin <antonkuchin@yandex-team.ru>

Reviewed-by: Juan Quintela <quintela@redhat.com>

The migration bits are correct.

And I can think a better way to explain that one device is migrated
externally.

If you have to respin:

> +static int vhost_user_fs_pre_save(void *opaque)
> +{
> +    VHostUserFS *fs = (VHostUserFS *)opaque;

This hack is useless.
I know that there are still lots of code that still have it.


Now remember that I have no clue about vhost-user-fs.

But this looks fishy
>  static const VMStateDescription vuf_vmstate = {
>      .name = "vhost-user-fs",
> -    .unmigratable = 1,
> +    .minimum_version_id = 0,
> +    .version_id = 0,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_VIRTIO_DEVICE,
> +        VMSTATE_UINT8(migration_type, VHostUserFS),
> +        VMSTATE_END_OF_LIST()
> +    },
> +   .pre_save = vhost_user_fs_pre_save,
>  };
>  
>  static Property vuf_properties[] = {
> @@ -309,6 +337,10 @@ static Property vuf_properties[] = {
>      DEFINE_PROP_UINT16("num-request-queues", VHostUserFS,
>                         conf.num_request_queues, 1),
>      DEFINE_PROP_UINT16("queue-size", VHostUserFS, conf.queue_size, 128),
> +    DEFINE_PROP_UNSIGNED("migration", VHostUserFS, migration_type,
> +                         VHOST_USER_MIGRATION_TYPE_NONE,
> +                         qdev_prop_vhost_user_migration_type,
> +                         uint8_t),
>      DEFINE_PROP_END_OF_LIST(),

We have four properties here (5 with the new migration one), and you
only migrate one.

This looks fishy, but I don't know if it makes sense.
If they _have_ to be configured the same on source and destination, I
would transfer them and check in post_load that the values are correct.

Later, Juan.


WARNING: multiple messages have this Message-ID (diff)
From: Juan Quintela <quintela@redhat.com>
To: Anton Kuchin <antonkuchin@yandex-team.ru>
Cc: qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	yc-core@yandex-team.ru, "Stefan Hajnoczi" <stefanha@redhat.com>,
	virtio-fs@redhat.com, "Eric Blake" <eblake@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v2 1/1] vhost-user-fs: add property to allow migration
Date: Thu, 16 Feb 2023 15:14:05 +0100	[thread overview]
Message-ID: <87v8k1itoy.fsf@secure.mitica> (raw)
In-Reply-To: <20230216140003.1103681-2-antonkuchin@yandex-team.ru> (Anton Kuchin's message of "Thu, 16 Feb 2023 16:00:03 +0200")

Anton Kuchin <antonkuchin@yandex-team.ru> wrote:
> Now any vhost-user-fs device makes VM unmigratable, that also prevents
> qemu update without stopping the VM. In most cases that makes sense
> because qemu has no way to transfer FUSE session state.
>
> But it is good to have an option for orchestrator to tune this according to
> backend capabilities and migration configuration.
>
> This patch adds device property 'migration' that is 'none' by default
> to keep old behaviour but can be set to 'external' to explicitly allow
> migration with minimal virtio device state in migration stream if daemon
> has some way to sync FUSE state on src and dst without help from qemu.
>
> Signed-off-by: Anton Kuchin <antonkuchin@yandex-team.ru>

Reviewed-by: Juan Quintela <quintela@redhat.com>

The migration bits are correct.

And I can think a better way to explain that one device is migrated
externally.

If you have to respin:

> +static int vhost_user_fs_pre_save(void *opaque)
> +{
> +    VHostUserFS *fs = (VHostUserFS *)opaque;

This hack is useless.
I know that there are still lots of code that still have it.


Now remember that I have no clue about vhost-user-fs.

But this looks fishy
>  static const VMStateDescription vuf_vmstate = {
>      .name = "vhost-user-fs",
> -    .unmigratable = 1,
> +    .minimum_version_id = 0,
> +    .version_id = 0,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_VIRTIO_DEVICE,
> +        VMSTATE_UINT8(migration_type, VHostUserFS),
> +        VMSTATE_END_OF_LIST()
> +    },
> +   .pre_save = vhost_user_fs_pre_save,
>  };
>  
>  static Property vuf_properties[] = {
> @@ -309,6 +337,10 @@ static Property vuf_properties[] = {
>      DEFINE_PROP_UINT16("num-request-queues", VHostUserFS,
>                         conf.num_request_queues, 1),
>      DEFINE_PROP_UINT16("queue-size", VHostUserFS, conf.queue_size, 128),
> +    DEFINE_PROP_UNSIGNED("migration", VHostUserFS, migration_type,
> +                         VHOST_USER_MIGRATION_TYPE_NONE,
> +                         qdev_prop_vhost_user_migration_type,
> +                         uint8_t),
>      DEFINE_PROP_END_OF_LIST(),

We have four properties here (5 with the new migration one), and you
only migrate one.

This looks fishy, but I don't know if it makes sense.
If they _have_ to be configured the same on source and destination, I
would transfer them and check in post_load that the values are correct.

Later, Juan.



  reply	other threads:[~2023-02-16 14:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 14:00 [Virtio-fs] [PATCH v2 0/1] virtio-fs: implement option for stateless migration Anton Kuchin
2023-02-16 14:00 ` Anton Kuchin
2023-02-16 14:00 ` [Virtio-fs] [PATCH v2 1/1] vhost-user-fs: add property to allow migration Anton Kuchin
2023-02-16 14:00   ` Anton Kuchin
2023-02-16 14:14   ` Juan Quintela [this message]
2023-02-16 14:14     ` Juan Quintela
2023-02-16 16:11     ` [Virtio-fs] " Michael S. Tsirkin
2023-02-16 16:11       ` Michael S. Tsirkin
2023-02-16 16:13       ` [Virtio-fs] " Michael S. Tsirkin
2023-02-16 16:13         ` Michael S. Tsirkin
2023-02-16 16:22         ` [Virtio-fs] " Juan Quintela
2023-02-16 16:22           ` Juan Quintela
2023-02-16 23:33           ` Anton Kuchin
2023-02-16 23:39           ` [Virtio-fs] " Anton Kuchin
2023-02-16 23:39             ` Anton Kuchin
2023-02-16 16:17       ` [Virtio-fs] " Juan Quintela
2023-02-16 16:17         ` Juan Quintela
2023-02-16 21:09   ` [Virtio-fs] " Stefan Hajnoczi
2023-02-16 21:09     ` Stefan Hajnoczi
2023-02-16 23:14     ` [Virtio-fs] " Anton Kuchin
2023-02-16 23:14       ` 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=87v8k1itoy.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=antonkuchin@yandex-team.ru \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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.