<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 24, 2023, 04:50 Dr. David Alan Gilbert <<a href="mailto:dgilbert@redhat.com">dgilbert@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Stefan Hajnoczi (<a href="mailto:stefanha@gmail.com" target="_blank" rel="noreferrer">stefanha@gmail.com</a>) wrote:<br>
> On Mon, 23 Jan 2023 at 14:54, Stefan Hajnoczi <<a href="mailto:stefanha@redhat.com" target="_blank" rel="noreferrer">stefanha@redhat.com</a>> wrote:<br>
> ><br>
> > On Mon, Jan 23, 2023 at 06:27:23PM +0000, Dr. David Alan Gilbert wrote:<br>
> > > * Michael S. Tsirkin (<a href="mailto:mst@redhat.com" target="_blank" rel="noreferrer">mst@redhat.com</a>) wrote:<br>
> > > > On Sun, Jan 22, 2023 at 06:09:40PM +0200, Anton Kuchin wrote:<br>
> > > > ><br>
> > > > > On 22/01/2023 16:46, Michael S. Tsirkin wrote:<br>
> > > > > > On Sun, Jan 22, 2023 at 02:36:04PM +0200, Anton Kuchin wrote:<br>
> > > > > > > > > This flag should be set when qemu don't need to worry about any<br>
> > > > > > > > > external state stored in vhost-user daemons during migration:<br>
> > > > > > > > > don't fail migration, just pack generic virtio device states to<br>
> > > > > > > > > migration stream and orchestrator guarantees that the rest of the<br>
> > > > > > > > > state will be present at the destination to restore full context and<br>
> > > > > > > > > continue running.<br>
> > > > > > > > Sorry  I still do not get it.  So fundamentally, why do we need this property?<br>
> > > > > > > > vhost-user-fs is not created by default that we'd then need opt-in to<br>
> > > > > > > > the special "migrateable" case.<br>
> > > > > > > > That's why I said it might make some sense as a device property as qemu<br>
> > > > > > > > tracks whether device is unplugged for us.<br>
> > > > > > > ><br>
> > > > > > > > But as written, if you are going to teach the orchestrator about<br>
> > > > > > > > vhost-user-fs and its special needs, just teach it when to migrate and<br>
> > > > > > > > where not to migrate.<br>
> > > > > > > ><br>
> > > > > > > > Either we describe the special situation to qemu and let qemu<br>
> > > > > > > > make an intelligent decision whether to allow migration,<br>
> > > > > > > > or we trust the orchestrator. And if it's the latter, then 'migrate'<br>
> > > > > > > > already says orchestrator decided to migrate.<br>
> > > > > > > The problem I'm trying to solve is that most of vhost-user devices<br>
> > > > > > > now block migration in qemu. And this makes sense since qemu can't<br>
> > > > > > > extract and transfer backend daemon state. But this prevents us from<br>
> > > > > > > updating qemu executable via local migration. So this flag is<br>
> > > > > > > intended more as a safety check that says "I know what I'm doing".<br>
> > > > > > ><br>
> > > > > > > I agree that it is not really necessary if we trust the orchestrator<br>
> > > > > > > to request migration only when the migration can be performed in a<br>
> > > > > > > safe way. But changing the current behavior of vhost-user-fs from<br>
> > > > > > > "always blocks migration" to "migrates partial state whenever<br>
> > > > > > > orchestrator requests it" seems a little  dangerous and can be<br>
> > > > > > > misinterpreted as full support for migration in all cases.<br>
> > > > > > It's not really different from block is it? orchestrator has to arrange<br>
> > > > > > for backend migration. I think we just assumed there's no use-case where<br>
> > > > > > this is practical for vhost-user-fs so we blocked it.<br>
> > > > > > But in any case it's orchestrator's responsibility.<br>
> > > > ><br>
> > > > > Yes, you are right. So do you think we should just drop the blocker<br>
> > > > > without adding a new flag?<br>
> > > ><br>
> > > > I'd be inclined to. I am curious what do dgilbert and stefanha think though.<br>
> > ><br>
> > > Yes I think that's probably OK, as long as we use the flag for knowing<br>
> > > how to handle the discard bitmap as a proxy for the daemon knowing how<br>
> > > to handle *some* migrations; knowing which migrations is then the job<br>
> > > for the orchestrator to be careful of.<br>
> ><br>
> > I think the feature bit is not a good way to detect live migration<br>
> > support. vhost-user backends typically use libvhost-user, rust-vmm's<br>
> > vhost-user-backend crate, etc where this feature can be implemented for<br>
> > free. If the feature bit is advertized we don't know if the device<br>
> > implementation (net, blk, fs, etc) is aware of migration at all.<br>
> <br>
> I checked how bad the situation is. libvhost-user currently enables<br>
> LOG_ALL by default. :(<br>
> <br>
> So I don't think the front-end can use LOG_ALL alone to determine<br>
> whether or not migration is supported by the back-end.<br>
> <br>
> There are several existing back-ends based on libvhost-user that have<br>
> no concept of reconnection or migration but report the LOG_ALL feature<br>
> bit.<br>
<br>
Ouch, yes that's messy.<br>
<br>
Going back to the original question; I don't think a command line flag<br>
will work though, because even for a given VM there's the possibility<br>
of some (local) migrations working but other (remote) migrations not<br>
working; so you don't know at the point you start the VM whether<br>
your migrations are going to work.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Stefan</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>