The enum converters are defined in the domain_conf.h (so
accessible widely across the code), but on the symbol layer, only
virDomainNetTypeToString was exposed. However, FromString variant
is going to be needed shortly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit b6a2828e introduced new functions to set process scheduler. There
is a small typo in ELSE path for systems where scheduler is not
available.

Also some of the definitions were introduced later in kernel. For
example RHEL-5 is running on kernel 2.6.18, but SCHED_IDLE was introduces
in 2.6.23 [1] and SCHED_BATCH in 2.6.16 [1]. We should not count only on
existence of function sched_setscheduler(), we must also check for
existence of used macros as they might not be defined.

[1] see 'man 7 sched'
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

not yet not -> not yet.
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>

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

While the main storage driver code allows the flag
VIR_STORAGE_VOL_RESIZE_SHRINK to be set, none of the backend
drivers are supporting it. At the very least this can work
for plain file based volumes since we just ftruncate() them
to the new size. It does not work with qcow2 volumes, but we
can arguably delegate to qemu-img for error reporting for that
instead of second guessing this for ourselves:

$ virsh vol-resize --shrink /home/berrange/VirtualMachines/demo.qcow2 2G
error: Failed to change size of volume 'demo.qcow2' to 2G

error: internal error: Child process (/usr/bin/qemu-img resize /home/berrange/VirtualMachines/demo.qcow2 2147483648) unexpected exit status 1: qemu-img: qcow2 doesn't support shrinking images yet
qemu-img: This image does not support resize

See also https://bugzilla.redhat.com/show_bug.cgi?id=1021802

The qemuDomainHelperGetVcpus attempted to report an error when the
vcpupids info was NULL. Unfortunately earlier code would clamp the
value of 'maxinfo' to 0 when nvcpupids was 0, so the error reporting
would end up being skipped.

This lead to 'virsh vcpuinfo <dom>' just returning an empty list
instead of giving the user a clear error.

If a previous commit I fixed the incorrect handling of vcpu pids
for TCG mode QEMU:

  commit b07f3d82
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Thu Dec 18 16:34:39 2014 +0000

    Don't setup fake CPU pids for old QEMU

    The code assumes that def->vcpus == nvcpupids, so when we setup
    fake CPU pids for old QEMU with nvcpupids == 1, we cause the
    later code to read off the end of the array. This has fun results
    like sche_setaffinity(0, ...) which changes libvirtd's own CPU
    affinity, or even better sched_setaffinity($RANDOM, ...) which
    changes the affinity of a random OS process.

The intent was that this would merely disable the ability to set
per-vCPU affinity. It should still have been possible to set VM
level host CPU affinity.

Unfortunately, when you set  <vcpu cpuset='0-1'>4</vcpu>, the XML
parser will internally take this & initialize an entry in the
def->cputune.vcpupin array for every VCPU. IOW this is implicitly
being treated as

  <cputune>
    <vcpupin cpuset='0-1' vcpu='0'/>
    <vcpupin cpuset='0-1' vcpu='1'/>
    <vcpupin cpuset='0-1' vcpu='2'/>
    <vcpupin cpuset='0-1' vcpu='3'/>
  </cputune>

Even more fun, the faked cputune elements are hidden from view when
querying the live XML, because their cpuset mask is the same as the
VM default cpumask.

The upshot was that it was impossible to set VM level CPU affinity.

To fix this we must update qemuProcessSetVcpuAffinities so that it
only reports a fatal error if the per-VCPU cpu mask is different
from the VM level cpu mask.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When initializing a libxl_domain_build_info struct with
libxl_domain_build_info_init(), VNC is enabled by default.  As a
result, VMs configured with no graphics still have VNC enabled.
This behavior is a regression wrt to the legacy Xen driver.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Do not silently ignore its value. LibXL support only one address, so
refuse multiple IPs.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

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

In order for QEMU vCPU (and other) threads to run with RT scheduler,
libvirt needs to take care of that so QEMU doesn't have to run privileged.

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

This function uses sched_setscheduler() function so it works with
processes and threads as well (even threads not created by us, which is
what we'll need in the future).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Prior to commit 7d5bf484 (first appearing in libvirt 1.2.2), the
status XML of a domain's interface was missing a lot of important
information; mainly it just output the config of the interface, plus
the name of the tap device and qemu device alias. Commit 7d5bf484
changed the status XML to include many important bits of information
that were required to make network "hook" scripts useful - bandwidth
information, vlan tag, the name of the bridge (or physical device in
the case of macvtap) that the tap/macvtap device was attached to - the
commit log for 7d5bf484 has a very detailed explanation of the
change. For quick reference - in the example given there, prior to the
change, status XML looked like figure [C]:

      <interface type='network'>
        <source network='testnet' portgroup='admin'/>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

and after the change, it looked like figure [E]:

      <interface type='direct'>
        <source dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

You'll notice that bandwidth info, physdev, and macvtap mode have been
added, but the network and portgroup names are now missing - I didn't
think that this information was of any use once the needed
bandwidth/vlan/etc config had been pulled from the network/portgroup.

I was wrong.

A few months after that change a user on IRC asked what happened to
portgroup in the status XML and described how he used it (more or less
as a tag to decide what external information to use in a hook script
that was run at startup/migration time - see
http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned
to make a patch to re-add portgroup, but life intervened as that was
just prior to a transatlantic move involving several weeks of
"vacation". During this time I somehow forgot to make the patch, and
also mistakenly remembered that I *had* made it.

Subsequent to this, as a part of mprivozn's work to add support for
network-specific hooks, I did re-add the output of the network name in
status XML, but once again completely forgot about portgroup. This was
in commit a3609121 (first appearing in libvirt 1.2.11). This made the
status XML from the above example look like this:

      <interface type='direct'>
        <source network='testnet' dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

*This* patch just adds the portgroup back to the status XML, so the
 same example interface will look like this:

      <interface type='direct'>
        <source network='testnet' portgroup='admin'
                dev='p4p1_0' mode='bridge'/>
        <bandwidth>
            <inbound average='1000' peak='5000' burst='1024'/>
            <outbound average='128' peak='256' burst='256'/>
        </bandwidth>
        <target dev='macvtap0'/>
        <alias name='net0'/>
        <address type='pci' domain='0x0000' bus='0x00'
                 slot='0x03' function='0x0'/>
      </interface>

The result is that the status XML now contains all information about
how the interface is setup (bandwidth, physical device, tap device,
etc), in addition to pointers to its origin (the network and
portgroup).

virDomainGraphicsListenSetAddress() and
virDomainGraphicsListenSetNetwork() both set their respective char* to
NULL directly when asked to set it to NULL, which is okay as long as
it's already set to NULL. If these functions are ever called to clear
a listen object that has a valid string in address or network, it will
end up leaking the old value. Currently that doesn't happen, so this
is just a preemptive strike.

Prior to 0.9.4, libvirt only supported a single listen, and it had to
be an IP address:

   <graphics listen='1.2.3.4' ..../>

Starting with 0.9.4, a graphics element could have a <listen>
subelement (actually the grammar supports multiples, but all of the
drivers only support a single <listen> per <graphics>), and that
listen element can be of type='address' or type='network'. For
type='address', <listen> also has an attribute called 'address' which
contains the IP address for listening:

    <graphics ....>
      <listen type='address' address='1.2.3.4' .../>
    </graphics>

type can also be "network", and in that case listen will have a
"network" attribute which will contain the name of a libvirt
network:

    <graphics ....>
      <listen type='network' network='testnet' .../>
    </graphics>

At domain start (or migrate) time, libvirt will attempt to
find an IP address associated with that network (e.g. the IP address
of the bridge device used by the network, or the physical device
listed in <forward dev='physdev'/>) and fill in that address in the
status XML:

    <graphics ....>
      <listen type='network' network='testnet' address='1.2.3.4' .../>
    </graphics>

In the case that a <graphics> element has a <listen> subelement of
type='address', that listen subelement's "address" attribute is
backfilled into the parent graphics element's "listen" *attribute* for
backward compatibility (so that a management application unaware of
the separate <listen> element can still learn the listen
address). This backfill should be done with the IP learned from
type='network' as well, and that's what this patch does:

    <graphics listen='1.2.3.4' ....>
      <listen type='network' network='testnet' address='1.2.3.4' .../>
    </graphics>

This is a continuation of the fix for:

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

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

virsh's domdisplay command looks in /domain/devices/graphics/@listen
of the domain's XML for the listen address, however for listen
type='network' (added in libvirt 0.9.4), the <graphics> element
doesn't have a listen attribute, but has a <listen> subelement,
*still* with no address (this is the inactive XML):

 <graphics type='spice' autoport='yes' keymap='en-us'>
  <listen type='network' network='default'/>
 </graphics>

However, at domain start time the <listen> subelement gets its address
attribute filled in once libvirt figures out the IP address associated
with the named network (this is the status XML):

 <graphics type='spice' port='5901' autoport='yes' keymap='en-us'>
  <listen type='network' address='192.168.122.1' network='default'/>
 </graphics>

So in these cases, we need to look at
/domain/devices/graphics/listen/@address instead.

Even though another patch is being pushed that will backfill
listen/@address into @listen, this patch is still useful, as it fixes
domdisplay for cases of a new virsh (with this patch) connecting to a
libvirtd that is newer than 0.9.4 but doesn't have the followup patch.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NLaine Stump <laine@laine.org>

Commit c5b6a4a5 forget to update also this mock function.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In the event we're falling into the code that tries to create the file
in a forked environment (VIR_FILE_OPEN_FORK) we pass different mode bits,
but those are never set because the virFileOpenForceOwnerMode has a check
if the OPEN_FORCE_MODE bit is set before attempting to change the mode.

Since this is a special case it seems reasonable to set u+rw,g+rw,o

Rather than have a dummy waitpid loop and return of the failure status
from recvfd, adjust the logic to save the recvfd error & fd and then
in priority order:

- if waitpid failed, use that errno value
- waitpid succeeded, but if the child exited abnormally, report failure
(use EACCES to report as return failure, since either EACCES or EPERM is
what caused us to fall into the fork+setuid path)
- waitpid succeeded, but if the child reported non-zero status, report
failure (use the errno value that the child encoded into exit status)
- waitpid succeeded, but if recvfd failed, report recvfd_errno
- waitpid and recvfd succeeded, use the fd

NOTE: Original logic to retry the open and force owner mode was
"documented" as only being attempted if we had already tried opening
with the fork+setuid, but checked flags vs. VIR_FILE_OPEN_NOFORK which
is counter to how we would get to that point. So that code was removed.

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

When we attempt to migrate a vm with a migrateuri that has no scheme:

 # virsh migrate test4 --live qemu+ssh://lhuang/system --migrateuri 127.0.0.1

target libvirtd will crash because uri->scheme is NULL in
qemuMigrationPrepareDirect on this line:

     if (STRNEQ(uri->scheme, "tcp") &&

Add a value check before this line. Also fix a bug like this in
doNativeMigrate, that could only happen when destination libvirtd
returned an incorrect URI.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The function virDomainVcpuPinDel() used vcpupin_list to stand for
def->cputune.vcpupin, which made the codes more readable.
However, in this function, it will realloc vcpupin_list later.
As the definition of realloc(), it may free vcpupin_list and then
points it to a new-realloced address, but def->cputune.vcpupin doesn't
point to the new address(it's freed however).
Thus,
1) When we refer to the def->cputune.vcpupin afterwards, which was freed
by realloc(), an INVALID READ occurs, and libvirtd may crash.
2) As no one will use vcpupin_list any more, and no one frees it(it's just
alloced by realloc()), memory leak occurs.

Part of the valgrind logs are shown as below:
==1837== Thread 15:
==1837== Invalid read of size 8
==1837==    at 0x5367337: virDomainDefFormatInternal (domain_conf.c:18392)
        which is : virBufferAsprintf(buf, "<vcpupin vcpu='%u' ",
                          def->cputune.vcpupin[i]->vcpuid);
==1837==    by 0x536966C: virDomainObjFormat (domain_conf.c:18970)
==1837==    by 0x5369743: virDomainSaveStatus (domain_conf.c:19166)
==1837==    by 0x117B26DC: qemuDomainPinVcpuFlags (qemu_driver.c:4586)
==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)
==1837==    by 0x171E6E: virNetServerHandleJob (virnetserver.c:193)
==1837==    by 0x5318E78: virThreadPoolWorker (virthreadpool.c:145)
==1837==  Address 0x12ea2870 is 0 bytes inside a block of size 16 free'd
==1837==    at 0x4C291AC: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1837==    by 0x52A3D14: virReallocN (viralloc.c:245)
==1837==    by 0x52A3DFB: virShrinkN (viralloc.c:372)
==1837==    by 0x52A3F57: virDeleteElementsN (viralloc.c:503)
==1837==    by 0x533939E: virDomainVcpuPinDel (domain_conf.c:15405)  //doReset为true时才会进到。
==1837==    by 0x117B2642: qemuDomainPinVcpuFlags (qemu_driver.c:4573)
==1837==    by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803)
==1837==    by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762)
==1837==    by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740)
==1837==    by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==1837==    by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307)
==1837==    by 0x171B83: virNetServerProcessMsg (virnetserver.c:172)

Steps to reproduce the problem:
1) use virDomainPinVcpuFlags() to pin a guest's vcpu to all the pcpus
of the host.

This patch uses def->cputune.vcpupin instead of vcpupin_list to do the
realloc() job, to avoid invalid read or memory leaking.
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: Yue Wenyuan <yuewenyuan@huawei.com@huawei.com>

Parser checks for per-domain seclabel duplicates, so it would be nice if
it checked for per-device seclabel duplicates the same way

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

In our RNG schema we do allow multiple (different) seclabels per-domain,
but don't allow this for devices, yet we neither have a check in our XML parser,
nor in a post-parse callback. In that case we should allow multiple
(different) seclabels for devices as well.

Commit c5ee5cfb added a job to SetSchedulerParameters, but
forgot to change one label in the SCHED_RANGE_CHECK macro.

Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Export the required helpers and add backend code to hotplug RNG devices.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Add support for using the attach/detach device APIs on the inactive
configuration to add RNG devices.

The helpers will be useful when implementing hotplug and coldplug of
random number generator devices.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NLuyao Huang <lhuang@redhat.com>

As the RNG device is using an -object as backend refactor the code to
use the JSON to commandline generator so that we can reuse the code
later in hotplug.

Move the alias name right after the object type for rng-egd backend so
that we can later use the JSON to commandline generator to create the
command line.

Libvirt didn't prefix the random number generator backend object alias
with any string thus the device alias and object alias were identical.

To avoid possible problems, rename the alias for the backend object and
tweak tests to comply with the change.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Rename qemuBuildRNGDeviceArgs to qemuBuildRNGDevStr and change the
return type so that it can be reused in the device hotplug code later.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This function is used to assign an alias for a RNG device. It will be
later reused when hotplugging RNGs.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

When adding devices to the definition it's useful to check whether the
devices don't reside on a conflicting address. This patch adds a helper
that iterates all device info and compares the addresses with the given
info.

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

Change the wording in the device-address-part of the docmunentation since
the ccw bus address support added to the optional address parameter of
virsh attach-disk for S390.
Signed-off-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

Adding ccw bus address support to the optional address parameter of virsh
attach-disk. The format used is ccw:cssid. ssid.devno, e.g.
ccw:0xfe.0x0.0x0201

Virtio-ccw devices must have their cssid set to 0xfe.
Signed-off-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>