This breaks vCPU hotplug, because when starting a domain, we
create a copy of domain definition (which becomes live XML) and
during the post parse callbacks we might adjust some tunings so
that vCPU hotplug is possible.

This reverts commit c0f90799.

Certain operations may make the vcpu order information invalid. Since
the order is primarily used to ensure migration compatibility and has
basically no other user benefits, clear the order prior to certain
operations and document that it may be cleared.

All the operations that would clear the order can still be properly
executed by defining a new domain configuration rather than using the
helper APIs.

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

So far only guestfwd and virtio were supported. Add an additional
for Xen as libxl channels create a Xen console visible to the guest.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This is an internal flag that prevents our two entry points to
XML parsing (virDomainDefParse and virDomainDeviceDefParse) from
running post parse callbacks. This is expected to be used in
cases when we already have full domain/device XML and we are just
parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseString.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseXML and subsequently virDomainDefPostParse too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Return whether the live or persistent definition was returned. Sometimes
it's necessary to base the decisions on this.

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

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

QEMU added another virtio-net tunable [1]. It basically allows
users to set the size of RX virtio ring. But because virtio-net
uses two separate ring buffers to pass data from/to guest they
named it explicitly rx_queue_size. We should expose it in our XML
too.

1: http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg02029.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the incoming XML defined a path to a TLS X.509 certificate environment,
add the necessary 'tls-creds-x509' object to the VIR_DOMAIN_CHR_TYPE_TCP
character device.

Likewise, if the environment exists the hot unplug needs adjustment as
well.  Note that all the return ret were changed to goto cleanup since
the cfg needs to be unref'd
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The code for replacing domain's transient definition with the persistent
one is repeated in several places and we'll need to add one more. Let's
make a nice helper for it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Since the domain lock is not held during preparation of an external XML
config, it is possible that the value can change resulting in unexpected
failures during ABI consistency checking for some save and migrate
operations.

This patch adds a new flag to skip the checking of the cur_balloon value
and then sets the destination value to the source value to ensure
subsequent checks without the skip flag will succeed.

This way it is protected from forges and is keeped up to date too.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Individual vCPU hotplug requires us to track the state of any vCPU. To
allow this add the following XML:

<domain>
  ...
  <vcpu current='2'>3</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
    <vcpu id='1' enabled='no' hotpluggable='yes'/>
  </vcpus>
  ...

The 'enabled' attribute allows to control the state of the vcpu.
'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
allows to specify the order to add the vcpus.

This element will control secure boot implemented by some
firmwares. If the firmware used in <loader/> does support the
feature we must tell it to the underlying hypervisor. However, we
can't know whether loader does support it or not just by looking
at the file. Therefore we have to have an attribute to the
element where users can tell us whether the firmware is secure
boot enabled or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Add the definitions to allow for viewing/setting cgroup period and quota
limits for IOThreads.

This is similar to the work done for emulator quota and period by
commit ids 'b65dafa8' and 'e051c482'.

Being able to view/set the IOThread specific values is related to more
recent changes adding global period (commmit id '4d92d58f') and global
quota (commit id '55ecdae0') definitions and qemu support (commit id
'4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow
the IOThread value in the cgroup hierarchy was set "outside of libvirt"
to a value that is incompatible with the global value.

Allowing control over IOThread specific values provides the capability
to alter the IOThread values as necessary.

According to libxl implementation, it supports pvusb
controller of version 1.1 and version 2.0, and it
supports two types of backend, 'pvusb' (dom0 backend)
and 'qusb' (qemu backend). But currently pvusb backend
is not checked in yet.

To match libxl support, extend usb controller schema
to support two more models: qusb1 (qusb, version 1.1)
and 'qusb2' (qusb version 2.0).
Signed-off-by: NChunyan Liu <cyliu@suse.com>

Nothing in the code path after the removed call has needs/uses the alias
anyway (as would be the case for command line building or talking to monitor).
The alias is VIR_FREE'd in virDomainDeviceInfoClear which is called for any
device that needs/uses an alias via virDomainDeviceDefFree or virDomainDefFree
as well as during virDomainDeviceInfoFree for host devices.

For persistent domains, the domain definition (including aliases) gets
freed a few screens later when it's replaced with newDef.

For transient domains, the definition is freed/unref'd along with the
virDomainObj a few moments later.

Since commit id 'fb063500' these are no longer called, so remove them

New type of <devices> <filesystem type= 'volume'> is introduced.
This patch allows to use volumes for storing the filesystem, that is
accessed from the guest e.g. root directory for container.

To take advantage of volumes as a backend of filesystem volume
and pool names should be specified:
<filesystem type= 'volume'>
 <source pool='pool name' volume='volume name'/>
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

A device with an attribute 'model', with just one model
so far:

<devices>
  ...
  <iommu model='intel'/>
</devices>

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

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.

Our copy functions format and parse XML thus are not able to copy data.
Annotate the private data pointers that this is happening.

Libxl is the last user and I don't have the toolchain prepared to
compile the libxl driver. Move it to the libxl driver to avoid having to
refactor the code.

Few arguments of the function are not necessary any more which leads to
some cleanups. The 'uri' argument had a stray ATTRIBUTE_UNUSED.

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

(This patch had been pushed earlier in
commit fe6a7789, but was reverted in
commit d6584565 because it had been
accidentally pushed during the freeze for release 2.0.0)

A helper that will execute a callback on every USB device
in the domain definition.

With an ability to skip USB hubs, since we will want to treat
them differently in some cases.

Some code paths already assume that it is allocated since it was always
allocated by virDomainPerfDefParseXML. Make it member of virDomainDef
directly so that we don't have to allocate it all the time.

This fixes crash when attempting to connect to an existing process via
virDomainQemuAttach since we would not allocate it in that code path.

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

This reverts commit fe6a7789.

This feature was accidentally pushed in the feature freeze.

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types, and 2) we can retain the info when set to
an invalid interface type all the way through to validation and report
a proper error, rather than just ignoring it (which is currently what
happens for many other type-specific settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

All the same information was already there, just in slightly different
places in the virDomainNetDef.

a.k.a. <hostdev mode='capabilities' type='net'>.

This replaces the existing nips, ips, nroutes, and routes with a
single virNetDevIPInfo, and simplifies the code by calling that
object's parse/format/clear functions instead of open coding.