On 19.09.25 20:16, Steven Sistare wrote:
On 9/12/2025 11:44 AM, Peter Xu wrote:
On Fri, Sep 12, 2025 at 10:50:34AM -0400, Steven Sistare wrote:
How to guarantee src/dst device topology match
exactly the same with the new cmdline?
That is up to the mgmt layer, to know how QEMU was originally started, and
what has been hot plugged afterwards. The fast qom-list-get command that
I recently added can help here.
I see. If you think that is the best way to consume cpr-exec, would you
add a small section into the doc patch for it as well?
It is not related to cpr-exec. It is related to hot plug, for any migration
type scenario, so it does not fit in the cpr-exec docs.
IMHO it matters.. With cpr-transfer, QMP hot plugs works and will not
contribute to downtime.
I don't follow. The guest is not resumed until after all devices that were
present in old QEMU are hot plugged in new QEMU, regardless of mode.
Yes, but in case of cpr-transfer, source is still running at time when we do
adding
devices to target through QMP. So, downtime is not started until we say
"migrate-incoming".
cpr-exec also works, but will contribute to
downtime.
We could, in the comparison section between cpr-exec v.s. cpr-transfer,
mention the potential difference on device hot plugs (out of many other
differences), then also mention that there's an option to reduce downtime
for cpr-exec due to hot-plug by converting QMP hot plugs into cmdlines
leveraging qom-list-get and other facilities. From there we could further
link to a special small section describing the usage of qom-list-get, or
stop there.
To hot plug a device, *or* to add it to the new QEMU command line, the manager
must know that the device was added sometime after old QEMU started, and
qom-list-get can help with that, by examining old QEMU initially and again
immediately before the update, then performing a diff. But again, this
is independent of mode.
- Steve
--
Best regards,
Vladimir
