This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There are couple of formatting issues. No functional change
though.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Due to the switch of parameters in a call to virDomainShmemDefEquals()
no device was found when looking for device with all the information
except address.  Also fix the indentation.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Make sure that the topology results into a sane number of cpus (up to
UINT_MAX) so that it can be sanely compared to the vcpu count of the VM.

Additionally the helper added in this patch allows to fetch the total
number the topology results to so that it does not have to be
reimplemented later.

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

Use much simpler logic to determine parts of the code to print.

Rather than copy-paste - use a macro

Unfortunately due to how the RNG schema was written keeping the 'value'
and 'value'_max next to each other in the XML causes a schema failure,
so the FORMAT has to write out singly rather than optimizing to write
out both values at once
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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 581b7756.

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>

When creating a copy of virDomainDef we save ourselves the
trouble of writing deep-copy functions and just format and parse
back domain/device XML. However, the XML we are parsing was
already fully formatted - there is no reason to run post parse
callbacks (which fill in blanks - there are none!).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.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>

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

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.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>

This way we'll be able to hotplug with both --live and --config in one
API call.
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>

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>

../../src/conf/domain_conf.c:4425:21: error: potential null pointer dereference [-Werror=null-dereference]
         switch (vcpu->hotpluggable) {
                 ~~~~^~~~~~~~~~~~~~

Validating the vcpu count is more intricate and doing it in the XML
parser will make previously valid configs (with older qemus) vanish.

Now that we have a very similar check in the qemu domain validation
callback we can do it in a more appropriate place.

This basically reverts commit b54de083.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370066

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.

Modify virDomainDefGetVcpuSched to emit an error message if
virDomainDefGetVcpu returns NULL meaning the vcpu could not
be found. Prior to commit id '9cc931f0' the error message
would have been issued in virDomainDefGetVcpu.

When commit id '6dfb4507' refactored where the iothreadsched data was
stored, the error message for when the virDomainIOThreadIDFind failed
to find an iothreadid ("iothreadsched attribute 'iothreads' uses
undefined iothread ids") was lost. This led to the possibility that
someone would try to use it, but receive the generic message "An error
occurred, but the cause is unknown".

This patch adds the error message back so that someone will know that
they have an invalid configuration.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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>