From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Juan Quintela In-Reply-To: (Stefan Hajnoczi's message of "Tue, 24 Jan 2023 07:48:12 -0500") References: <20230120085534-mutt-send-email-mst@kernel.org> <703d527f-de92-090c-6ce1-af0dec7de033@yandex-team.ru> <20230122030455-mutt-send-email-mst@kernel.org> <20230122093903-mutt-send-email-mst@kernel.org> <70c0f00a-7828-3ccf-c2ea-49aeef8693e9@yandex-team.ru> <20230122111618-mutt-send-email-mst@kernel.org> Reply-To: quintela@redhat.com Date: Wed, 01 Feb 2023 15:37:10 +0100 Message-ID: <87cz6te9k9.fsf@secure.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Virtio-fs] [PATCH] vhost-user-fs: add capability to allow migration List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: "Dr. David Alan Gilbert" , Stefan Hajnoczi , "Michael S. Tsirkin" , Anton Kuchin , qemu-devel , "open list:virtiofs" , Markus Armbruster , Eric Blake , yc-core@yandex-team.ru Stefan Hajnoczi wrote: > On Tue, Jan 24, 2023, 04:50 Dr. David Alan Gilbert > 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.