Make sure that they're entirely contained within a single line
and that punctuation is used in a way that doesn't make the
resulting HTML look weird.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I've seen examples in the wild of the cluster attribute having
non-zero value on x86_64.
This is obviously quite confusing, but it's the information that
Linux exposes to userspace and we don't really have a way to tell
apart a valid die/cluster ID from a dummy one.
What ultimately matters is that the underlying assumptions about
topology are respected, which they are: in the x86_64 cases that
I have analyzed, for example, each "cluster" contained exactly
one core, so any program that would use this information to
influence guest topology decisions would be unaffected by the
additional level showing up in the hierarchy.
In an attempt to reduce confusion, remove any reference to any
specific value for the attributes having any special meaning
attached to it.
In fact, since there are plans to make it possible to create
guests with multiple CPU clusters on x86_64, rework the note
into a more generic warning cautioning users that an attribute
showing up here does not imply that the same attribute can be
used when defining a guest CPU topology.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
On the guest configuration side, mention that support for the
"dies" attribute was introduced in libvirt 6.1.0 and clarify
that the ability to use non-default values is subject to
architecture and machine limitations.
On the host capabilities side, the documentation was pretty
much entirely missing. It's still far from perfect, but anything
is better than having no information at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that deleting and reverting external snapshots is implemented we can
report that in capabilities so management applications can use that
information and start using external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reverting external snapshot for running VM doesn't work correctly so we
should not report this capability until it is fixed.
This reverts commit de71573bfe.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that deleting and reverting external snapshots is implemented we can
report that in capabilities so management applications can use that
information and start using external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Libvirt supports creating snapshots for a long time but the wording of
the feature may imply that libvirt supports external snapshots in
general but that is not true as users were not able to use APIs to
delete or revert external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the formatcaps.rst we give an example output of capabilities.
Well, there are couple of issues with it:
1) We show <features/> nested under /capabilities/host/cpu.
There's no such element and never was.
2) The ordering of elements is corrupted.
3) There is plenty of elements missing.
Fix these by showing an actual output of 'virsh capabilities' as
obtained on my machine.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The links were broken on the initial conversion of formatdomain.html to
RST which didn't faithfully forward port some of the manually added
anchors.
Fix it by pointing to the closest possible heading.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
