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

* docs/news.xml: update for release
* po/*.po*: regenerated

As usual, a bunch of changes slipped through the cracks during the
development cycle. Update the release notes to include at least the
most notable ones.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Update the text to include "luks" as a possible value.

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

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

Commit id '1241e487' used <code>&lt;interface&gt;</code> which
is not valid syntax for a <summary>.

Migration never removes any configuration files on the destination host.
Thus when the domain is already defined on the destination, it will stay
persistent even after migration without --persist.

https://bugzilla.redhat.com/show_bug.cgi?id=1514930Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Emphasise the valid values by wrapping them in <code> and reword the
last sentence so that the invalid value example can be dropped.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1523070

The Fedora mingw support is all merged in Fedora repos, so remove the
outdated link.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Change all links to https:// where the remote site supports it. Fix URLs for
a few packages that moved, and delete entries which appear to be dead.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently we only describe setting the CN field for server certs. This leads
to inevitable pain for users who set it to the fully qualified hostname and
then use a unqualified hostname or IP address to connect in the URI. Describe
the usage of Subject Alt Name extensions, to provide multiple hostnames and
IP addresses. This will help users avoid the classic mistake and is important
future proofing, since at least in browsers, TLS libraries no longer use the
CN field for validation, mandating use of SAN info instead.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The contents of a <rule> are a choice of exactly one union member. The
RNG schema, however, was allowing an arbitrary number of instances of every
union member at once.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

As documented in

  https://libvirt.org/downloads.html#schedule
  https://libvirt.org/downloads.html#numbering

the next release will happen in the middle of January 2018 and,
being the first release of a new year, will bring a brand new
major version number with it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

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

The 'wiremode' attribute exists in a couple of Xen XML files, but no code has
ever parsed that value. It was later added to the RNG schema too, again despite
there not being any code which parses it.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The libxlxml2domconfigdata directory was not covered in the RNG schema
tests. This hid a few bugs in both the libxl XML files and the RNG
schema itself.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Introduce specific a target types with two models for the console
devices (sclp and sclplm) used in s390 and s390x guests, so isa-serial
is no more used for them.

This makes <serial> usable on s390 and s390x guests, with at most only
a single sclpconsole and one sclplmconsole devices usable in a single
guest (due to limitations in QEMU, which will enforce already at
runtime).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449265Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We can finally introduce a specific target model for the pl011 device
used by mach-virt guests, which means isa-serial will no longer show
up to confuse users.

We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that pl011 is not
used for non-mach-virt guests and add a bunch of test cases.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=151292Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We can finally introduce a specific target model for the spapr-vty
device used by pSeries guests, which means isa-serial will no longer
show up to confuse users.

We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that spapr-vty is
not used for non-pSeries guests and add a bunch of test cases.

This commit is best viewed with 'git show -w'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511421Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This information will be used to select, and store in the guest
configuration in order to guarantee ABI stability, the concrete
(hypervisor-specific) model for serial devices.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Our current documentation is missing some information and doesn't
do a great job at explaining how the <serial> and <console> elements
are connected. Let's try to fix that.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since we already have such support for libxl all we need is qemu
driver adjustment. And a test case.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg
entry for a guest to store dump details, necessary to process kernel
dump with KASLR enabled and providing additional kernel details.

In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in
this case it is not backed by a file, but collected by QEMU itself.

Since the device is a singleton and shouldn't use additional hardware
resources, it is presented as a <feature> element in the libvirt
domain XML.

The device is arm/x86 only for now (targets that support fw_cfg+dma).

Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1395248Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

While we have collective knowledge about the support status of various
parts of libvirt, this has never been formally documented, leaving our
users to guess.

Note, this document makes one change to our previous policy. It explicitly
declares the RPC protocol of libvirtd as being a supported interface. THis
accepts the reality that we can a) never change it without breaking compat
with old libvirt.so, b) there are both rust + go impls that are written
against the RPC protocol already.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The XML namespace URI for the QEMU/LXC drivers must use http as the protocol
otherwise it won't match the parser's expectations.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In the definition of virHookQemuOpType and virHookNetworkOpType,
we should use 'stopped' rather than 'shutdown'.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

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

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

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

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

Add two new entries under new features for 3.10.0. One
advertising support for specifying distance between vNUMA cells
and another advertising Xen's support for vNUMA configuration.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add support for describing NUMA distances in a domain's <numa> <cell>
XML description.

Below is an example of a 4 node setup:

  <cpu>
    <numa>
      <cell id='0' cpus='0-3' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='10'/>
          <sibling id='1' value='21'/>
          <sibling id='2' value='31'/>
          <sibling id='3' value='21'/>
        </distances>
      </cell>
      <cell id='1' cpus='4-7' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='21'/>
          <sibling id='1' value='10'/>
          <sibling id='2' value='21'/>
          <sibling id='3' value='31'/>
        </distances>
      </cell>
      <cell id='2' cpus='8-11' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='31'/>
          <sibling id='1' value='21'/>
          <sibling id='2' value='10'/>
          <sibling id='3' value='21'/>
        </distances>
      <cell id='3' cpus='12-15' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='21'/>
          <sibling id='1' value='31'/>
          <sibling id='2' value='21'/>
          <sibling id='3' value='10'/>
        </distances>
      </cell>
    </numa>
  </cpu>

A <cell> defines a NUMA node. <distances> describes the NUMA distance
from the <cell> to the other NUMA nodes (the <sibling>s).  For example,
in above XML description, the distance between NUMA node0 <cell id='0'
...> and NUMA node2 <sibling id='2' ...> is 31.

Valid distance values are '10 <= value <= 255'.  A distance value of 10
represents the distance to the node itself.  A distance value of 20
represents the default value for remote nodes but other values are
possible depending on the physical topology of the system.

When distances are not fully described, any missing sibling distance
values will default to 10 for local nodes and 20 for remote nodes.

If distance is given for A -> B, then we default B -> A to the same
value instead of 20.
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>