When testing stuff you might want to print the XML. Interlocking it with
no metadata adds exactly 0 value to the user.
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
tools/virsh-snapshot.c | 8 +-------
tools/virsh.pod | 4 ++--
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c
index f6bb38bc96..e9f0ee0810 100644
--- a/tools/virsh-snapshot.c
+++ b/tools/virsh-snapshot.c
@@ -369,14 +369,8 @@ cmdSnapshotCreateAs(vshControl *ctl, const vshCmd *cmd)
unsigned int flags = 0;
const vshCmdOpt *opt = NULL;
- if (vshCommandOptBool(cmd, "no-metadata")) {
- if (vshCommandOptBool(cmd, "print-xml")) {
- vshError(ctl, "%s",
- _("--print-xml is incompatible with --no-metadata"));
- return false;
- }
+ if (vshCommandOptBool(cmd, "no-metadata"))
flags |= VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA;
- }
if (vshCommandOptBool(cmd, "halt"))
flags |= VIR_DOMAIN_SNAPSHOT_CREATE_HALT;
if (vshCommandOptBool(cmd, "disk-only"))
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 2e70b68a66..dc39004a66 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -4653,7 +4653,7 @@ metadata is silently lost when the domain quits running (whether
by command such as B<destroy> or by internal guest action).
=item B<snapshot-create-as> I<domain> {[I<--print-xml>]
-| [I<--no-metadata>] [I<--halt>] [I<--reuse-external>]} [I<name>]
+[I<--no-metadata>] [I<--halt>] [I<--reuse-external>]} [I<name>]
[I<description>] [I<--disk-only> [I<--quiesce>]] [I<--atomic>]
[[I<--live>] [I<--memspec> B<memspec>]] [I<--diskspec>] B<diskspec>]...
@@ -4703,7 +4703,7 @@ If I<--no-metadata> is specified, then the snapshot data is created,
but any metadata is immediately discarded (that is, libvirt does not
treat the snapshot as current, and cannot revert to the snapshot
unless B<snapshot-create> is later used to teach libvirt about the
-metadata again). This flag is incompatible with I<--print-xml>.
+metadata again).
If I<--atomic> is specified, libvirt will guarantee that the snapshot
either succeeds, or fails with no changes; not all hypervisors support
--
2.21.0
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
