If any disk of a VM was involved in a (copy) block job we refused to do
a snapshot. As not only copy jobs interlock snapshots and the
interlocking is applicable to individual disks only we can make the
check in a more individual fashion and interlock all block job types
supported by libvirt.

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

Include them in the files that need them instead.

After splitting out most of virsh command, some includes
are no longer needed.

Some files have the libXML includes despite not needing them.

* "verify.h" from gnulib is included in internal.h
* <sys/select.h> is no longer needed
  added by commit da196338 to use fd_set in virExec prototype

No longer needed after commit dd477238

Unused since commit bc2f42a0.

Move it under the WITHOUT_DRIVER_MODULES #ifdef
and start using it again.

In the order of appearance:

* MAX_LISTEN - never used
  added by 23ad665c (qemud) and addec57 (lock daemon)

* NEXT_FREE_CLASS_ID - never used, added by 07d1b6b5

* virLockError - never used, added by eb8268a4

* OPENVZ_MAX_ARG, CMDBUF_LEN, CMDOP_LEN
  unused since the removal of ADD_ARG_LIT in d8b31306

* QEMU_NB_PER_CPU_STAT_PARAM - unused since 897808e7

* QEMU_CMD_PROMPT, QEMU_PASSWD_PROMPT - unused since 1dc10a7b

* TEST_MODEL_WORDSIZE - unused since c25c18f7

* TEMPDIR - never used, added by 714bef5b

* NSIG - workaround around old headers
  added by commit 60ed1d2a
  unused since virExec was moved by commit 02e86910

* DO_TEST_PARSE - never used, added by 9afa0060

* DIFF_MSEC, GETTIMEOFDAY - unused since eee6eb66

Use virBitmapNewCopy instead of a combination of virBitmapNew and
virBitmapCopy.

The function doesn't make sense. There's a simpler way to achieve the
same.

The function doesn't make sense. There's a simpler way to achieve the
same.

The function is used to set cpuset.cpus in various other helpers.

Two places would call to qemuPrepareCpumap() with priv->autoNodeset to
convert it to a cpuset. Remove the function and use the prepared cpuset
automatically.

When the default cpuset or automatic numa placement is used libvirt
would place the whole parent cgroup in the specified cpuset. This then
disallowed to re-pin the vcpus to a different cpu.

This patch pins only the vcpu threads to the default cpuset and thus
allows to re-pin them later.

The following config would fail to start:
<domain type='kvm'>
  ...
  <vcpu placement='static' cpuset='0-1' current='2'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='2-3'/>
    ...

This is a regression since a39f69d2.

Use the default or auto cpuset if they are provided for IOThreads.

The automatic cpuset can be stored along with automatic nodeset and it
does not have to be recreated when used.

- docs/news.html.in libvirt.spec.in: update for the release
- po/*.po*: regenerated localization

This would have caught the bug fixed by Wei's commit c13de016Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NEric Blake <eblake@redhat.com>

When the synchronous pivot option is selected, libvirt would not update
the backing chain until the job was exitted. Some applications then
received invalid data as their job serialized first.

This patch removes polling to wait for the ABORT/PIVOT job completion
and replaces it with a condition. If a synchronous operation is
requested the update of the XML is executed in the job of the caller of
the synchronous request. Otherwise the monitor event callback uses a
separate worker to update the backing chain with a new job.

This is a regression since 1a92c719

When the ABORT job is finished synchronously you get the following call
stack:
 #0  qemuBlockJobEventProcess
 #1  qemuDomainBlockJobImpl
 #2  qemuDomainBlockJobAbort
 #3  virDomainBlockJobAbort

While previously or while using the _ASYNC flag you'd get:
 #0  qemuBlockJobEventProcess
 #1  processBlockJobEvent
 #2  qemuProcessEventHandler
 #3  virThreadPoolWorker

Later on I'll be adding a condition that will allow to synchronise a
SYNC block job abort. The approach will require this code to be called
from two different places so it has to be extracted into a helper.

Commit 1a92c719 moved code to handle block job events to a different
function that is executed in a separate thread. The caller of
processBlockJob handles locking and unlocking of @vm, so the we should
not do it in the function itself.

The block copy API takes the speed in bytes/s rather than MiB/s that was
the prior approach in virDomainBlockRebase. We correctly converted the
speed to bytes/s in the old API but we still called the common helper
virDomainBlockCopyCommon with the unadjusted variable.

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

The overflow check for the bandwidth parameter did not jump to the
cleanup label.

Additionally virsh should use vshError instead of virReportError.

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

When getting info on NUMA parameters for domain,
virCgroupGetCpusetMems() may be called. However, as of 43b67f2e
the call is guarded by check if memory controller is present.
Even though it may be not obvious instantly, NUMA parameters are
stored under cpuset controller. Therefore the check needs to look
like this:

  if (!virCgroupHasController(priv->cgroup,
                              VIR_CGROUP_CONTROLLER_CPUSET) ||
      virCgroupGetCpusetMems(priv->cgroup, &nodeset) < 0) {
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Throughout our code, the virCgroupController enum is used in two ways.
First as an index to an array of cgroup controllers:

struct virCgroup {
    char *path;

    struct virCgroupController controllers[VIR_CGROUP_CONTROLLER_LAST];
};

Second way is that when calling virCgroupNew() a bitmask of the enum
items can be passed to selectively detect only some controllers. For
instance:

int
virCgroupNewVcpu(virCgroupPtr domain,
                 int vcpuid,
                 bool create,
                 virCgroupPtr *group)
{
    ...
    controllers = ((1 << VIR_CGROUP_CONTROLLER_CPU) |
                   (1 << VIR_CGROUP_CONTROLLER_CPUACCT) |
                   (1 << VIR_CGROUP_CONTROLLER_CPUSET));

    if (virCgroupNew(-1, name, domain, controllers, group) < 0)
        goto cleanup;
}

Even though it's highly unlikely that so many new controllers will be
invented so that we would overflow when constructing the bitmask, it
doesn't hurt to check at compile time either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When creating new internal representation of cgroups, all passed
arguments are logged. Well, except for two: pid and pointer for
return value. Lets log them too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The function has no argument named @name rather than @path
instead.  The comment is, however, referring to @name while it
should have been referring to @path really.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 2f36e694 (re-)introduced a use of an identifier 'interface',
which causes this build failure on mingw:

../../tools/virsh-domain-monitor.c: In function 'cmdDomIfAddr':
../../tools/virsh-domain-monitor.c:2233:17: error: expected identifier or '(' before 'struct'
     const char *interface = NULL;
                      ^

See also commit 6512c8b4.  Sadly, I'm not quite sure how to write a
syntax check that can poison the use of this identifier.

* tools/virsh-domain-monitor.c (cmdDomIfAddr): Use ifacestr instead.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit id '2dbfa716' exposed virCgroupDetectMountsFromFile, but did not
add the corresponding entry in the "#else /* !VIR_CGROUP_SUPPORTED */"
section of the module.

Commit id 'ba1dfc5b' added virCgroupSetCpusetMemoryMigrate and
virCgroupGetCpusetMemoryMigrate, but did not add the corresponding
entry points into the "#else /* !VIR_CGROUP_SUPPORTED */" section

We need to mock virFileExists to return true for "/dev/kvm" because the
test should not depend on host system.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This reverts commit 49bf09d1.  That
commit is wrong and doesn't fix the issue.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commint 0473b45c introduced new function virNetlinkDelLink, but in
it's counterpart for non-linux platform there should be ATTRIBUTE_UNUSED
instead of ATTRIBUTE_UNSUPPORTED.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Blockcopy to non-file destination is not supported according the code,
but a 'goto endjob' is missed after checking the destination.

This leads to calling drive-mirror with wrong parameters.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206406Signed-off-by: NShanzhi Yu <shyu@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Current libvirt can only handle up to 1023 bytes when it
reads Linux sysfs topology/thread_siblings. This isn't enough for
Linux distributions that support a large value. This patch fixes
the problem by using VIR_ALLOC()/VIR_FREE(), instead of using a
fixed-size (1024) local char array. In the meanwhile
SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX is increased to 8192 which
should be large enough for a foreseeable future.
Signed-off-by: NWei Huang <wei@redhat.com>

On IRC, Hydrar pointed a problem where 'virsh edit' failed on
his domain created through an ISCSI pool managed by virt-manager,
all because the XML included a block device with colons in the
name.

* docs/schemas/basictypes.rng (absFilePath): Add colon as safe.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.xml: New file.
* tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.args: Likewise.
* tests/qemuxml2argvtest.c (mymain): Test it.
Signed-off-by: NEric Blake <eblake@redhat.com>

If we fail to create the thread we leak the shutdown_info
structure.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Just as it is possible to delete a bridge device with the netlink
RTM_DELLINK message, one can be created with the RTM_NEWLINK
message. Because of differences in the format of the message, it's not
as straightforward as with virNetlinkDelLink() to create a single
utility function that can be used to create any type of interface, so
the new netlink version of virNetDevBridgeCreate() does its own
construction of the netlink message and calls virNetlinkCommand()
itself.

This doesn't provide any extra functionality, just provides symmetry
with the previous commit.

NB: We *could* alter the API of virNetDevBridgeCreate() to take a MAC
address, and directly program that mac address into the bridge (by
adding an IFLA_ADDRESS attribute, as is done in
virNetDevMacVLanCreate()) rather than separately creating the "dummy
tap" (e.g. virbr0-nic) to maintain a fixed mac address on the bridge,
but the commit history of virnetdevbridge.c shows that the presence of
this dummy tap is essential in some older versions of the kernel
(between 2.6.39 and 3.1 or 3.2, possibly?) to proper operation of IPv6
DAD, and I don't want to take the chance of breaking something that I
don't have the time/setup to test (my RHEL6 box is at kernel
2.6.32-544, and the next lowest kernel I have is 3.17)

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

reported that a stray bridge device was left on the system when a
libvirt network failed to start due to an illegal iptables rule caused
by bad config. Apparently the reason this was happening was that
NetworkManager was noticing immediately when the bridge device was
created and automatically setting it IFF_UP. libvirt would then try to
setup the iptables rules, get an error back, and since libvirt had
never IFF_UPed the bridge, it didn't expect that it needed to set it
~IFF_UP before deleting it during the cleanup process. But the
ioctl(SIOCBRDELBR) ioctl will fail to delete a bridge if it is IFF_UP.

Since that bug was reported, NetworkManager has gotten a bit more
polite in this respect, but just in case something similar happens in
the future, this patch switches to using the netlink RTM_DELLINK
message to delete the bridge - unlike SIOCBRDELBR, it will delete the
requested bridge no matter what the setting of IFF_UP.