From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 23 Jan 2023 14:53:35 -0500 From: Stefan Hajnoczi Message-ID: References: <20230119074602-mutt-send-email-mst@kernel.org> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QdF4bo3qnNvnWMS/" Content-Disposition: inline In-Reply-To: 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: "Dr. David Alan Gilbert" Cc: "Michael S. Tsirkin" , Anton Kuchin , qemu-devel@nongnu.org, virtio-fs@redhat.com, Markus Armbruster , Eric Blake , Juan Quintela , yc-core@yandex-team.ru --QdF4bo3qnNvnWMS/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2023 at 06:27:23PM +0000, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (mst@redhat.com) wrote: > > On Sun, Jan 22, 2023 at 06:09:40PM +0200, Anton Kuchin wrote: > > >=20 > > > On 22/01/2023 16:46, Michael S. Tsirkin wrote: > > > > On Sun, Jan 22, 2023 at 02:36:04PM +0200, Anton Kuchin wrote: > > > > > > > This flag should be set when qemu don't need to worry about a= ny > > > > > > > external state stored in vhost-user daemons during migration: > > > > > > > don't fail migration, just pack generic virtio device states = to > > > > > > > migration stream and orchestrator guarantees that the rest of= the > > > > > > > state will be present at the destination to restore full cont= ext and > > > > > > > continue running. > > > > > > Sorry I still do not get it. So fundamentally, why do we need= this property? > > > > > > vhost-user-fs is not created by default that we'd then need opt= -in to > > > > > > the special "migrateable" case. > > > > > > That's why I said it might make some sense as a device property= as qemu > > > > > > tracks whether device is unplugged for us. > > > > > >=20 > > > > > > But as written, if you are going to teach the orchestrator about > > > > > > vhost-user-fs and its special needs, just teach it when to migr= ate and > > > > > > where not to migrate. > > > > > >=20 > > > > > > Either we describe the special situation to qemu and let qemu > > > > > > make an intelligent decision whether to allow migration, > > > > > > or we trust the orchestrator. And if it's the latter, then 'mig= rate' > > > > > > already says orchestrator decided to migrate. > > > > > The problem I'm trying to solve is that most of vhost-user devices > > > > > now block migration in qemu. And this makes sense since qemu can't > > > > > extract and transfer backend daemon state. But this prevents us f= rom > > > > > updating qemu executable via local migration. So this flag is > > > > > intended more as a safety check that says "I know what I'm doing". > > > > >=20 > > > > > I agree that it is not really necessary if we trust the orchestra= tor > > > > > to request migration only when the migration can be performed in a > > > > > safe way. But changing the current behavior of vhost-user-fs from > > > > > "always blocks migration" to "migrates partial state whenever > > > > > orchestrator requests it" seems a little=A0 dangerous and can be > > > > > misinterpreted as full support for migration in all cases. > > > > It's not really different from block is it? orchestrator has to arr= ange > > > > for backend migration. I think we just assumed there's no use-case = where > > > > this is practical for vhost-user-fs so we blocked it. > > > > But in any case it's orchestrator's responsibility. > > >=20 > > > Yes, you are right. So do you think we should just drop the blocker > > > without adding a new flag? > >=20 > > I'd be inclined to. I am curious what do dgilbert and stefanha think th= ough. >=20 > Yes I think that's probably OK, as long as we use the flag for knowing > how to handle the discard bitmap as a proxy for the daemon knowing how > to handle *some* migrations; knowing which migrations is then the job > for the orchestrator to be careful of. I think the feature bit is not a good way to detect live migration support. vhost-user backends typically use libvhost-user, rust-vmm's vhost-user-backend crate, etc where this feature can be implemented for free. If the feature bit is advertized we don't know if the device implementation (net, blk, fs, etc) is aware of migration at all. Stefan --QdF4bo3qnNvnWMS/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmPO5b8ACgkQnKSrs4Gr c8h3PggAibx2DqNveEjS7LgSZ4Ms8/+3Q/sxtdmCADNlgDZ+INE5Q8QqtfRxh5OG 7nCaJvqdJ1qV97hYtTZlbfL7diEvFRykYO+3Re46wmXlOQLjC4NX3pWBbbCLl2g6 4DITO8gVKmU8L/V2BagPdzA8PFsY4Ki4y4m5L/4cHUsiC748pxoRh4v4bXNKAk7u +fOFuOT4wfyYqT8N0ocV8uIUutOCaDeBUMxrNU2FYrSzVdZu8509HzAokIZsQXrt h5Yu9GcUkfmEkZD+UU2yMJ01Tc+jEEFECsDEhVPLlZ7e9mH8TycPBPEnbC+YuioA DOlw3/lnYrgv9gA2Fbizi46S0ar2qg== =2YF9 -----END PGP SIGNATURE----- --QdF4bo3qnNvnWMS/--