This patch creates two bitmaps, one for macvlan device names and one
for macvtap. The bitmap position is used to indicate that libvirt is
currently using a device with the name macvtap%d/macvlan%d, where %d
is the position in the bitmap. When requested to create a new
macvtap/macvlan device, libvirt will now look for the first clear bit
in the appropriate bitmap and derive the device name from that rather
than just starting at 0 and counting up until one works.

When libvirtd is restarted, the qemu driver code that reattaches to
active domains calls the appropriate function to "re-reserve" the
device names as it is scanning the status of running domains.

Note that it may seem strange that the retry counter now starts at
8191 instead of 5. This is because we now don't do a "pre-check" for
the existence of a device once we've reserved it in the bitmap - we
move straight to creating it; although very unlikely, it's possible
that someone has a running system where they have a large number of
network devices *created outside libvirt* named "macvtap%d" or
"macvlan%d" - such a setup would still allow creating more devices
with the old code, while a low retry max in the new code would cause a
failure. Since the objective of the retry max is just to prevent an
infinite loop, and it's highly unlikely to do more than 1 iteration
anyway, having a high max is a reasonable concession in order to
prevent lots of new failures.

In the following cases nl_recv() was returning the error "No buffer
space available":

* When switching CPUs to offline/online in a system more than 128 cpus
* When using virsh to destroy domain in a system with many interfaces

This patch sets the buffer size for all netlink sockets created by
libnl to 128K and turns on message peeking for nl_recv(). This
eliminates the "No buffer space available" errors seen in the cases
above, and also preempts other future errors the smaller buffers could
have caused.
Signed-off-by: NLeno Hou <houqy@linux.vnet.ibm.com>
Signed-off-by: NLaine Stump <laine@laine.org>

The current code was a little bit odd.  At first we've removed all
possible implicit input devices from domain definition to add them later
back if there was any graphics device defined while parsing XML
description.  That's not all, while formating domain definition to XML
description we at first ignore any input devices with bus different to
USB and VIRTIO and few lines later we add implicit input devices to XML.

This seems to me as a lot of code for nothing.  This patch may look
to be more complicated than original approach, but this is a preferred
way to modify/add driver specific stuff only in those drivers and not
deal with them in common parsing/formating functions.

The update is to add those implicit input devices into config XML to
follow the real HW configuration visible by guest OS.

There was also inconsistence between our behavior and QEMU's in the way,
that in QEMU there is no way how to disable those implicit input devices
for x86 architecture and they are available always, even without graphics
device.  This applies also to XEN hypervisor.  VZ driver already does its
part by putting correct implicit devices into live XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Those tests are in qemuargv2xmltest and it makes sense to include them
also in qemuxml2xmltest and qemuxml2argvtest.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This will enable regenerate functionality for those tests to make
developer lives easier while updating tests.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In dc576025 we renamed virCgroupIsolateMount function to
virCgroupBindMount. However, we forgot about one occurrence in
section of the code which provides stubs for platforms without
support for CGroups like *BSD for instance.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

On the host when we start a container, it will be
placed in a cgroup path of

   /machine.slice/machine-lxc\x2ddemo.scope

under /sys/fs/cgroup/*

Inside the containers' namespace we need to setup
/sys/fs/cgroup mounts, and currently will bind
mount /machine.slice/machine-lxc\x2ddemo.scope on
the host to appear as / in the container.

While this may sound nice, it confuses applications
dealing with cgroups, because /proc/$PID/cgroup
now does not match the directory in /sys/fs/cgroup

This particularly causes problems for systems and
will make it create repeated path components in
the cgroup for apps run in the container eg

  /machine.slice/machine-lxc\x2ddemo.scope/machine.slice/machine-lxc\x2ddemo.scope/user.slice/user-0.slice/session-61.scope

This also causes any systemd service that uses
sd-notify to fail to start, because when systemd
receives the notification it won't be able to
identify the corresponding unit it came from.
In particular this break rabbitmq-server startup

Future kernels will provide proper cgroup namespacing
which will handle this problem, but until that time
we should not try to play games with hiding parent
cgroups.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The VIR_DOMAIN_STATS_VCPU flag to virDomainListGetStats
enables reporting of stats about vCPUs. Currently we
only report the cumulative CPU running time and the
execution state.

This adds reporting of the wait time - time the vCPU
wants to run, but the host scheduler has something else
running ahead of it.

The data is reported per-vCPU eg

$ virsh domstats --vcpu demo
 Domain: 'demo'
   vcpu.current=4
   vcpu.maximum=4
   vcpu.0.state=1
   vcpu.0.time=1420000000
   vcpu.0.wait=18403928
   vcpu.1.state=1
   vcpu.1.time=130000000
   vcpu.1.wait=10612111
   vcpu.2.state=1
   vcpu.2.time=110000000
   vcpu.2.wait=12759501
   vcpu.3.state=1
   vcpu.3.time=90000000
   vcpu.3.wait=21825087

In implementing this I notice our reporting of CPU execute
time has very poor granularity, since we are getting it
from /proc/$PID/stat. As a future enhancement we should
prefer to get CPU execute time from /proc/$PID/schedstat
or /proc/$PID/sched (if either exist on the running kernel)
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

After commit 57177f1a, the cpu-stats command format change to:

CPU0:
    cpu_time         14401.507878990 seconds
    vcpu_time    14378732785511

vcpu_time is not user friendly. After this patch, it will
change back:
CPU0:
    cpu_time         14401.507878990 seconds
    vcpu_time        14378.732785511 seconds

https://bugzilla.redhat.com/show_bug.cgi?id=1301807Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Idioms are usually weird and obscure when translated literally.

Report
error: invalid argument: requested vcpu '100' is not present in the domain
instead of
error: invalid argument: requested vcpu is higher than allocated vcpus

A future patch will refactor the storage of the pinning information in a
way where the ordering will be lost. Order them numerically to avoid
changing the tests later.

virDomainGetCPUStats doesn't support flags so there's no need to carry
the 'flags' variable around. Additionally since the API is poorly
designed I doubt that it will be extended.

Simplify the code by extracting a common code path.

Remove unnecessary condition and variable.

The array doesn't necessarily have the same cardinality as the count of
vCPUs for a domain. Iterating it can cause access beyond the end of the
array.

Counterintuitively the user would end up with a VM with maximum number
of vCPUs available.

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

Next patch will add minimum checking, so use a more generic name.
Refactor return values to the commonly used semantics.

From the code it seems to me that we need user namespace if
configured in domain XML. Otherwise we don't use it at all.
However our tool is more strict about that. Fix this discrepancy.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since the introduction of virt-host-validate tool the set of
cgroup controllers we use has changed so the tool is checking for
some cgroups that we don't need (e.g. net_cls, although I doubt
we have ever used that one) and is not checking for those we
actually use (e.g. cpuset).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

It all works like this. The change-media command dumps domain
XML, finds the corresponding cdrom device we want to change media
in and returns it in the xmlNodePtr form. This way we don't have
to bother with keeping all the subelements or attributes that we
don't care about in the XML that is fed back to libvirt for the
update API.

Now, the problem is we try to be clever here and detect if disk
already has a source (indicated by <source/> subelement).
However, bare fact that the element is there does not mean disk
has source. Make our clever check better.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

We are missing this value for cdrom-image device. It seems like
there's no added value to extend this to other types of disk
devices [1].

1: https://www.redhat.com/archives/libvir-list/2016-January/msg01038.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since 'savevm' was not converted to QMP libvirt has to parse for error
strings in the text monitor output. One of the unhandled errors is
produced when qemu treats a device as unmigratable.

As current qemu actually does support AHCI migration this bug is
applicable only to older versions of qemu.

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

Unify few error conditions into a single error reporting case.

Make bhyveload respect boot order as specified by os.boot section of the
domain XML or by "boot order" for specific devices. As bhyve does not
support a real boot order specification right now, it's just about
choosing a single device to boot from.

These functions are going to be used by the Bhyve driver.

libvirt always resets the MAC address of the physdev used for macvtap
passthrough when the guest is finished with it. This was happening
prior to the 802.1Qb[gh] DISASSOCIATE command, and was quite often
failing, presumably because the driver wouldn't allow the MAC address
to be reset while the association was still active, with a log message
like this:

virNetDevSetMAC:168 : Cannot set interface MAC to 00:00:00:00:00:00 on 'eth13': Cannot assign requested address

This patch changes the order - we now do the 802.1Qb[gh] disassociate
and delete the macvtap interface first, then and reset the MAC
address.

'free' on fedora23 wants to use the Slab field for calculated used
memory. The equation is:

used = MemTotal - MemFree - (Cached + Slab) - Buffers

We already set Cached and Buffers to 0, do the same for Slab and its
related values

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

'free' on Fedora 23 will use MemAvailable to calculate its 'available'
field, but we are passing through the host's value. Set it to match
MemFree, which is what 'free' will do for older linux that don't have
MemAvailable

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

We virtualize bits of /proc/meminfo by replacing host values with
values specific to the container.

However for calculating the final size of the returned data, we are
using the size of the original file and not the altered copy, which
could give garbelled output.

Reverse the conditional at the start so we aren't stuffing all the logic
in an 'if' block

... and consolidate the cmdline/extra/root parsing to facilitate doing
so.

The logic is the same as xl's parse_cmdline from the current xen.git master
branch (e6f0e099d2c17de47fd86e817b1998db903cab61).

On the formatting side switch to producing cmdline= instead of extra=.

Update a few tests and add serveral more.
  - test-cmdline is added to test the exclusive use of cmdline.
  - test-fullvirt-direct-kernel-boot.cfg is updated due to the switch
    on the formatting side and now tests the exclusive use of cmdline=.
  - Tests are added for both paravirt and fullvirt where the .cfg uses
    extra= and (paravirt only) root=. These are format (xl->xml) only
    since the inverse will generate cmdline= hence is not a round trip
    (which was already true if using root=, which used to generate
    extra= on the way back).
  - Tests are added for both paravirt and fullvirt where the .cfg
    declares cmdline= as well as bogus extra= and (paravirt only) root=
    entries which should be ignored. Again these are format only tests
    since the inverse won't include the bogus lines.

The last two bullets here required splitting the DO_TEST macro into
two halves, as is done in the xmconfigtest.c case.

In order to introduce a use of VIR_WARN for logging I had to add
virerror.h and VIR_LOG_INIT.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>

As suggested in a previous thread [0] this patch adds some missing calls
to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info
operations which would otherwise lead to memory leaks.

[0]
https://www.redhat.com/archives/libvir-list/2015-September/msg00519.htmlSigned-off-by: NJoao Martins <joao.m.martins@oracle.com>

Add "Xen XL Config" to the virErrorDomain enum and use it in
src/xenconfig/xen_xl.c.

The virErrorDomain enum has VIR_FROM_XEN, VIR_FROM_XEND,
VIR_FROM_XENSTORE, VIR_FROM_SEXPR, and VIR_FROM_XENXM. Use
these elements in the corresponding .c files. While at it,
remove the VIR_FROM_THIS define in src/xenconfig/xenxs_private.h.

The corresponding event in QEMU is called MIGRATION_PASS.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The VIR_DOMAIN_EVENT_ID_MIGRATION_ITERATION event will be triggered
whenever VIR_DOMAIN_JOB_MEMORY_ITERATION changes its value, i.e.,
whenever a new iteration over guest memory pages is started during
migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When acpi is used to reboot/shutdown qemu domain, qemu emits
SHUTDOWN event. Libvirt uses fakeReboot variable in order to
differentiate reboot or shutdown. fakeReboot value is reseted
to false after domain restart/reset.

When mode=agent is used to reboot qemu domain, qemu doesn't emit
SHUTDOWN event and libvirt doesn't reset fakeReboot value to false.
In this case next 'shutdown -h now' performs reboot. That's why
we don't need to set fakeReboot=true for mode=agent.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We are getting the list of domains and after that we iterate over
the list and try to get status for each domain hoping it will
skip over domains that disappeared meanwhile. However, this
solution to race is bogus - domain may disappear right after we
have checked its state and before we exec another API over it
(e.g. virDomainHasManagedSaveImage()). Also, when printing just
names or uuids (list --name / --uuid) we issue APIs to obtain the
values, however these require no RPC call as all requested info
is in virDomain object that client already has.
Therefore move the status obtaining only to the place that really
needs it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>