<features><vmcoreinfo/> is a bare boolean XML property. We don't really
use this format anymore and instead prefer tristate <X state=on|off/>
since it's required for modeling on/off/default. If for example future
qemu started enabling vmcoreinfo by default we wouldn't have any way
for the user to turn this off.

Convert it to tristate. For writing XML this is semanticly the same,
<vmcoreinfo/> is processed as <vmcoreinfo state='on'/>.

For apps reading guest XML this is technically an API change,
as they might misinterpret <vmcoreinfo state='off'/>, however this
has only been present in libvirt since 3.10.0 and I don't think any
apps are dependent on this yet
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Enable the TPM CRB to be specified in the domain XML. This
now allows to describe the TPM device like this:

  <tpm model='tpm-crb'>
    <backend type='passthrough'>
      <device path='/dev/tpm0'/>
    </backend>
  </tpm>

Extend the XML schema to also allow tpm-crb.
Extend the documentation.
Add a test case for testing the XML parser and formatter.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NVille Skyttä <ville.skytta@iki.fi>

Panic device has 2 optional sub-elements - <alias> and <address> the
order of which should be interchangeable in the XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1456165Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>

* docs/news.xml: updated for the release
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This reverts commit 209d4d6f.

The wildcard feature has been temporarily removed pending re-impl.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The attribute can be used to disable ROM loading completely
for a device.

This might be needed because, even when the guest is configured
such that the PCI ROM will not be loaded in the PCI BAR, some
hypervisors (eg. QEMU) might still make it available to the
guest in a form (eg. fw_cfg) that some firmwares (eg. SeaBIOS)
will consume, thus not achieving the desired result.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While working on discard feature I've noticed some long lines
that should be wrapped.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This was pointing to an .html.in file rather than to the intended html
document.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Currently the virDrvConnectOpen method is supposed to handle both
opening an explicit URI and auto-probing a driver if no URI is
given. Introduce a dedicated virDrvConnectURIProbe method to enable the
probing functionality to be split from the driver opening functionality.

It is still possible for NULL to be passed to the virDrvConnectOpen
method after this change, because the remote driver needs special
handling to enable probing of the URI against a remote libvirtd daemon.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Historically we have used a bare lxc:/// URI for connecting to LXC. This
is different from our practice with QEMU, UML, Parallels, Libxl, BHyve
and VirtualBox drivers, which all use a path of '/system' or '/session'
or both.

By making LXC allow '/system', we have fully standardized on the use of
either '/system' or '/session' for all the stateful drivers that run
inside libvirtd.

Support for lxc:/// is of course maintained for back-compat.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Historically we have used a bare xen:/// URI for connecting to the
legacy Xen driver. The new libxl Xen driver follows the new practice
of allowing '/system' as a path, as well as bare '/' for compat with
the old Xen driver.

This documents xen:///system as the preferred format for Xen, leaving
xen:/// as an undocumented feature just for back-compat.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Now that the old Xen driver is removed, update the drvxen
page with current information on the libxl drvier and remove
all the old cruft.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Described how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NErik Skultety <eskultet@redhat.com>

Initially, update the UUID field to have the proper format, but
then also changed the type, id, and name fields.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Both pcie-to-pci-bridge and dmi-to-pci-bridge can be used to
create a traditional PCI topology in a pure PCIe guest such as
those using the x86_64/q35 or aarch64/virt machine type;
however, the former should be preferred, as it doesn't need to
obey limitation of real hardware and is completely
architecture-agnostic.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1520821Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The new controller will not yet be used automatically by
libvirt, but at this point it's already possible to configure
a guest to use it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Instead of first listing the models on their own, and then
listing them again grouped by the libvirt release they were
introduced in, have a single list.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NErik Skultety <eskultet@redhat.com>

Using the 'require' value for the 'policy' attribute indicates
that the guest will have the feature so the host CPU does not
need to support it if the hypervisor can emulate it.

E.g. 'x2apic' is emulated by QEMU even if the host does not support it:

    <feature policy='require' name='x2apic'/>
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>

QEMU is the preferred spelling used on QEMU website.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

* docs/news.xml: updated
* po/*.po*: regenerated
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Document support for the virtio-gpu-ccw and
virtio-{keyboard, mouse, tablet}-ccw devices.
Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

QEMU on S390 (since v2.11) can support virtio input ccw devices.
So build the qemu command line for ccw devices.

Also add test cases for virtio-{keyboard, mouse, tablet}-ccw.
Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

QEMU on S390 (since v2.11) can support the virtio-gpu-ccw device,
which can be used as a video device.
Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com>

libvirt-dbus is a new binding that wraps libvirt API into D-Bus calls.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Also describe a possible side-affect due to changes in the default
(unspecified) value from 1000 to 256.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The https:// protocol is much more reliably usable than git:// when
faced with unreasonably strict firewalls. The libvirt.org web server is
now setup to support the smart https:// protocol, which is just as fast
as git://, so change all the docs to use https://
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>