[PATCH 18/24] qemu: checkpoint: Implement VIR_DOMAIN_CHECKPOINT_XML_SIZE

Peter Krempa pkrempa at redhat.com
Tue Jul 7 10:45:35 UTC 2020


On Thu, Jul 02, 2020 at 14:42:50 -0500, Eric Blake wrote:
> On 7/2/20 9:40 AM, Peter Krempa wrote:
> > Introduce code which merges the appropriate bitmaps and queries the
> > final size of the backup, so that we can print the XML with size
> > information.
> > 
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >   src/qemu/qemu_checkpoint.c | 143 ++++++++++++++++++++++++++++++++++++-
> >   1 file changed, 142 insertions(+), 1 deletion(-)
> > 
> 
> > +    /* we need to calculate the merged bitmap to obtain accurate data */
> > +    for (i = 0; i < ndisks; i++) {
> > +        virDomainDiskDefPtr domdisk = diskmap[i].domdisk;
> > +        g_autoptr(virJSONValue) actions = NULL;
> > +
> > +        /* possibly delete leftovers from previous cases */
> > +        if (qemuBlockNamedNodeDataGetBitmapByName(blockNamedNodeData, domdisk->src,
> > +                                                  "libvirt-tmp-size-xml")) {
> > +            if (!recoveractions)
> > +                recoveractions = virJSONValueNewArray();
> > +
> > +            if (qemuMonitorTransactionBitmapRemove(recoveractions,
> > +                                                   domdisk->src->nodeformat,
> > +                                                   "libvirt-tmp-size-xml") < 0)
> > +                goto endjob;
> > +        }
> 
> Odd that we may leave a temporary bitmap in qemu's memory if we fail partway
> through, but not the end of the world, and you handle it nicely here.

Well a SIGKILL or SIGSEGV between adding the bitmaps and querying and
removing them can always ruin your day. It's especially hard to recover
from such scenario, yet it doesn't feel to be worth adding status XML
for it.





More information about the libvir-list mailing list