If no <interface> elements are included in an LXC guest XML
description, then the LXC guest will just see the host's
network interfaces. It is desirable to be able to hide the
host interfaces, without having to define any guest interfaces.

This patch introduces a new feature flag <privnet/> to allow
forcing of a private network namespace for LXC. In the future
I also anticipate that we will add <privuser/> to force a
private user ID namespace.

* src/conf/domain_conf.c, src/conf/domain_conf.h: Add support
  for <privnet/> feature. Auto-set <privnet> if any <interface>
  devices are defined
* src/lxc/lxc_container.c: Honour request for private network
  namespace

numad is an user-level daemon that monitors NUMA topology and
processes resource consumption to facilitate good NUMA resource
alignment of applications/virtual machines to improve performance
and minimize cost of remote memory latencies. It provides a
pre-placement advisory interface, so significant processes can
be pre-bound to nodes with sufficient available resources.

More details: http://fedoraproject.org/wiki/Features/numad

"numad -w ncpus:memory_amount" is the advisory interface numad
provides currently.

This patch add the support by introducing a new XML attribute
for <vcpu>. e.g.

  <vcpu placement="auto">4</vcpu>
  <vcpu placement="static" cpuset="1-10^6">4</vcpu>

The returned advisory nodeset from numad will be printed
in domain's dumped XML. e.g.
  <vcpu placement="auto" cpuset="1-10^6">4</vcpu>

If placement is "auto", the number of vcpus and the current
memory amount specified in domain XML will be used for numad
command line (numad uses MB for memory amount):
  numad -w $num_of_vcpus:$current_memory_amount / 1024

The advisory nodeset returned from numad will be used to set
domain process CPU affinity then. (e.g. qemuProcessInitCpuAffinity).

If the user specifies both CPU affinity policy (e.g.
(<vcpu cpuset="1-10,^7,^8">4</vcpu>) and placement == "auto"
the specified CPU affinity will be overridden.

Only QEMU/KVM drivers support it now.

See docs update in patch for more details.

spice agent-mouse support

Usage:
  <graphics type='spice'>
    <mouse mode='client'|'server'/>
  <graphics/>
Signed-off-by: NOsier Yang <jyang@redhat.com>

Output is still in kibibytes, but input can now be in different
scales for ease of typing.

* src/conf/domain_conf.c (virDomainParseMemory): New helper.
(virDomainDefParseXML): Use it when parsing.
* docs/schemas/domaincommon.rng: Expand XML; rename memoryKBElement
to memoryElement and update callers.
* docs/formatdomain.html.in (elementsMemoryAllocation): Document
scaling.
* tests/qemuxml2argvdata/qemuxml2argv-memtune.xml: Adjust test.
* tests/qemuxml2xmltest.c: Likewise.
* tests/qemuxml2xmloutdata/qemuxml2xmlout-memtune.xml: New file.

The test domain allows <memory>0</memory>, but the RNG was stating
that memory had to be at least 4096000 bytes.  Hypervisors should
enforce their own limits, rather than complicating the RNG.

Meanwhile, some copy and paste had introduced some fishy constructs
in various unit tests.

* docs/schemas/domaincommon.rng (memoryKB, memoryKBElement): Drop
limit that isn't enforced in code.
* src/conf/domain_conf.c (virDomainDefParseXML): Require current
<= maximum.
* tests/qemuxml2argvdata/*.xml: Fix offenders.

Make it obvious to 'dumpxml' readers what unit we are using,
since our default of KiB for memory (1024) differs from qemu's
default of MiB; and differs from our use of bytes for storage.

Tests were updated via:

$ find tests/*data tests/*out -name '*.xml' | \
  xargs sed -i 's/<\(memory\|currentMemory\|hard_limit\|soft_limit\|min_guarantee\|swap_hard_limit\)>/<\1 unit='"'KiB'>/"
$ find tests/*data tests/*out -name '*.xml' | \
  xargs sed -i 's/<\(capacity\|allocation\|available\)>/<\1 unit='"'bytes'>/"

followed by a few fixes for the stragglers.

Note that with this patch, the RNG for <memory> still forbids
validation of anything except unit='KiB', since the code silently
ignores the attribute; a later patch will expand <memory> to allow
scaled input in the code and update the RNG to match.

* docs/schemas/basictypes.rng (unit): Add 'bytes'.
(scaledInteger): New define.
* docs/schemas/storagevol.rng (sizing): Use it.
* docs/schemas/storagepool.rng (sizing): Likewise.
* docs/schemas/domaincommon.rng (memoryKBElement): New define; use
for memory elements.
* src/conf/storage_conf.c (virStoragePoolDefFormat)
(virStorageVolDefFormat): Likewise.
* src/conf/domain_conf.h (_virDomainDef): Document unit used
internally.
* src/conf/storage_conf.h (_virStoragePoolDef, _virStorageVolDef):
Likewise.
* tests/*data/*.xml: Update all tests.
* tests/*out/*.xml: Likewise.
* tests/define-dev-segfault: Likewise.
* tests/openvzutilstest.c (testReadNetworkConf): Likewise.
* tests/qemuargv2xmltest.c (blankProblemElements): Likewise.

This is the new interface type that sets up an SR-IOV PCI network
device to be assigned to the guest with PCI passthrough after
initializing some network device-specific things from the config
(e.g. MAC address, virtualport profile parameters). Here is an example
of the syntax:

  <interface type='hostdev' managed='yes'>
    <source>
      <address type='pci' domain='0' bus='0' slot='4' function='3'/>
    </source>
    <mac address='00:11:22:33:44:55'/>
    <address type='pci' domain='0' bus='0' slot='7' function='0'/>
  </interface>

This would assign the PCI card from bus 0 slot 4 function 3 on the
host, to bus 0 slot 7 function 0 on the guest, but would first set the
MAC address of the card to 00:11:22:33:44:55.

NB: The parser and formatter don't care if the PCI card being
specified is a standard single function network adapter, or a virtual
function (VF) of an SR-IOV capable network adapter, but the upcoming
code that implements the back end of this config will work *only* with
SR-IOV VFs. This is because modifying the mac address of a standard
network adapter prior to assigning it to a guest is pointless - part
of the device reset that occurs during that process will reset the MAC
address to the value programmed into the card's firmware.

Although it's not supported by any of libvirt's hypervisor drivers,
usb network hostdevs are also supported in the parser and formatter
for completeness and consistency. <source> syntax is identical to that
for plain <hostdev> devices, except that the <address> element should
have "type='usb'" added if bus/device are specified:

  <interface type='hostdev'>
    <source>
      <address type='usb' bus='0' device='4'/>
    </source>
    <mac address='00:11:22:33:44:55'/>
  </interface>

If the vendor/product form of usb specification is used, type='usb'
is implied:

  <interface type='hostdev'>
    <source>
      <vendor id='0x0012'/>
      <product id='0x24dd'/>
    </source>
    <mac address='00:11:22:33:44:55'/>
  </interface>

Again, the upcoming patch to fill in the backend of this functionality
will log an error and fail with "Unsupported Config" if you actually
try to assign a USB network adapter to a guest using <interface
type='hostdev'> - just use a standard <hostdev> entry in that case
(and also for single-port PCI adapters).

* src/conf/domain_conf.h: Add new member "target" to struct
  _virDomainDeviceDriveAddress.

* src/conf/domain_conf.c: Parse and format "target"

* Lots of tests (.xml) in tests/domainsnapshotxml2xmlout,
  tests/qemuxml2argvdata, tests/qemuxml2xmloutdata, and
  tests/vmx2xmldata/ are modified for newly introduced
  attribute "target" for address of "drive" type.

Adding a new model for virtio-scsi roughly follows the same scheme
as the previous patch.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

KVM will be able to use a PCI SCSI controller even on POWER.  Let
the user specify the vSCSI controller by other means than a default.

After this patch, the QEMU driver will actually look at the model
and reject anything but auto, lsilogic and ibmvscsi.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NOsier Yang <jyang@redhat.com>

This reverts commit 7b345b69.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.xml

This reverts commit c9abfadf.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-virtio-scsi.xml

Commit b170eb99 introduced a bug: domains that had an explicit
<seclabel type='none'/> when started would not be reparsed if
libvirtd restarted.  It turns out that our testsuite was not
exercising this because it never tried anything but inactive
parsing.  Additionally, the live XML for such a domain failed
to re-validate.  Applying just the tests/ portion of this patch
will expose the bugs that are fixed by the other two files.

* docs/schemas/domaincommon.rng (seclabel): Allow relabel under
type='none'.
* src/conf/domain_conf.c (virSecurityLabelDefParseXML): Per RNG,
presence of <seclabel> with no type implies dynamic.  Don't
require sub-elements for type='none'.
* tests/qemuxml2xmltest.c (mymain): Add test.
* tests/qemuxml2argvtest.c (mymain): Likewise.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.xml: Add file.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.args: Add file.
Reported by Ansis Atteka.

Curently security labels can be of type 'dynamic' or 'static'.
If no security label is given, then 'dynamic' is assumed. The
current code takes advantage of this default, and avoids even
saving <seclabel> elements with type='dynamic' to disk. This
means if you temporarily change security driver, the guests
can all still start.

With the introduction of sVirt to LXC though, there needs to be
a new default of 'none' to allow unconfined LXC containers.

This patch introduces two new security label types

 - default:  the host configuration decides whether to run the
             guest with type 'none' or 'dynamic' at guest start
 - none:     the guest will run unconfined by security policy

The 'none' label type will obviously be undesirable for some
deployments, so a new qemu.conf option allows a host admin to
mandate confined guests. It is also possible to turn off default
confinement

  security_default_confined = 1|0  (default == 1)
  security_require_confined = 1|0  (default == 0)

* src/conf/domain_conf.c, src/conf/domain_conf.h: Add new
  seclabel types
* src/security/security_manager.c, src/security/security_manager.h:
  Set default sec label types
* src/security/security_selinux.c: Handle 'none' seclabel type
* src/qemu/qemu.conf, src/qemu/qemu_conf.c, src/qemu/qemu_conf.h,
  src/qemu/libvirtd_qemu.aug: New security config options
* src/qemu/qemu_driver.c: Tell security driver about default
  config

This patch adds a new element <title> to the domain XML. This attribute
can hold a short title defined by the user to ease the identification of
domains. The title may not contain newlines and should be reasonably short.

 *docs/formatdomain.html.in
 *docs/schemas/domaincommon.rng
        - add schema grammar for the new element and documentation
  *src/conf/domain_conf.c
  *src/conf/domain_conf.h
        - add field to hold the new attribute
        - add code to parse and create XML with the new attribute

Commit 8a09ee41 tickles a bug in libxml2-2.7.6 on RHEL 6.2,
where libxml2 treats the pattern [^\n] as excluding literal
backslash and n, instead of the intended newline, thus failing
to validate any domain name containing 'n'.

* docs/schemas/domaincommon.rng: Use literal newline instead.

 This patch adds a new attribute "rawio" to the "disk" element
 of domain XML. Valid values of "rawio" attribute are "yes"
 and "no".
 rawio='yes' indicates the disk is desirous of CAP_SYS_RAWIO.

 If you specify the following XML:

 <disk type='block' device='lun' rawio='yes'>
  ...
 </disk>

 the domain will be granted CAP_SYS_RAWIO.
 (of course, the domain have to be executed with root privilege)

NOTE:
   - "rawio" attribute is only valid when device='lun'
   - At the moment, any other disks you won't use rawio can use rawio.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

This patch addresses: https://bugzilla.redhat.com/show_bug.cgi?id=781562

Along with the "rombar" option that controls whether or not a boot rom
is made visible to the guest, qemu also has a "romfile" option that
allows specifying a binary file to present as the ROM BIOS of any
emulated or passthrough PCI device. This patch adds support for
specifying romfile to both passthrough PCI devices, and emulated
network devices that attach to the guest's PCI bus (just about
everything other than ne2k_isa).

One example of the usefulness of this option is described in the
bugzilla report: 82576 sriov network adapters don't provide a ROM BIOS
for the cards virtual functions (VF), but an image of such a ROM is
available, and with this ROM visible to the guest, it can PXE boot.

In libvirt's xml, the new option is configured like this:

   <hostdev>
     ...
     <rom file='/etc/fake/boot.bin'/>
     ...
   </hostdev

(similarly for <interface>).

When support for the rombar option was added, it was only added for
PCI passthrough devices, configured with <hostdev>. The same option is
available for any network device that is attached to the guest's PCI
bus. This patch allows setting rombar for any PCI network device type.

After adding cases to test this to qemuxml2argv-hostdev-pci-rombar.*,
I decided to rename those files (to qemuxml2argv-pci-rom.*) to more
accurately reflect the additional tests, and also noticed that up to
now we've only been performing a domainschematest for that case, so I
added the "pci-rom" test to both qemuxml2argv and qemuxml2xml (and in
the process found some bugs whose fixes I squashed into previous
commits of this series).

Add kvmclock timer to documentation, schema and parsers.  Keep the
platform timer first since it is kind of special, and alphabetize
the others when possible (i.e. when it does not change the ABI).
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The domain schema enforced restrictions on the domain name string that
the code doesn't. This patch relaxes the check, leaving the restrictions
on the driver or hypervisor. The only invalid character is a newline.

Applications can now insert custom nodes and hierarchies into domain
configuration XML. Although currently not enforced, applications are
required to use their own namespaces on every custom node they insert,
with only one top-level element per namespace.

This introduces new attribute wrpolicy with only supported
value as immediate. This will be an optional
attribute with no defaults. This helps specify whether
to skip the host page cache.

When wrpolicy is specified, meaning when wrpolicy=immediate
a writeback is explicitly initiated for the dirty pages in
the host page cache as part of the guest file write operation.

Usage:
<filesystem type='mount' accessmode='passthrough'>
  <driver type='path' wrpolicy='immediate'/>
  <source dir='/export/to/guest'/>
  <target dir='mount_tag'/>
</filesystem>

Currently this only works with type='mount' for the QEMU/KVM driver.
Signed-off-by: NDeepak C Shetty <deepakcs@linux.vnet.ibm.com>

The mode can be either of "custom" (default), "host-model",
"host-passthrough". The semantics of each mode is described in the
following examples:

- guest CPU is a default model with specified topology:
    <cpu>
      <topology sockets='1' cores='2' threads='1'/>
    </cpu>

- guest CPU matches selected model:
    <cpu mode='custom' match='exact'>
      <model>core2duo</model>
    </cpu>

- guest CPU should be a copy of host CPU as advertised by capabilities
  XML (this is a short cut for manually copying host CPU specification
  from capabilities to domain XML):
    <cpu mode='host-model'/>

  In case a hypervisor does not support the exact host model, libvirt
  automatically falls back to a closest supported CPU model and
  removes/adds features to match host. This behavior can be disabled by
    <cpu mode='host-model'>
      <model fallback='forbid'/>
    </cpu>

- the same as previous returned by virDomainGetXMLDesc with
  VIR_DOMAIN_XML_UPDATE_CPU flag:
    <cpu mode='host-model' match='exact'>
      <model fallback='allow'>Penryn</model>       --+
      <vendor>Intel</vendor>                         |
      <topology sockets='2' cores='4' threads='1'/>  + copied from
      <feature policy='require' name='dca'/>         | capabilities XML
      <feature policy='require' name='xtpr'/>        |
      ...                                          --+
    </cpu>

- guest CPU should be exactly the same as host CPU even in the aspects
  libvirt doesn't model (such domain cannot be migrated unless both
  hosts contain exactly the same CPUs):
    <cpu mode='host-passthrough'/>

- the same as previous returned by virDomainGetXMLDesc with
  VIR_DOMAIN_XML_UPDATE_CPU flag:
    <cpu mode='host-passthrough' match='minimal'>
      <model>Penryn</model>                        --+ copied from caps
      <vendor>Intel</vendor>                         | XML but doesn't
      <topology sockets='2' cores='4' threads='1'/>  | describe all
      <feature policy='require' name='dca'/>         | aspects of the
      <feature policy='require' name='xtpr'/>        | actual guest CPU
      ...                                          --+
    </cpu>

In case a hypervisor doesn't support the exact CPU model requested by a
domain XML, we automatically fallback to a closest CPU model the
hypervisor supports (and make sure we add/remove any additional features
if needed). This patch adds 'fallback' attribute to model element, which
can be used to disable this automatic fallback.

We support <interface> of type "mcast", "server", and "client",
but the RNG schema for them are missed. Attribute "address" is
optional for "server" type. And these 3 types support
<mac address='MAC'/>, too.

Though <alias> is ignored when defining a domain, it can cause
failure if one validates (e.g. virt-xml-validate) the XML dumped
from a running domain. This patch expose it in domain RNG schema
for all the devices which support it.

"<readonly/>" is supported by filesystem XML, and also documented.

The "unit" attribute of a drive address is optional in the code, so should
also be in the XML schema.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

Adding a new model for virtio-scsi roughly follows the same scheme
as the previous patch.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

KVM will be able to use a PCI SCSI controller even on POWER.  Let
the user specify the vSCSI controller by other means than a default.

After this patch, the QEMU driver will actually look at the model
and reject anything but auto, lsilogic and ibmvscsi.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The new introduced optional attribute "copy_on_read</code> controls
whether to copy read backing file into the image file. The value can
be either "on" or "off". Copy-on-read avoids accessing the same backing
file sectors repeatedly and is useful when the backing file is over a
slow network. By default copy-on-read is off.

In the past, generic SCSI commands issued from a guest to a virtio
disk were always passed through to the underlying disk by qemu, and
the kernel would also pass them on.

As a result of CVE-2011-4127 (see:
http://seclists.org/oss-sec/2011/q4/536), qemu now honors its
scsi=on|off device option for virtio-blk-pci (which enables/disables
passthrough of generic SCSI commands), and the kernel will only allow
the commands for physical devices (not for partitions or logical
volumes). The default behavior of qemu is still to allow sending
generic SCSI commands to physical disks that are presented to a guest
as virtio-blk-pci devices, but libvirt prefers to disable those
commands in the standard virtio block devices, enabling it only when
specifically requested (hopefully indicating that the requester
understands what they're asking for). For this purpose, a new libvirt
disk device type (device='lun') has been created.

device='lun' is identical to the default device='disk', except that:

1) It is only allowed if bus='virtio', type='block', and the qemu
   version is "new enough" to support it ("new enough" == qemu 0.11 or
   better), otherwise the domain will fail to start and a
   CONFIG_UNSUPPORTED error will be logged).

2) The option "scsi=on" will be added to the -device arg to allow
   SG_IO commands (if device !='lun', "scsi=off" will be added to the
   -device arg so that SG_IO commands are specifically forbidden).

Guests which continue to use disk device='disk' (the default) will no
longer be able to use SG_IO commands on the disk; those that have
their disk device changed to device='lun' will still be able to use SG_IO
commands.

*docs/formatdomain.html.in - document the new device attribute value.
*docs/schemas/domaincommon.rng - allow it in the RNG
*tests/* - update the args of several existing tests to add scsi=off, and
 add one new test that will test scsi=on.
*src/conf/domain_conf.c - update domain XML parser and formatter

*src/qemu/qemu_(command|driver|hotplug).c - treat
 VIR_DOMAIN_DISK_DEVICE_LUN *almost* identically to
 VIR_DOMAIN_DISK_DEVICE_DISK, except as indicated above.

Note that no support for this new device value was added to any
hypervisor drivers other than qemu, because it's unclear what it might
mean (if anything) to those drivers.

We already support CPU features with '.' in their name (e.g., sse4.1) so
we should not forbid that in the schema.

When doing security relabeling, there are cases where a per-file
override might be appropriate.  For example, with a static label
and relabeling, it might be appropriate to skip relabeling on a
particular disk, where the backing file lives on NFS that lacks
the ability to track labeling.  Or with dynamic labeling, it might
be appropriate to use a custom (non-dynamic) label for a disk
specifically intended to be shared across domains.

The new XML resembles the top-level <seclabel>, but with fewer
options (basically relabel='no', or <label>text</label>):

<domain ...>
  ...
  <devices>
    <disk type='file' device='disk'>
      <source file='/path/to/image1'>
        <seclabel relabel='no'/> <!-- override for just this disk -->
      </source>
      ...
    </disk>
    <disk type='file' device='disk'>
      <source file='/path/to/image1'>
        <seclabel relabel='yes'> <!-- override for just this disk -->
          <label>system_u:object_r:shared_content_t:s0</label>
        </seclabel>
      </source>
      ...
    </disk>
    ...
  </devices>
  <seclabel type='dynamic' model='selinux'>
    <baselabel>text</baselabel> <!-- used for all devices without override -->
  </seclabel>
</domain>

This patch only introduces the XML and documentation; future patches
will actually parse and make use of it.  The intent is that we can
further extend things as needed, adding a per-device <seclabel> in
more places (such as the source of a console device), and possibly
allowing a <baselabel> instead of <label> for labeling where we want
to reuse the cNNN,cNNN pair of a dynamically labeled domain but a
different base label.

First suggested by Daniel P. Berrange here:
https://www.redhat.com/archives/libvir-list/2011-December/msg00258.html

* docs/schemas/domaincommon.rng (devSeclabel): New define.
(disk): Use it.
* docs/formatdomain.html.in (elementsDisks, seclabel): Document
the new XML.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-override.xml:
New test, to validate RNG.

The RNG for <seclabel> was too strict - if it was present, then it
had to have sub-elements, even if those didn't make sense for the
given attributes.  Also, we didn't have any tests of <seclabel>
parsing or XML output.

In this patch, I added more parsing tests than output tests (since
the output populates and/or reorders fields not present in certain
inputs).  Making the RNG reliable is a precursor to using <seclabel>
variants in more places in the XML in later patches.

See also:
http://berrange.com/posts/2011/09/29/two-small-improvements-to-svirt-guest-configuration-flexibility-with-kvmlibvirt/

* docs/schemas/domaincommon.rng (seclabel): Tighten rules.
* tests/qemuxml2argvtest.c (mymain): New tests.
* tests/qemuxml2xmltest.c (mymain): Likewise.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-*.*: New files.

Original patch by Bharata. Updated to use {1,16} in spaprvioReg based
on example from Eric Blake.
Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>

In QEMU PPC64 we have a network device called "spapr-vlan". We can specify
this using the existing syntax for network devices, however libvirt
currently rejects "spapr-vlan" in virDomainNetDefParseXML() because of
the "-". Fix the code to accept "-".

* src/conf/domain_conf.c (virDomainNetDefParseXML): Allow '-' in
model name, and be more efficient.
* docs/schemas/domaincommon.rng: Limit valid model names to match code.
Based on a patch by Michael Ellerman.

ppc64 as new arch type and pseries as new machine type are
added under <os> ...  </os>.
Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>