qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anton Kuchin <antonkuchin@yandex-team.ru>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@yandex-team.ru>,
	qemu-devel@nongnu.org, yc-core@yandex-team.ru,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Juan Quintela" <quintela@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	virtio-fs@redhat.com, "Eric Blake" <eblake@redhat.com>
Subject: Re: [PATCH v3 1/1] vhost-user-fs: add migration type property
Date: Tue, 28 Feb 2023 09:57:50 -0500	[thread overview]
Message-ID: <20230228094756-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <8611d901-0940-3747-c2cd-9c193c7f24f2@yandex-team.ru>

On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote:
> I really don't understand why and what do you want to check on
> destination.

Yes I understand your patch controls source. Let me try to rephrase
why I think it's better on destination.
Here's my understanding
- With vhost-user-fs state lives inside an external daemon.
A- If after load you connect to the same daemon you can get migration mostly
  for free.
B- If you connect to a different daemon then that daemon will need
  to pass information from original one.

Is this a fair summary?

Current solution is to set flag on the source meaning "I have an
orchestration tool that will make sure that either A or B is correct".

However both A and B can only be known when destination is known.
Especially as long as what we are really trying to do is just allow qemu
restarts, Checking the flag on load will thus achive it in a cleaner
way, in that orchestration tool can reasonably keep the flag
clear normally and only set it if restarting qemu locally.


By comparison, with your approach orchestration tool will have
to either always set the flag (risky since then we lose the
extra check that we coded) or keep it clear and set before migration
(complex).

I hope I explained what and why I want to check.

I am far from a vhost-user-fs expert so maybe I am wrong but
I wanted to make sure I got the point across even if other
disagree.

-- 
MST



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

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 17:00 [PATCH v3 0/1] virtio-fs: implement option for stateless migration Anton Kuchin
2023-02-17 17:00 ` [PATCH v3 1/1] vhost-user-fs: add migration type property Anton Kuchin
2023-02-21 20:45   ` Stefan Hajnoczi
2023-02-22 12:20   ` Vladimir Sementsov-Ogievskiy
2023-02-22 12:43     ` Michael S. Tsirkin
2023-02-22 14:25       ` Anton Kuchin
2023-02-22 15:14         ` Vladimir Sementsov-Ogievskiy
2023-02-22 16:43           ` Michael S. Tsirkin
2023-02-22 17:15             ` Anton Kuchin
2023-02-22 17:30               ` Michael S. Tsirkin
2023-02-22 16:49           ` Anton Kuchin
2023-02-22 16:51             ` Michael S. Tsirkin
2023-02-22 17:05               ` Anton Kuchin
2023-02-22 17:12                 ` Michael S. Tsirkin
2023-02-22 18:25                   ` Anton Kuchin
2023-02-22 20:21                     ` Michael S. Tsirkin
2023-02-22 20:50                       ` Anton Kuchin
2023-03-01 15:40                         ` Michael S. Tsirkin
2023-02-23  7:36                       ` Michael S. Tsirkin
2023-02-23 21:24                         ` Stefan Hajnoczi
2023-02-24  4:14                           ` Anton Kuchin
2023-02-27 10:19                             ` Anton Kuchin
2023-02-24  8:47                           ` Michael S. Tsirkin
2023-02-28 14:30                             ` Anton Kuchin
2023-02-28 14:57                               ` Michael S. Tsirkin [this message]
2023-02-28 17:59                                 ` Anton Kuchin
2023-02-28 21:24                                   ` Michael S. Tsirkin
2023-03-01 14:03                                     ` Vladimir Sementsov-Ogievskiy
2023-03-01 14:46                                       ` Michael S. Tsirkin
2023-03-01 15:40                                         ` Anton Kuchin
2023-03-01 15:52                                           ` Michael S. Tsirkin
2023-03-01 16:29                                             ` Anton Kuchin
2023-03-01 17:19                                               ` Michael S. Tsirkin
2023-03-01 19:42                                             ` Anton Kuchin
2023-03-01 15:07                                     ` Anton Kuchin
2023-03-01 15:24                                       ` Michael S. Tsirkin
2023-03-01 16:04                                         ` Anton Kuchin
2023-03-01 17:17                                           ` Michael S. Tsirkin
2023-03-01 19:35                                             ` Anton Kuchin
2023-03-01 20:22                                               ` Michael S. Tsirkin
2023-03-06 20:55                                                 ` Anton Kuchin
2023-03-06 21:53                                                   ` Michael S. Tsirkin
2023-03-17 18:04                                                     ` Anton Kuchin
2023-03-01 15:33                                   ` Michael S. Tsirkin
2023-03-17 19:02                                     ` Anton Kuchin
2023-02-28 19:18                                 ` Stefan Hajnoczi
2023-02-28 21:29                                   ` Michael S. Tsirkin
2023-02-28 21:54                                     ` Michael S. Tsirkin
2023-02-22 14:21     ` Anton Kuchin
2023-02-22 15:15       ` Vladimir Sementsov-Ogievskiy
2023-02-22 15:20   ` Vladimir Sementsov-Ogievskiy

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=20230228094756-mutt-send-email-mst@kernel.org \
    --to=mst@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=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@redhat.com \
    --cc=vsementsov@yandex-team.ru \
    --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).