backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
/*
|
|
|
|
* checkpoint_conf.c: domain checkpoint XML processing
|
|
|
|
*
|
|
|
|
* Copyright (C) 2006-2019 Red Hat, Inc.
|
|
|
|
* Copyright (C) 2006-2008 Daniel P. Berrange
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
#include "configmake.h"
|
|
|
|
#include "internal.h"
|
|
|
|
#include "virbitmap.h"
|
|
|
|
#include "virbuffer.h"
|
|
|
|
#include "datatypes.h"
|
|
|
|
#include "domain_conf.h"
|
|
|
|
#include "virlog.h"
|
|
|
|
#include "viralloc.h"
|
|
|
|
#include "checkpoint_conf.h"
|
|
|
|
#include "virstoragefile.h"
|
|
|
|
#include "viruuid.h"
|
|
|
|
#include "virfile.h"
|
|
|
|
#include "virerror.h"
|
|
|
|
#include "virxml.h"
|
|
|
|
#include "virstring.h"
|
2019-07-26 19:28:44 +00:00
|
|
|
#include "virdomaincheckpointobjlist.h"
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_DOMAIN_CHECKPOINT
|
|
|
|
|
|
|
|
VIR_LOG_INIT("conf.checkpoint_conf");
|
|
|
|
|
|
|
|
static virClassPtr virDomainCheckpointDefClass;
|
|
|
|
static void virDomainCheckpointDefDispose(void *obj);
|
|
|
|
|
|
|
|
static int
|
|
|
|
virDomainCheckpointOnceInit(void)
|
|
|
|
{
|
|
|
|
if (!VIR_CLASS_NEW(virDomainCheckpointDef, virClassForDomainMomentDef()))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
VIR_ONCE_GLOBAL_INIT(virDomainCheckpoint);
|
|
|
|
|
|
|
|
VIR_ENUM_IMPL(virDomainCheckpoint,
|
|
|
|
VIR_DOMAIN_CHECKPOINT_TYPE_LAST,
|
|
|
|
"default", "no", "bitmap");
|
|
|
|
|
|
|
|
|
|
|
|
/* Checkpoint Def functions */
|
|
|
|
static void
|
|
|
|
virDomainCheckpointDiskDefClear(virDomainCheckpointDiskDefPtr disk)
|
|
|
|
{
|
|
|
|
VIR_FREE(disk->name);
|
|
|
|
VIR_FREE(disk->bitmap);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate a new virDomainCheckpointDef; free with virObjectUnref() */
|
|
|
|
virDomainCheckpointDefPtr
|
|
|
|
virDomainCheckpointDefNew(void)
|
|
|
|
{
|
|
|
|
if (virDomainCheckpointInitialize() < 0)
|
|
|
|
return NULL;
|
|
|
|
|
2019-10-17 08:10:10 +00:00
|
|
|
return virObjectNew(virDomainCheckpointDefClass);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
virDomainCheckpointDefDispose(void *obj)
|
|
|
|
{
|
|
|
|
virDomainCheckpointDefPtr def = obj;
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < def->ndisks; i++)
|
|
|
|
virDomainCheckpointDiskDefClear(&def->disks[i]);
|
|
|
|
VIR_FREE(def->disks);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
virDomainCheckpointDiskDefParseXML(xmlNodePtr node,
|
|
|
|
xmlXPathContextPtr ctxt,
|
|
|
|
virDomainCheckpointDiskDefPtr def)
|
|
|
|
{
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree char *checkpoint = NULL;
|
2020-07-28 19:47:48 +00:00
|
|
|
VIR_XPATH_NODE_AUTORESTORE(ctxt)
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
ctxt->node = node;
|
|
|
|
|
|
|
|
/* Schema guarantees this is non-NULL: */
|
|
|
|
def->name = virXMLPropString(node, "name");
|
|
|
|
|
|
|
|
checkpoint = virXMLPropString(node, "checkpoint");
|
|
|
|
if (checkpoint)
|
|
|
|
/* Schema guarantees this is in range: */
|
|
|
|
def->type = virDomainCheckpointTypeFromString(checkpoint);
|
|
|
|
else
|
|
|
|
def->type = VIR_DOMAIN_CHECKPOINT_TYPE_BITMAP;
|
|
|
|
|
|
|
|
def->bitmap = virXMLPropString(node, "bitmap");
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-11-27 13:10:21 +00:00
|
|
|
/* flags is bitwise-or of virDomainCheckpointParseFlags.
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
*/
|
|
|
|
static virDomainCheckpointDefPtr
|
|
|
|
virDomainCheckpointDefParse(xmlXPathContextPtr ctxt,
|
|
|
|
virDomainXMLOptionPtr xmlopt,
|
2019-08-06 12:19:35 +00:00
|
|
|
void *parseOpaque,
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
virDomainCheckpointDefPtr ret = NULL;
|
|
|
|
size_t i;
|
|
|
|
int n;
|
|
|
|
char *tmp;
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree xmlNodePtr *nodes = NULL;
|
2019-10-15 12:47:50 +00:00
|
|
|
g_autoptr(virDomainCheckpointDef) def = NULL;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
if (!(def = virDomainCheckpointDefNew()))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
def->parent.name = virXPathString("string(./name)", ctxt);
|
|
|
|
|
|
|
|
if (def->parent.name == NULL) {
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_PARSE_REDEFINE) {
|
|
|
|
virReportError(VIR_ERR_XML_ERROR, "%s",
|
|
|
|
_("a redefined checkpoint must have a name"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
def->parent.description = virXPathString("string(./description)", ctxt);
|
|
|
|
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_PARSE_REDEFINE) {
|
|
|
|
if (virXPathLongLong("string(./creationTime)", ctxt,
|
|
|
|
&def->parent.creationTime) < 0) {
|
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
|
|
|
|
_("missing creationTime from existing checkpoint"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
def->parent.parent_name = virXPathString("string(./parent/name)", ctxt);
|
|
|
|
|
|
|
|
if ((tmp = virXPathString("string(./domain/@type)", ctxt))) {
|
|
|
|
int domainflags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
|
|
|
|
VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE;
|
|
|
|
xmlNodePtr domainNode = virXPathNode("./domain", ctxt);
|
|
|
|
|
|
|
|
VIR_FREE(tmp);
|
|
|
|
if (!domainNode) {
|
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
|
|
|
|
_("missing domain in checkpoint"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
def->parent.dom = virDomainDefParseNode(ctxt->node->doc, domainNode,
|
2019-11-27 12:29:21 +00:00
|
|
|
xmlopt, parseOpaque,
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
domainflags);
|
|
|
|
if (!def->parent.dom)
|
|
|
|
return NULL;
|
|
|
|
} else {
|
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
|
|
|
|
_("missing domain in checkpoint redefine"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
} else if (virDomainXMLOptionRunMomentPostParse(xmlopt, &def->parent) < 0) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((n = virXPathNodeSet("./disks/*", ctxt, &nodes)) < 0)
|
|
|
|
return NULL;
|
2020-10-07 19:15:50 +00:00
|
|
|
if (n)
|
|
|
|
def->disks = g_new0(virDomainCheckpointDiskDef, n);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
def->ndisks = n;
|
|
|
|
for (i = 0; i < def->ndisks; i++) {
|
|
|
|
if (virDomainCheckpointDiskDefParseXML(nodes[i], ctxt,
|
|
|
|
&def->disks[i]) < 0)
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-10-16 11:43:01 +00:00
|
|
|
ret = g_steal_pointer(&def);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static virDomainCheckpointDefPtr
|
|
|
|
virDomainCheckpointDefParseNode(xmlDocPtr xml,
|
|
|
|
xmlNodePtr root,
|
|
|
|
virDomainXMLOptionPtr xmlopt,
|
2019-08-06 12:19:35 +00:00
|
|
|
void *parseOpaque,
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
2019-10-15 12:47:50 +00:00
|
|
|
g_autoptr(xmlXPathContext) ctxt = NULL;
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree char *schema = NULL;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
if (!virXMLNodeNameEqual(root, "domaincheckpoint")) {
|
|
|
|
virReportError(VIR_ERR_XML_ERROR, "%s", _("domaincheckpoint"));
|
2019-09-16 10:52:57 +00:00
|
|
|
return NULL;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* This is a new enough API to make schema validation unconditional */
|
|
|
|
schema = virFileFindResource("domaincheckpoint.rng",
|
|
|
|
abs_top_srcdir "/docs/schemas",
|
|
|
|
PKGDATADIR "/schemas");
|
|
|
|
if (!schema)
|
|
|
|
return NULL;
|
|
|
|
if (virXMLValidateAgainstSchema(schema, xml) < 0)
|
|
|
|
return NULL;
|
|
|
|
|
2019-09-09 06:33:58 +00:00
|
|
|
if (!(ctxt = virXMLXPathContextNew(xml)))
|
2019-09-16 10:52:57 +00:00
|
|
|
return NULL;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
ctxt->node = root;
|
2019-11-27 13:10:21 +00:00
|
|
|
return virDomainCheckpointDefParse(ctxt, xmlopt, parseOpaque, flags);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
virDomainCheckpointDefPtr
|
|
|
|
virDomainCheckpointDefParseString(const char *xmlStr,
|
|
|
|
virDomainXMLOptionPtr xmlopt,
|
2019-08-06 12:19:35 +00:00
|
|
|
void *parseOpaque,
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
virDomainCheckpointDefPtr ret = NULL;
|
|
|
|
xmlDocPtr xml;
|
|
|
|
int keepBlanksDefault = xmlKeepBlanksDefault(0);
|
|
|
|
|
|
|
|
if ((xml = virXMLParse(NULL, xmlStr, _("(domain_checkpoint)")))) {
|
|
|
|
xmlKeepBlanksDefault(keepBlanksDefault);
|
|
|
|
ret = virDomainCheckpointDefParseNode(xml, xmlDocGetRootElement(xml),
|
2019-11-27 13:10:21 +00:00
|
|
|
xmlopt, parseOpaque, flags);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
xmlFreeDoc(xml);
|
|
|
|
}
|
|
|
|
xmlKeepBlanksDefault(keepBlanksDefault);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virDomainCheckpointDefAssignBitmapNames:
|
|
|
|
* @def: checkpoint def object
|
|
|
|
*
|
|
|
|
* Generate default bitmap names for checkpoint targets. Returns 0 on
|
|
|
|
* success, -1 on error.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
virDomainCheckpointDefAssignBitmapNames(virDomainCheckpointDefPtr def)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < def->ndisks; i++) {
|
|
|
|
virDomainCheckpointDiskDefPtr disk = &def->disks[i];
|
|
|
|
|
|
|
|
if (disk->type != VIR_DOMAIN_CHECKPOINT_TYPE_BITMAP ||
|
|
|
|
disk->bitmap)
|
|
|
|
continue;
|
|
|
|
|
2019-10-20 11:49:46 +00:00
|
|
|
disk->bitmap = g_strdup(def->parent.name);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Align def->disks to def->domain. Sort the list of def->disks,
|
|
|
|
* filling in any missing disks with appropriate default. Convert
|
|
|
|
* paths to disk targets for uniformity. Issue an error and return -1
|
|
|
|
* if any def->disks[n]->name appears more than once or does not map
|
|
|
|
* to dom->disks. */
|
|
|
|
int
|
2020-12-01 16:20:10 +00:00
|
|
|
virDomainCheckpointAlignDisks(virDomainCheckpointDefPtr chkdef)
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
{
|
2020-12-01 16:20:10 +00:00
|
|
|
virDomainDefPtr domdef = chkdef->parent.dom;
|
2020-12-01 17:10:00 +00:00
|
|
|
g_autoptr(GHashTable) map = virHashNew(NULL);
|
|
|
|
g_autofree virDomainCheckpointDiskDefPtr olddisks = NULL;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
size_t i;
|
|
|
|
int checkpoint_default = VIR_DOMAIN_CHECKPOINT_TYPE_NONE;
|
|
|
|
|
2020-12-01 16:18:44 +00:00
|
|
|
if (!domdef) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
|
|
|
|
_("missing domain in checkpoint"));
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
2020-12-01 16:20:10 +00:00
|
|
|
if (chkdef->ndisks > domdef->ndisks) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
|
|
|
|
_("too many disk checkpoint requests for domain"));
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Unlikely to have a guest without disks but technically possible. */
|
2020-12-01 16:18:44 +00:00
|
|
|
if (!domdef->ndisks) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
|
2020-12-01 16:57:23 +00:00
|
|
|
_("domain must have at least one disk to perform checkpoints"));
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* If <disks> omitted, do bitmap on all writeable disks;
|
|
|
|
* otherwise, do nothing for omitted disks */
|
2020-12-01 16:20:10 +00:00
|
|
|
if (!chkdef->ndisks)
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
checkpoint_default = VIR_DOMAIN_CHECKPOINT_TYPE_BITMAP;
|
|
|
|
|
|
|
|
/* Double check requested disks. */
|
2020-12-01 16:20:10 +00:00
|
|
|
for (i = 0; i < chkdef->ndisks; i++) {
|
2020-12-01 16:22:21 +00:00
|
|
|
virDomainCheckpointDiskDefPtr chkdisk = &chkdef->disks[i];
|
2020-12-01 16:55:54 +00:00
|
|
|
virDomainDiskDefPtr domdisk = virDomainDiskByName(domdef, chkdisk->name, false);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
2020-12-01 16:55:54 +00:00
|
|
|
if (!domdisk) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
2020-12-01 16:22:21 +00:00
|
|
|
_("no disk named '%s'"), chkdisk->name);
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
2020-12-01 17:10:00 +00:00
|
|
|
if (virHashHasEntry(map, domdisk->dst)) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("disk '%s' specified twice"),
|
2020-12-01 16:22:21 +00:00
|
|
|
chkdisk->name);
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
2020-12-01 17:03:47 +00:00
|
|
|
|
2020-12-01 17:10:00 +00:00
|
|
|
if (virHashAddEntry(map, domdisk->dst, chkdisk) < 0)
|
|
|
|
return -1;
|
|
|
|
|
2020-12-01 17:03:47 +00:00
|
|
|
if ((virStorageSourceIsEmpty(domdisk->src) ||
|
|
|
|
domdisk->src->readonly) &&
|
2020-12-01 16:22:21 +00:00
|
|
|
chkdisk->type != VIR_DOMAIN_CHECKPOINT_TYPE_NONE) {
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
|
|
|
|
_("disk '%s' is empty or readonly"),
|
2020-12-01 16:22:21 +00:00
|
|
|
chkdisk->name);
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
2020-12-01 17:03:47 +00:00
|
|
|
if (STRNEQ(chkdisk->name, domdisk->dst)) {
|
2020-12-01 16:22:21 +00:00
|
|
|
VIR_FREE(chkdisk->name);
|
2020-12-01 17:03:47 +00:00
|
|
|
chkdisk->name = g_strdup(domdisk->dst);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-01 17:10:00 +00:00
|
|
|
olddisks = g_steal_pointer(&chkdef->disks);
|
|
|
|
chkdef->disks = g_new0(virDomainCheckpointDiskDef, domdef->ndisks);
|
|
|
|
chkdef->ndisks = domdef->ndisks;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
2020-12-01 16:18:44 +00:00
|
|
|
for (i = 0; i < domdef->ndisks; i++) {
|
2020-12-01 17:10:00 +00:00
|
|
|
virDomainDiskDefPtr domdisk = domdef->disks[i];
|
|
|
|
virDomainCheckpointDiskDefPtr chkdisk = chkdef->disks + i;
|
|
|
|
virDomainCheckpointDiskDefPtr existing;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
2020-12-01 17:10:00 +00:00
|
|
|
/* copy existing disks */
|
|
|
|
if ((existing = virHashLookup(map, domdisk->dst))) {
|
|
|
|
memcpy(chkdisk, existing, sizeof(*chkdisk));
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
continue;
|
2020-12-01 17:10:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Provide defaults for all remaining disks. */
|
|
|
|
chkdisk->name = g_strdup(domdisk->dst);
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
/* Don't checkpoint empty or readonly drives */
|
2020-12-01 17:10:00 +00:00
|
|
|
if (virStorageSourceIsEmpty(domdisk->src) ||
|
|
|
|
domdisk->src->readonly)
|
2020-12-01 16:22:21 +00:00
|
|
|
chkdisk->type = VIR_DOMAIN_CHECKPOINT_TYPE_NONE;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
else
|
2020-12-01 16:22:21 +00:00
|
|
|
chkdisk->type = checkpoint_default;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Generate default bitmap names for checkpoint */
|
2020-12-01 16:20:10 +00:00
|
|
|
if (virDomainCheckpointDefAssignBitmapNames(chkdef) < 0)
|
2020-12-01 16:04:03 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
2020-12-01 16:04:03 +00:00
|
|
|
return 0;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Converts public VIR_DOMAIN_CHECKPOINT_XML_* into
|
|
|
|
* VIR_DOMAIN_CHECKPOINT_FORMAT_* flags, and silently ignores any other
|
|
|
|
* flags. */
|
|
|
|
unsigned int virDomainCheckpointFormatConvertXMLFlags(unsigned int flags)
|
|
|
|
{
|
|
|
|
unsigned int formatFlags = 0;
|
|
|
|
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_XML_SECURE)
|
|
|
|
formatFlags |= VIR_DOMAIN_CHECKPOINT_FORMAT_SECURE;
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN)
|
|
|
|
formatFlags |= VIR_DOMAIN_CHECKPOINT_FORMAT_NO_DOMAIN;
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_XML_SIZE)
|
|
|
|
formatFlags |= VIR_DOMAIN_CHECKPOINT_FORMAT_SIZE;
|
|
|
|
|
|
|
|
return formatFlags;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
virDomainCheckpointDiskDefFormat(virBufferPtr buf,
|
|
|
|
virDomainCheckpointDiskDefPtr disk,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
if (!disk->name)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
virBufferEscapeString(buf, "<disk name='%s'", disk->name);
|
|
|
|
if (disk->type)
|
|
|
|
virBufferAsprintf(buf, " checkpoint='%s'",
|
|
|
|
virDomainCheckpointTypeToString(disk->type));
|
|
|
|
if (disk->bitmap) {
|
|
|
|
virBufferEscapeString(buf, " bitmap='%s'", disk->bitmap);
|
2020-07-01 14:58:29 +00:00
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_FORMAT_SIZE && disk->sizeValid)
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
virBufferAsprintf(buf, " size='%llu'", disk->size);
|
|
|
|
}
|
|
|
|
virBufferAddLit(buf, "/>\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
virDomainCheckpointDefFormatInternal(virBufferPtr buf,
|
|
|
|
virDomainCheckpointDefPtr def,
|
|
|
|
virDomainXMLOptionPtr xmlopt,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
unsigned int domainflags = VIR_DOMAIN_DEF_FORMAT_INACTIVE;
|
|
|
|
|
|
|
|
if (flags & VIR_DOMAIN_CHECKPOINT_FORMAT_SECURE)
|
|
|
|
domainflags |= VIR_DOMAIN_DEF_FORMAT_SECURE;
|
|
|
|
|
|
|
|
virBufferAddLit(buf, "<domaincheckpoint>\n");
|
|
|
|
virBufferAdjustIndent(buf, 2);
|
|
|
|
|
|
|
|
virBufferEscapeString(buf, "<name>%s</name>\n", def->parent.name);
|
|
|
|
virBufferEscapeString(buf, "<description>%s</description>\n",
|
|
|
|
def->parent.description);
|
|
|
|
|
|
|
|
if (def->parent.parent_name) {
|
|
|
|
virBufferAddLit(buf, "<parent>\n");
|
|
|
|
virBufferAdjustIndent(buf, 2);
|
|
|
|
virBufferEscapeString(buf, "<name>%s</name>\n",
|
|
|
|
def->parent.parent_name);
|
|
|
|
virBufferAdjustIndent(buf, -2);
|
|
|
|
virBufferAddLit(buf, "</parent>\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (def->parent.creationTime)
|
|
|
|
virBufferAsprintf(buf, "<creationTime>%lld</creationTime>\n",
|
|
|
|
def->parent.creationTime);
|
|
|
|
|
|
|
|
if (def->ndisks) {
|
|
|
|
virBufferAddLit(buf, "<disks>\n");
|
|
|
|
virBufferAdjustIndent(buf, 2);
|
|
|
|
for (i = 0; i < def->ndisks; i++) {
|
|
|
|
if (virDomainCheckpointDiskDefFormat(buf, &def->disks[i],
|
|
|
|
flags) < 0)
|
2020-07-03 03:19:26 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
}
|
|
|
|
virBufferAdjustIndent(buf, -2);
|
|
|
|
virBufferAddLit(buf, "</disks>\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(flags & VIR_DOMAIN_CHECKPOINT_FORMAT_NO_DOMAIN) &&
|
2019-11-26 19:40:46 +00:00
|
|
|
virDomainDefFormatInternal(def->parent.dom, xmlopt,
|
2019-11-27 11:57:34 +00:00
|
|
|
buf, domainflags) < 0)
|
2020-07-03 03:19:26 +00:00
|
|
|
return -1;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
virBufferAdjustIndent(buf, -2);
|
|
|
|
virBufferAddLit(buf, "</domaincheckpoint>\n");
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-07-03 03:19:26 +00:00
|
|
|
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
char *
|
|
|
|
virDomainCheckpointDefFormat(virDomainCheckpointDefPtr def,
|
|
|
|
virDomainXMLOptionPtr xmlopt,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
2020-07-03 02:19:01 +00:00
|
|
|
g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
|
|
|
|
virCheckFlags(VIR_DOMAIN_CHECKPOINT_FORMAT_SECURE |
|
|
|
|
VIR_DOMAIN_CHECKPOINT_FORMAT_NO_DOMAIN |
|
|
|
|
VIR_DOMAIN_CHECKPOINT_FORMAT_SIZE, NULL);
|
2019-11-27 13:10:21 +00:00
|
|
|
if (virDomainCheckpointDefFormatInternal(&buf, def, xmlopt,
|
backup: Parse and output checkpoint XML
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
2018-07-08 02:01:14 +00:00
|
|
|
flags) < 0)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return virBufferContentAndReset(&buf);
|
|
|
|
}
|
2019-07-26 19:28:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
2019-09-20 10:25:51 +00:00
|
|
|
virDomainCheckpointRedefinePrep(virDomainObjPtr vm,
|
2020-11-04 09:10:56 +00:00
|
|
|
virDomainCheckpointDefPtr def,
|
2019-07-26 19:28:44 +00:00
|
|
|
bool *update_current)
|
|
|
|
{
|
|
|
|
char uuidstr[VIR_UUID_STRING_BUFLEN];
|
2019-10-01 06:00:26 +00:00
|
|
|
virDomainMomentObjPtr parent = NULL;
|
2019-07-26 19:28:44 +00:00
|
|
|
|
2019-09-20 10:25:51 +00:00
|
|
|
virUUIDFormat(vm->def->uuid, uuidstr);
|
2019-07-26 19:28:44 +00:00
|
|
|
|
|
|
|
if (virDomainCheckpointCheckCycles(vm->checkpoints, def, vm->def->name) < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (!def->parent.dom ||
|
2019-09-20 10:25:51 +00:00
|
|
|
memcmp(def->parent.dom->uuid, vm->def->uuid, VIR_UUID_BUFLEN)) {
|
2019-07-26 19:28:44 +00:00
|
|
|
virReportError(VIR_ERR_INVALID_ARG,
|
|
|
|
_("definition for checkpoint %s must use uuid %s"),
|
|
|
|
def->parent.name, uuidstr);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (virDomainCheckpointAlignDisks(def) < 0)
|
|
|
|
return -1;
|
|
|
|
|
2019-10-01 06:00:26 +00:00
|
|
|
if (def->parent.parent_name &&
|
|
|
|
(parent = virDomainCheckpointFindByName(vm->checkpoints,
|
|
|
|
def->parent.parent_name))) {
|
2019-10-01 06:10:18 +00:00
|
|
|
if (parent == virDomainCheckpointGetCurrent(vm->checkpoints))
|
2019-10-01 06:00:26 +00:00
|
|
|
*update_current = true;
|
2019-07-26 19:28:44 +00:00
|
|
|
}
|
|
|
|
|
2020-04-01 12:34:15 +00:00
|
|
|
/* set the first redefined checkpoint as current */
|
|
|
|
if (virDomainCheckpointGetCurrent(vm->checkpoints) == NULL)
|
|
|
|
*update_current = true;
|
|
|
|
|
2020-11-04 09:10:56 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
virDomainMomentObjPtr
|
|
|
|
virDomainCheckpointRedefineCommit(virDomainObjPtr vm,
|
|
|
|
virDomainCheckpointDefPtr *defptr,
|
|
|
|
virDomainXMLOptionPtr xmlopt)
|
|
|
|
{
|
|
|
|
virDomainCheckpointDefPtr def = *defptr;
|
|
|
|
virDomainMomentObjPtr other = NULL;
|
|
|
|
virDomainCheckpointDefPtr otherdef = NULL;
|
|
|
|
virDomainMomentObjPtr chk = NULL;
|
|
|
|
|
2019-07-26 19:28:44 +00:00
|
|
|
other = virDomainCheckpointFindByName(vm->checkpoints, def->parent.name);
|
|
|
|
if (other) {
|
|
|
|
otherdef = virDomainCheckpointObjGetDef(other);
|
|
|
|
if (!virDomainDefCheckABIStability(otherdef->parent.dom,
|
|
|
|
def->parent.dom, xmlopt))
|
2020-11-04 09:10:56 +00:00
|
|
|
return NULL;
|
2019-07-26 19:28:44 +00:00
|
|
|
|
|
|
|
/* Drop and rebuild the parent relationship, but keep all
|
|
|
|
* child relations by reusing chk. */
|
|
|
|
virDomainMomentDropParent(other);
|
|
|
|
virObjectUnref(otherdef);
|
|
|
|
other->def = &(*defptr)->parent;
|
|
|
|
*defptr = NULL;
|
2020-11-04 09:10:56 +00:00
|
|
|
chk = other;
|
|
|
|
} else {
|
|
|
|
chk = virDomainCheckpointAssignDef(vm->checkpoints, def);
|
|
|
|
*defptr = NULL;
|
2019-07-26 19:28:44 +00:00
|
|
|
}
|
|
|
|
|
2020-11-04 09:10:56 +00:00
|
|
|
return chk;
|
2019-07-26 19:28:44 +00:00
|
|
|
}
|