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: Wed, 1 Mar 2023 10:33:54 -0500 [thread overview]
Message-ID: <20230301102757-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f3338868-d43a-a499-5db8-2fb06d244e37@yandex-team.ru>
On Tue, Feb 28, 2023 at 07:59:54PM +0200, Anton Kuchin wrote:
> We can't rely here entirely on
> destination to block this because if VM is migrated to file and then
> can't be loaded by destination there is no way to fallback and resume
> the source so we need to have some kind of blocker on source by default.
So I commented about a fallback. IMO it's just orchestrator being silly:
don't kill source qemu until you have made sure destination loaded the
file, or re-load it, and all will be well.
But a bigger issue that this highlights is simply that if migrating to
file you have no idea at all where will the file be loaded. Maybe some
orchestrators know but I don't see how we can be sure all of them know.
The only time where we know whether the file is loaded on the same host
where it was saved is when we actually load it.
--
MST
next prev parent reply other threads:[~2023-03-01 15:34 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
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 [this message]
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=20230301102757-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).