Creating ACL rules is not exactly easy and existing examples are pretty
simple. This patch adds a somewhat complex example which defines several
roles. Admins can do everything, operators can do basic operations
on any domain and several groups of users who act as operators but only
on a limited set of domains.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.

The interface type required the addition of a "localaddr" (local
address), this then maps into the following xml and qemu call.

<interface type='udp'>
  <mac address='52:54:00:5c:67:56'/>
  <source address='127.0.0.1' port='11112'>
    <local address='127.0.0.1' port='22222'/>
  </source>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>

QEMU call:
	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222

Notice the xml "local" entry becomes the "localaddr" for the qemu call.

reference:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: regenerated

This patch adds feature for lxc containers to inherit namespaces.
This is very similar to what lxc-tools or docker provides.  Look
for "man lxc-start" and you will find that you can pass command
args as [ --share-[net|ipc|uts] name|pid ]. Or check out docker
networking option in which you can give --net=container:NAME_or_ID
as an option for sharing +namespace.

>From this patch you can add extra libvirt option to share
namespace in following way.

 <lxc:namespace>
   <lxc:sharenet type='netns' value='red'/>
   <lxc:shareipc type='pid' value='12345'/>
   <lxc:shareuts type='name' value='container1'/>
 </lxc:namespace>

The netns option is specific to sharenet. It can be used to
inherit from existing network namespace.

Co-authored: Daniel P. Berrange <berrange@redhat.com>

Parallels driver was renamed to Virtuozzo. Replace old name by new
one for libvirt docs and schemas.

We're using the %.html.tmp for all html files now so drop the unused one
and rather make sure the needed directory exists.

This fixes build failures as described in

    https://www.redhat.com/archives/libvir-list/2015-August/msg00603.html

This will be used with a virtio-scsi controller later on.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This controller can be connected only to a port on a
pcie-switch-upstream-port. It provides a single hotpluggable port that
will accept any PCI or PCIe device, as well as any device requiring a
pcie-*-port (the only current example of such a device is the
pcie-switch-upstream-port).

This controller can be connected only to a pcie-root-port or a
pcie-switch-downstream-port (which will be added in a later patch),
which is the reason for the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
32 ports (slot=0 to slot=31) on the downstream side, which can only
have pci controllers of model "pcie-switch-downstream-port" plugged
into them, which is the reason for the other new connect type
VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.

This controller can be connected (at domain startup time only - not
hotpluggable) only to a port on the pcie root complex ("pcie-root" in
libvirt config), hence the new connect type
VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
will accept any PCI or PCIe device.

New attributes must be added to the controller <target> subelement for
this - chassis and port are guest-visible option values that will be
set by libvirt with values derived from the controller's index and pci
address information.

There are some configuration options to some types of pci controllers
that are currently automatically derived from other parts of the
controller's configuration. For example, in qemu a pci-bridge
controller has an option that is called "chassis_nr"; up until now
libvirt has always set chassis_nr to the index of the pci-bridge. So
this:

  <controller type='pci' model='pci-bridge' index='2'/>

will always result in:

  -device pci-bridge,chassis_nr=2,...

on the qemu commandline. In the future we may decide there is a better
way to derive that option, but even in that case we will need for
existing domains to retain the same chassis_nr they were using in the
past - that is something that is visible to the guest so it is part of
the guest ABI and changing it would lead to problems for migrating
guests (or just guests with very picky OSes).

The <target> subelement has been added as a place to put the new
"chassisNr" attribute that will be filled in by libvirt when it
auto-generates the chassisNr; it will be saved in the config, then
reused any time the domain is started:

  <controller type='pci' model='pci-bridge' index='2'>
    <model type='pci-bridge'/>
    <target chassisNr='2'/>
  </controller>

The one oddity of all this is that if the controller configuration
is changed (for example to change the index or the pci address
where the controller is plugged in), the items in <target> will
*not* be re-generated, which might lead to conflict. I can't
really see any way around this, but fortunately if there is a
material conflict qemu will let us know and we will pass that on
to the user.

This new subelement is used in PCI controllers: the toplevel
*attribute* "model" of a controller denotes what kind of PCI
controller is being described, e.g. a "dmi-to-pci-bridge",
"pci-bridge", or "pci-root". But in the future there will be different
implementations of some of those types of PCI controllers, which
behave similarly from libvirt's point of view (and so should have the
same model), but use a different device in qemu (and present
themselves as a different piece of hardware in the guest). In an ideal
world we (i.e. "I") would have thought of that back when the pci
controllers were added, and used some sort of type/class/model
notation (where class was used in the way we are now using model, and
model was used for the actual manufacturer's model number of a
particular family of PCI controller), but that opportunity is long
past, so as an alternative, this patch allows selecting a particular
implementation of a pci controller with the "name" attribute of the
<model> subelement, e.g.:

  <controller type='pci' model='dmi-to-pci-bridge' index='1'>
    <model name='i82801b11-bridge'/>
  </controller>

In this case, "dmi-to-pci-bridge" is the kind of controller (one that
has a single PCIe port upstream, and 32 standard PCI ports downstream,
which are not hotpluggable), and the qemu device to be used to
implement this kind of controller is named "i82801b11-bridge".

Implementing the above now will allow us in the future to add a new
kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
device, but instead uses something else (which doesn't yet exist, but
qemu people have been discussing it), all without breaking existing
configs.

(note that for the existing "pci-bridge" type of PCI controller, both
the model attribute and <model> name are 'pci-bridge'. This is just a
coincidence, since it turns out that in this case the device name in
qemu really is a generic 'pci-bridge' rather than being the name of
some real-world chip)

"Further" clarification (and testing) shows that using a SCSI Fibre
Channel NPIV device/lun from a storage pool as a <disk type='volume'
device'lun'> will work. So just add that to the allowable options

Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1230179

Rather than calling virDomainHostdevAssignAddress during the parsing
of the XML, move the setting of a default hostdev address to domain/
device post processing.

Since the parse code no longer generates an address, we can remove
the virDomainDefMaybeAddHostdevSCSIcontroller since the call to
virDomainHostdevAssignAddress will attempt to add the controllers
that were not already defined in the XML.

This patch will also enforce that the address type is type 'drive'
when a SCSI subsystem <hostdev> element is provided with an <address>.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

Adding functionality to libvirt that will allow
it query the interface for the availability of RDMA and
tx-udp_tnl-segmentation Offloading NIC capabilities

Here is an example of the feature XML definition:

<device>
<name>net_eth4_90_e2_ba_5e_a5_45</name>
  <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path>
  <parent>pci_0000_08_00_1</parent>
  <capability type='net'>
    <interface>eth4</interface>
    <address>90:e2:ba:5e:a5:45</address>
    <link speed='10000' state='up'/>
    <feature name='rx'/>
    <feature name='tx'/>
    <feature name='sg'/>
    <feature name='tso'/>
    <feature name='gso'/>
    <feature name='gro'/>
    <feature name='rxvlan'/>
    <feature name='txvlan'/>
    <feature name='rxhash'/>
    <feature name='rdma'/>
    <feature name='txudptnl'/>
    <capability type='80203'/>
  </capability>
</device>

The information on companion controllers we give in our documentation is
rather sparse.  For example, it looks like any controller can be used as
a companion one.  Also, when using ich9-uhci2, for example, we are able
to set some sensible defaults, but it might get confusing for the user
as we don't do that for all controller models.

https://bugzilla.redhat.com/show_bug.cgi?id=1069590Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

A helper function for copying error objects.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Update the descriptions for disk and hostdev sgio in order to indicate
not all hypervisors and OS's support this feature
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the query string could be output when displaying the results too

Raised by https://www.xssposed.org/incidents/69566/
Need to escape the user provided query before displaying it back

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated

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

Since an mpath pool contains all the Multipath devices on a host, allowing
more than one defined on a host at a time should be disallowed under the
policy of disallowing duplicate source pools for the host.

Adjust to docs to clarify the Multipath target path value usage for both
the storage driver (only 1 pool per host) and formatstorage references
(ignore the target element in favor of the default target mapping of
/dev/mapper).

This reverts commit 9a8d916e.

Also some changes that were introduced after that commit are fixed to
use 1.2.17 instead of 1.3.0

Don't listen on the admin socket in the daemon and comment out the
admin devel files out of specfile.

Library is still being compiled and installed in order to link easily
without any disturbing modifications to the daemon code.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

While re-reading what I wrote for commit id '785a8940', I realized
I needed to clarify that being able to present as a 'lun', the mode
property for the pool source element needed to be "host" (or empty)
and not "direct".

It was described correctly later in the mode host description, but
this just ensures it's not missed here as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Also move the mention of version numbers for the various PCI
controller models up to the end of the sentence where they are first
given, to avoid confusion.

When support for the pcie-root and dmi-to-pci-bridge buses on a Q35
machinetype was added, I was concerned that even though qemu at the
time allowed plugging a PCI device into a PCIe port, that it might not
be supported in the future. To prevent painful backtracking in the
possible future where this happened, I disallowed such connections
except in a few specific cases requested by qemu developers (indicated
in the code with the flag VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG).

Now that a couple years have passed, there is a clear message from
qemu that there is no danger in allowing PCI devices to be plugged
into PCIe ports. This patch eliminates
VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG and changes the code to always
allow PCI->PCIe or PCIe->PCI connection *when the PCI address is
specified in the config. (For newly added devices that haven't yet
been given a PCI address, the auto-placement still prefers using the
correct type of bus).

In my previous fix (1310b135) I've tried to solve an ordering
issue.  Well, while it worked it has a side effect of keeping a
temporary file around. My patch was buggy in that sense. Solve
this by properly marking the dependency without any side effect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch provides support for the new watchdog model "diag288".
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>

This patch provides support for a new watchdog action "inject-nmi" which
allows to define an inject of a non-maskable interrupt into a guest.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>

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

The acl.html file includes aclperms.htmlinc which is generated.
However, acl.html is generated too from acl.html.tmp. And in fact,
this is the place where the aclperms file is needed. Fix the
dependency in Makefile.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Currently the grammar uses "none" for a "valid" Disk Storage Pool
format type; however, virStoragePoolFormatDisk uses "unknown" so
virt-xml-validate will fail to validate when "unknown" is found

The type='scsi' parameter of an address element is ignored
if placed within a hostdev section, and rejected by the XML
schema used by virt-xml-validate. Remove it from the doc,
and correct a typo in the remaining address arguments.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Defining a domain with a SCSI disk attached via a hostdev
tag and a source address unit value longer than two digits
causes an error when editing the domain with virsh edit,
even if no changes are made to the domain definition.
The error suggests invalid XML, somewhere:

  # virsh edit lmb_guest
  error: XML document failed to validate against schema:
  Unable to validate doc against /usr/local/share/libvirt/schemas/domain.rng
  Extra element devices in interleave
  Element domain failed to validate content

The virt-xml-validate tool fails with a similar error:

  # virt-xml-validate lmb_guest.xml
  Relax-NG validity error : Extra element devices in interleave
  lmb_guest.xml:17: element devices: Relax-NG validity error :
  Element domain failed to validate content
  lmb_guest.xml fails to validate

The hostdev tag requires a source address to be specified,
which includes bus, target, and unit address attributes.
According to the SCSI Architecture Model spec (section
4.9 of SAM-2), a LUN address is 64 bits and thus could be
up to 20 decimal digits long.  Unfortunately, the XML
schema limits this string to just two digits.  Similarly,
the target field can be up to 32 bits in length, which
would be 10 decimal digits.

  # lsscsi -xx
  [0:0:19:0x4022401100000000]  disk    IBM      2107900          3.44 /dev/sda
  # lsscsi
  [0:0:19:1074872354]disk    IBM      2107900          3.44  /dev/sda
  # cat lmb_guest.xml
  <domain type='kvm'>
    <name>lmb_guest</name>
    <memory unit='MiB'>1024</memory>
  ...trimmed...
    <devices>
      <controller type='scsi' model='virtio-scsi' index='0'/>
      <hostdev mode='subsystem' type='scsi'>
        <source>
          <adapter name='scsi_host0'/>
          <address bus='0' target='19' unit='1074872354'/>
        </source>
      </hostdev>
  ...trimmed...

Since the reference unit and target fields are used in
several places in the XML schema, create a separate one
specific for SCSI Logical Units that will permit the
greater length.  This permits both the validation utility
and the virsh edit command to succeed when a hostdev
tag is included.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

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

This type of information defines attributes of a system
baseboard. With one exception: board type is yet not implemented
in qemu so it's not introduced here either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>