|
From: | Hanna Czenczek |
Subject: | Re: [PATCH 2/4] vhost-user: Interface for migration state transfer |
Date: | Wed, 19 Apr 2023 12:45:19 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 14.04.23 17:17, Eugenio Perez Martin wrote:
On Thu, Apr 13, 2023 at 7:55 PM Hanna Czenczek <hreitz@redhat.com> wrote:
[...]
Basically, what I’m hearing is that I need to implement a different feature that has no practical impact right now, and also fix bugs around it along the way...To fix this properly requires iterative device migration in qemu as far as I know, instead of using VMStates [1]. This way the state is requested to virtiofsd before the device reset. What does virtiofsd do when the state is totally sent? Does it keep processing requests and generating new state or is only a one shot that will suspend the daemon? If it is the second I think it still can be done in one shot at the end, always indicating "no more state" at save_live_pending and sending all the state at save_live_complete_precopy.
This sounds to me as if we should reset all devices during migration, and I don’t understand that. virtiofsd will not immediately process requests when the state is sent, because the device is still stopped, but when it is re-enabled (e.g. because of a failed migration), it will have retained its state and continue processing requests as if nothing happened. A reset would break this and other stateful back-ends, as I think Stefan has mentioned somewhere else.
It seems to me as if there are devices that need a reset, and so need suspend+resume around it, but I also think there are back-ends that don’t, where this would only unnecessarily complicate the back-end implementation.
Hanna
[Prev in Thread] | Current Thread | [Next in Thread] |