Eric Blake <ebl...@redhat.com> writes: > On 10/1/19 2:34 PM, Markus Armbruster wrote: >> Peter Krempa <pkre...@redhat.com> writes: >> >>> savevm was buggy as it considered all monitor owned block device nodes >> >> Recommend "monitor-owned block device nodes" or "block device nodes >> owned by a monitor" >> >>> for snapshot. With introduction of -blockdev the common usage made all >>> nodes including protocol nodes monitor owned and thus considered for >>> snapshot. >> >> What exactly is / was the problem? > > > Old way: using QMP add_device, you create a drive backend with two BDS > (format and protocol) assigned to it; the drive backend has your given > name, and both BDS have a generated name (beginning with '#'). The > two BDS are not monitor-owned, rather, the drive is. > > New way: using QMP blockdev_add, you create the two BDS manually with > names of your choice, then plug that blockdev into an unnamed > blockbackend (the drive no longer needs a name, because you can get at > everything through the BDS name). You _could_ do this in one step > (the QAPI allows self-recursion where you can define both the format > and protocol in one step), but it is easier to do in two steps (define > the protocol BDS first, then define the format BDS using a "string" > name of the protocol BDS instead of a { "driver":..., args... } object > of the protocol layer. But by making two calls, now both BDS are > monitor-owned. > > At snapshot-time, the code currently looks for all monitor-owned nodes > when deciding what to snapshot. In the old way, this finds the named > drive, picks up its associated top-most node, and snapshots the format > layer. In the new way, the drive is unnamed so it is skipped, while > there are two named BDS, but we don't want a snapshot of the protocol > layer.
So the problem is certain (common & sane) -blockdev use makes savevm create additional, unwanted snapshots. Your explanation should be worked into the commit message along with ... >>> This was fixed but clients need to be able to detect whether >>> this fix is present. >> >> Fixed where? Commit hash, if possible. > > Pull request: > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg04773.html > (assuming it doesn't need a respin before landing, 8ec72832) ... a pointer to this fix. Thanks! [...]