If a panic device is being defined without a model in a domain
the default value is always overwritten with model ISA. An ISA
bus does not exist on S390 and therefore specifying a panic device
results in an unsupported configuration.
Since the S390 architecture inherently provides a crash detection
capability the panic device should be defined in the domain xml.
This patch adds an s390 panic device model and prevents setting a
device address on it.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
There were few things done in the nodedev code but we were lacking tests
for it. And because of that we missed that the schema was not updated
either. Fix the schema and add various test files to show the schema
is correct.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This reverts commit 690969af9c, which
added the domain config parts to support a "peer" attribute in domain
interface <ip> elements.
It's being removed temporarily for the release of libvirt 1.3.4
because the feature doesn't work, and there are concerns that it may
need to be modified in an externally visible manner which could create
backward compatibility problems.
Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45
However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:
http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html
Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely
https://bugzilla.redhat.com/show_bug.cgi?id=1074464
All top-level functions have been moved to this class.
On top of that, the app.warning() method has been defined,
so that calls to it - already present in rebuild() - can
actually succeed.
Since commit d195cffa2e, both $(srcdir) and $(abs_builddir)
are passed to the apibuild.py script; however, since the
former is a relative path and the latter an absolute one, the
script might not be able to detect whether they point to the
same location.
Pass both as relative paths to avoid the issue.
When describing attributes and elements, we mostly stick to
a certain pattern; however, there are a few cases when the
information is not presented in the usual way.
Since there doesn't seem to be any reason not to follow the
tried and true formula, rework those bits to fit the rest of
the documentation.
Commit 61b070cf20 cleaned up a number of cases where the <dt>
element was used to document symbols, but the symbol itself was
not inside a <code> element.
To make sure we don't end up having to clean up again a few
months from now, introduce a syntax-check rule that can spot
such mistakes.
All existing exceptions are marked as such, with either file
or line granularity depending on the case.
libvirt-common.h is generated into builddir/include/libvirt. apibuild.py
only operated on srcdir/inlcude/libvirt. With VPATH build
srcdir/docs/libvirt-libvirt-common.html would not get generated and make
RPM failed.
Add bolding for <dt><code> elements to make them "stick out" on the
page rather that just a stream of text where the elements only differ
by slightly different font style.
IGMP is used on IPv4 networks tp setup multicast group memberships. On
IPv6, this job is done by Multicast Listener Discovery (MLD), which
uses ICMPv6 packets rather than its own IP protocol number like IGMP.
The nwfilter documentation lists "igmp-ipv6" as one of the possible
protocols, but this is ignored (and stripped from the xml). This patch
removes that erroneous reference.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1038888
Since commit f5d9c5d00c moved the virTypedParam stuff into
libvirt-common we did not generate any docs for them and neither did we
populate them into libvirt-api.xml. This broke the sanity check in
libvirt python. Fix it by generating docs for libvirt-common.h too.
Some macros don't make sense to be documented at all. Add infrastructure
to the web/api generator and add VIR_DEPRECATED and VIR_EXPORT_VAR as
macros we should not document.
Our uninstall script is not exact counterpart of install one.
Therefore we are leaving couple of files behind. This should not
happen.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While we could leave it behind as an indelible sign that libvirt
has been running on host, other users might not be that fond of
it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Ploop image consists of directory with two files: ploop image itself,
called root.hds and DiskDescriptor.xml that contains information about
ploop device: https://openvz.org/Ploop/format.
Such volume are difficult to manipulate in terms of existing volume types
because they are neither a single files nor a directory.
This patch introduces new volume type - ploop. This volume type is used
by ploop volume's exclusively.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).
Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).
This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.
The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).
Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.
This is especially useful for "bus", since the bus of a device's pci
address is matched to the "index" of a controller to determine which
bus it will be connected to, and "index" is always specified in
decimal - being able to specify both in decimal at least makes it
easier to assure a device is being assigned to the correct bus when it
is added. For the other attributes, it is just a convenience.
(MB: the parser already allows for any of these attributes to be given
in decimal, and there are even examples floating around on the
internet that give them in decimal rather than hex (written in the
days before virsh did schema validation on all XML). This only updates
the schema to match the parser.)
nwfilter.rng defines uint16range and uint32range, but in a different
manner (it also allows a variable name as the value, rather than just
a decimal or hex number). I wanted to add uint16range to
basictypes.rng, but my desired definition was parallel to those for
uint8range and uint24range which are defined in basictypes.rng - they
*don't* allow a variable name for the value.
The simplest path to make everyone happy is to make the "plain"
versions in basictypes.rng have simpler names - "uint8", "uint16", and
"uint24". This patch renames uint8range and uint24range to uint8 and
uint24, while the next patch will add uint16.
The pcie-switch-downstream-port and pcie-root-port controllers have
only a single slot, numbered 0, and the greate majority of all guest
PCI devices are plugged into function 0 of whatever slot they're
using. The parser makes these optional, setting them to 0 when not
specified, and it's logical for the schema to also make them optional.
This cleanups the documentation, reformat some of the paragraphs to use
<p> instead of </br> and rewrites the listen part to be more extendable.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
According to MDN[1], 'margin-left' and similar CSS properties,
including 'margin-right', cannot be applied to the '::first-line'
pseudo-element, so this rule will never have any effect and can
be safely removed.
[1] https://developer.mozilla.org/en/docs/Web/CSS/::first-line
