Add startupPolicy attribute for harddisk with type "file",
"block" and "dir". 'requisite' is not supported currently for
harddisk.

This PCI controller, named "dmi-to-pci-bridge" in the libvirt config,
and implemented with qemu's "i82801b11-bridge" device, connects to a
PCI Express slot (e.g. one of the slots provided by the pcie-root
controller, aka "pcie.0" on the qemu commandline), and provides 31
*non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31.

Any time a machine is defined which has a pcie-root controller
(i.e. any q35-based machinetype), libvirt will automatically add a
dmi-to-pci-bridge controller if one doesn't exist, and also add a
pci-bridge controller. The reasoning here is that any useful domain
will have either an immediate (startup time) or eventual (subsequent
hot-plug) need for a standard PCI slot; since the pcie-root controller
only provides PCIe slots, we need to connect a dmi-to-pci-bridge
controller to it in order to get a non-hot-plug PCI slot that we can
then use to connect a pci-bridge - the slots provided by the
pci-bridge will be both standard PCI and hot-pluggable.

Since pci-bridge devices themselves can not be hot-plugged into a
running system (although you can hot-plug other devices into a
pci-bridge's slots), any new pci-bridge controller that is added can
(and will) be plugged into the dmi-to-pci-bridge as long as it has
empty slots available.

This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST"
to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit
the automatically added dmi-to-pci-bridge and pci-bridge devices, and
the "after" xml can include it - this way we are testing if libvirt is
properly adding these devices.

This controller is implicit on q35 machinetypes. It provides 31 PCIe
(*not* PCI) slots as controller 0.

Currently there are no devices that can connect to pcie-root, and no
implicit pci controller on a q35 machine, so q35 is still
unusable. For a usable q35 system, we need to add a
"dmi-to-pci-bridge" pci controller, which can connect to pcie-root,
and provides standard pci slots that can be used to connect other
devices.

There are two ways to use a iSCSI LUN as disk source for qemu.

 * The LUN's path as it shows up on host, e.g.
   /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1

 * The libiscsi URI from the storage pool source element host attribute, e.g.
   iscsi://demo.org:6000/iqn.1992-01.com.example/1

For a "volume" type disk, if the specified "pool" is of iscsi
type, we should support to use the LUN in either of above 2 ways.
That's why to introduce a new XML tag "mode" for the disk source
(libvirt should support iscsi pool with libiscsi, but it's another
new feature, which should be done later).

The "mode" can be either of "host" or "direct". Use "host" to indicate
use of the LUN with the path as it shows up on host. Use "direct" to
indicate to use it with the source pool host URI (future patches may support
to use network type libvirt storage too, e.g. Ceph)

Add a period in seconds to allow/enable statistics gathering from the
Balloon driver for 'virsh dommemstat <domain>'.

<hyperv>
  <spinlocks state='off'/>
</hyperv>

results in:
error: XML error: missing HyperV spinlock retry count

Don't require retries when state is off and use virXPathUInt
instead of virXPathString to simplify parsing.

https://bugzilla.redhat.com/show_bug.cgi?id=784836#c19

This patch introduces new element <idmap> for
user namespace. for example
<idmap>
    <uid start='0' target='1000' count='10'/>
    <gid start='0' target='1000' count='10'/>
</idmap>

this new element is used for setting proc files
/proc/<pid>/{uid_map,gid_map}.

This patch also supports multiple uid/gid elements
setting in XML configuration.

We don't support the semi configuation, user has to
configure uid and gid both.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Add new CPU features for HyperV:
vapic for virtual APIC support
spinlocks for setting spinlock support

<features>
  <hyperv>
    <vapic state='on'/>
    <spinlocks state='on' retries='4096'/>
  </hyperv>
</features>

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

This attribute is going to represent number of queues for
multique vhost network interface. This commit implements XML
extension part of the feature and add one test as well. For now,
we can only do xml2xml test as qemu command line generation code
is not adapted yet.

 -vnc :5900,share=allow-exclusive
allows clients to ask for exclusive access which is
implemented by dropping other connections Connecting
multiple clients in parallel requires all clients asking
for a shared session (vncviewer: -shared switch)

 -vnc :5900,share=force-shared
disables exclusive client access.  Useful for shared
desktop sessions, where you don't want someone forgetting
specify -shared disconnect everybody else.

 -vnc :5900,share=ignore
completely ignores the shared flag and allows everybody
connect unconditionally

QEMU might support more values for "-drive discard", so using Bi-state
values (on/off) for it doesn't make sense.

"on" maps to "unmap", "off" maps to "ignore":

<...>
@var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and
controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap})
requests are ignored or passed to the filesystem.  Some machine types
may not support discard requests.
</...>

The following XML configuration can be used to request all domain's
memory pages to be kept locked in host's memory (i.e., domain's memory
pages will not be swapped out):

      <memoryBacking>
        <locked/>
      </memoryBacking>

"sgio" is only valid for scsi host device.

Unlike disk device, the scsi-generic always writethrough the data,
so no need to introduce a "cache" tag, and set "cache=off".

QEMU introduced "discard" option for drive since commit a9384aff53,

<...>
@var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and
controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap})
requests are ignored or passed to the filesystem.  Some machine types
may not support discard requests.
</...>

This patch exposes the support in libvirt.

QEMU supported "discard" for "-drive" since v1.5.0-rc0:

% git tag --contains a9384aff53
contains
v1.5.0-rc0
v1.5.0-rc1

So this only detects the capability bit using virQEMUCapsProbeQMPCommandLine.

Adding support for new attribute 'websocket' in the '<graphics>'
element, the attribute value is the port to listen on with '-1'
meaning auto-allocation, '0' meaning no websockets.

QEMU introduced command line "-mem-merge=on|off" (defaults to on) to
enable/disable the memory merge (KSM) at guest startup. This exposes
it by new XML:
  <memoryBacking>
    <nosharepages/>
  </memoryBacking>

The XML tag is same with what we used internally for old RHEL.

The <filesystem> element can now accept a <driver type='nbd'/>
as an alternative to 'loop'. The benefit of NBD is support
for non-raw disk image formats.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Extend the <driver> element in filesystem devices to
allow a storage format to be set. The new attribute
uses 'format' to reflect the storage format. This is
different from the <driver> element in disk devices
which use 'type' to reflect the storage format. This
is because the 'type' attribute on filesystem devices
is already used for the driver backend, for which the
disk devices use the 'name' attribute. Arggggh.

Anyway for disks we have

   <driver name="qemu" type="raw"/>

And for filesystems this change means we now have

   <driver type="loop" format="raw"/>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since it's generic enough to be used by other types in future, I
put it in <hostdev> as sub-element, though now it's only used by
scsi host device.

An example of the scsi hostdev XML:

    <hostdev mode='subsystem' type='scsi'>
      <source>
        <adapter name='scsi_host0'/>
        <address bus='0' target='0' unit='0'/>
      </source>
      <address type='drive' controller='0' bus='0' target='4' unit='8'/>
    </hostdev>

Controller is implicitly added for scsi hostdev, though the scsi
controller's model defaults to "lsilogic", which might be not what
the user wants (same problem exists for virtio-scsi disk). It's
the existing problem, will be addressed later.

The device address must be specified manually. Later patch will let
libvirt generate it automatically.

This only introduces the generic XMLs for scsi hostdev, later patches
will add other elements, e.g. <readonly>, <shareable>.
Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com>
Signed-off-by: NOsier Yang <jyang@redhat.com>

A domain's <interface> or <hostdev>, as well as a <network>'s
<forward>, can now have an optional <driver name='kvm|vfio'/>
element. As of this patch, there is no functionality behind this new
knob - this patch adds support to the domain and network
formatter/parser, and to the RNG and documentation.

When the backend is added, legacy KVM PCI device assignment will
continue to be used when no driver name is specified (or if <driver
name='kvm'/> is specified), but if driver name is 'vfio', the new UEFI
Secure Boot compatible VFIO device assignment will be used.

Note that the parser doesn't automatically insert the current default
value of this setting. This is done on purpose because the two
possibilities are functionally equivalent from the guest's point of
view, and we want to be able to automatically start using vfio as the
default (even for existing domains) at some time in the future. This
is similar to what was done with the "vhost" driver option in
<interface>.

Add new controller type 'pci' with models 'pci-root' and 'pci-bridge'.

For pSeries guest in QEMU, NVRAM is one kind of spapr-vio device.
Users are allowed to specify spapr-vio devices'address.
But NVRAM is not supported in libvirt. So this patch is to
add NVRAM device to allow users to specify its address.

In QEMU, NVRAM device's address is specified by
 "-global spapr-nvram.reg=xxxxx".

In libvirt, XML file is defined as the following:

  <nvram>
    <address type='spapr-vio' reg='0x3000'/>
  </nvram>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>

Like what we did for "disk", "filesystem" and "interface", this
introduces sub-element <driver> for "controller", and put the "queues"
into it.

Instead of making a choice between the underscore and camelCase, this
simply changes "num_queues" into "queues", which is also consistent
with Michal's multiple queue support for interface.

The rng schema for <controller> had been non-specific about which
types of controllers allowed which models, and also allowed the
num_queues attribute (since that hasn't been released yet, should we
rename it to "numQueues"?) and <master> subelement to be included for
any controller type. In reality, half of the models are allowed only
for type='scsi', and the other half only for type='usb', num_queues is
allowed only for type='scsi', and <master> only for type='usb'.

This patch makes a separate <group> for type='scsi' and type='usb',
with each group allowing only the appropriate model values, and
allowing num_queue and <master> only when appropriate.

<interleave> also hadn't been specified, forcing a specific order of
subelements, which should never be done. (Note that the <interleave>
had to surround the main element attributes that are in the <group>
subelements, due to one of the <group>s containing a subelement).

Allow VMs to be placed into resource groups using the
following syntax

  <resource>
    <partition>/virtualmachines/production</partition>
  </resource>

A resource cgroup will be backed by some hypervisor specific
functionality, such as cgroups with KVM/LXC.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Supported TPM passthrough XML may look as follows:

    <tpm model='tpm-tis'>
      <backend type='passthrough'>
        <device path='/dev/tpm0'/>
      </backend>
    </tpm>
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
Tested-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>

The definiton of scsi adapter in storagespool.rng (sourceinfoadapter)
can be used by scsi hostdev in later patch. Move it to basictypes.rng.

PortNumber is defined in both domaincommon.rng and storagespool.rng,
simplify it by moving it to basictypes.rng.
Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com>

This updates the definitions and supporting structures in the XML
schema and domain configuration files.
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@freescale.com>

"seclabels" is only valid for 'file' or 'block' type storage volume.

"startupPolicy" is only valid for file type storage volume, otherwise
it fails on starting the domain.

With this patch, one can specify the disk source using libvirt
storage like:

  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source pool='default' volume='fc18.img'/>
    <target dev='vdb' bus='virtio'/>
  </disk>

"seclabels" and "startupPolicy" are not supported for this new
disk type ("volume"). They will be supported in later patches.

docs/formatdomain.html.in:
  * Add documents for new XMLs
docs/schemas/domaincommon.rng:
  * Add rng for new XMLs;
src/conf/domain_conf.h:
  * New struct for 'volume' type disk source (virDomainDiskSourcePoolDef)
  * Add VIR_DOMAIN_DISK_TYPE_VOLUME for enum virDomainDiskType
src/conf/domain_conf.c:
  * New helper virDomainDiskSourcePoolDefParse to parse the 'volume'
    type disk source.
  * New helper virDomainDiskSourcePoolDefFree to free the source def
    if 'volume' type disk.
tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool.xml:
tests/qemuxml2xmltest.c:
  * New test

This introduce a new attribute "num_queues" (same with the good name
QEMU uses) for virtio-scsi controller. An example of the XML:

<controller type='scsi' index='0' model='virtio-scsi' num_queues='8'/>

The corresponding QEMU command line:

-device virtio-scsi-pci,id=scsi0,num_queues=8,bus=pci.0,addr=0x3 \

Split the "resource" define out into multiple smaller
defines, one for each type of resource tuning parameter.
This makes the schema a bit clearer to read
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

It's long enough to have a independant definition.

This does nothing more than adding the new device and capability.
The device is present since QEMU 1.2.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>