qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Anton Kuchin <antonkuchin@yandex-team.ru>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, virtio-fs@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	yc-core@yandex-team.ru
Subject: Re: [PATCH] vhost-user-fs: add capability to allow migration
Date: Mon, 23 Jan 2023 16:56:34 -0500	[thread overview]
Message-ID: <Y88Cknp1XwN8rGHA@fedora> (raw)
In-Reply-To: <20230123155228-mutt-send-email-mst@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

On Mon, Jan 23, 2023 at 04:00:50PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 23, 2023 at 02:49:39PM -0500, Stefan Hajnoczi wrote:
> > The point of the migration blocker is to prevent breaking running
> > guests. Situations where a migration completes but results in a broken
> > guest are problematic for users (especially when they are not logged in
> > to guests and able to fix them interactively).
> 
> I thought it's the reverse - we block when we are sure it can't work.
> If we are not sure we should leave policy to orchestrators.
> 
> You can always get into situations like this with stateful storage (as
> opposed to RO one).  For example, naively scp the backend file then
> start migration. Will seem to work but corrupts the disk (I didn't try,
> for sure with raw but what about qcow2?)

You're right that ultimately QEMU cannot verify that the destination
will 100% work. Who knows if the destination is even a real QEMU or just
a process that throws away the migration stream? :)

> > If a command-line option is set to override the blocker, that's fine.
> > But there needs to be a blocker by default if external knowledge is
> > required to decide whether or not it's safe to migrate.
> 
> If all the command line says is "I want migration to work" then
> that's more like shifting the blame than helping users.
> They just learn this one weird trick and it seems to work
> until it doesn't.  Then we are like "we told you only to set this
> flag if you are sure" and they are like "well I was sure".

What I'm getting at is that this is a breaking change. Previously the
management tool didn't need to be aware of vhost-user-fs migration
support. QEMU would reject migrations. We cannot start allowing them
because management tools may depend on QEMU's migration blocker.

If management tools need to be aware now then the safe way to introduce
this is via a parameter that new management tools must explicitly pass
to QEMU.

Anton's same host migration case is valid but the majority of users
migrate between hosts and that case is not supported yet. Most of the
time vhost-user-fs migration won't work. Let's not break existing
management tools and vhost-user-fs back-ends.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-01-23 21:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-15 17:09 [PATCH] vhost-user-fs: add capability to allow migration Anton Kuchin
2023-01-18 15:52 ` Stefan Hajnoczi
2023-01-19 12:43   ` Anton Kuchin
2023-01-19 14:30     ` Stefan Hajnoczi
2023-01-19 15:29       ` Anton Kuchin
2023-01-19 16:02         ` Stefan Hajnoczi
2023-01-19 16:58           ` Anton Kuchin
2023-01-19 20:40             ` Stefan Hajnoczi
2023-02-01 14:26             ` Juan Quintela
2023-02-02  0:54               ` Anton Kuchin
2023-02-02  9:59                 ` Juan Quintela
2023-02-10 14:09                   ` Anton Kuchin
2023-02-10 16:08                     ` Juan Quintela
2023-02-16 21:00                       ` Stefan Hajnoczi
2023-01-19 12:51 ` Michael S. Tsirkin
2023-01-19 13:45   ` Anton Kuchin
2023-01-19 19:00     ` Dr. David Alan Gilbert
2023-01-19 20:47       ` Anton Kuchin
2023-01-20 13:58     ` Michael S. Tsirkin
2023-01-20 17:37       ` Anton Kuchin
2023-01-22  8:16         ` Michael S. Tsirkin
2023-01-22 12:36           ` Anton Kuchin
2023-01-22 14:46             ` Michael S. Tsirkin
2023-01-22 16:09               ` Anton Kuchin
2023-01-22 16:17                 ` Michael S. Tsirkin
2023-01-23 14:09                   ` Stefan Hajnoczi
2023-01-23 15:52                     ` Anton Kuchin
2023-01-23 19:49                       ` Stefan Hajnoczi
2023-01-23 21:00                         ` Michael S. Tsirkin
2023-01-23 21:56                           ` Stefan Hajnoczi [this message]
2023-01-23 18:27                   ` Dr. David Alan Gilbert
2023-01-23 19:53                     ` Stefan Hajnoczi
2023-01-24  1:46                       ` Stefan Hajnoczi
2023-01-24  9:50                         ` Dr. David Alan Gilbert
2023-01-24 12:48                           ` Stefan Hajnoczi
2023-02-01 14:37                             ` Juan Quintela
2023-01-25 19:46 ` Stefan Hajnoczi
2023-01-26 14:20   ` Anton Kuchin
2023-01-26 15:13     ` Stefan Hajnoczi
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=Y88Cknp1XwN8rGHA@fedora \
    --to=stefanha@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=quintela@redhat.com \
    --cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).