This reverts commit 46a811db. It causes
random problems in OpenStack, which displays the following error:

"""
error : virNWFilterObjAssignDef:3075 : operation failed: filter
'nova-no-nd-reflection' already exists with uuid
ef783c9f-ae1c-4242-8cd5-9cef5ec4fa7a
"""

Special thanks to Vojtech Cima for investigating.

Perform phase stops once migration switched to post-copy.
Confirm phase waits for post-copy to finish before killing the VM.

Signed-off-by: Cristian Klein <cristiklein@gmail.com>

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

The virStoragePoolSourceFindDuplicate only checks the incoming definition
against the same type of pool as the def; however, for "scsi_host" and
"fc_host" adapter pools, it's possible that either some pool "scsi_host"
adapter definition is already using the scsi_hostN that the "fc_host"
adapter definition wants to use or some "fc_host" pool adapter definition
is using a vHBA scsi_hostN or parent scsi_hostN that an incoming "scsi_host"
definition is trying to use.

This patch adds the mismatched type checks and adds extraneous comments
to describe what each check is determining.

This patch also modifies the documentation to be describe what scsi_hostN
devices a "scsi_host" source adapter should use and which to avoid. It also
updates the parent definition to specifically call out that for mixed
environments it's better to define which parent to use so that the duplicate
pool checks can be done properly.

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

Move the API from the backend to storage_conf and rename it to
virStoragePoolGetVhbaSCSIHostParent.  A future patch will need to
use this functionality from storage_conf

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

There are some small issue in qemuProcessAttach:

1.Fix virSecurityManagerGetProcessLabel always get pid = 0,
move 'vm->pid = pid' before call virSecurityManagerGetProcessLabel.

2.Use virSecurityManagerGenLabel to get image label.

3.Fix always set selinux label for other security driver label.

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

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



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

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



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

When a block{commit,copy} job was aborted on a domain, block job handler
did not process it correctly, leaving a phantom job in the background.
Any further calls to any blockjob causes "block <jobtype> still active"
error. This patch fixes the blockjob handler so that it checks not only
for VIR_DOMAIN_BLOCK_JOB_FAILED status, but VIR_DOMAIN_BLOCK_JOB_CANCELED
status as well, followed by our existing cleanup routine.

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



Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

If job is failed in qemuMigrationRun, we expect the jobinfo type as
FAILED. But jobinfo type won't be updated until entering
qemuMigrationWaitForCompletion. We should make it updated in all
conditions. Moreover, we can't use qemuMigrationUpdateJobStatus
here because job may fail in libvirt, so we can't query job status
from QEMU.

Signed-off-by: Wang Rui <moon.wangrui@huawei.com>

The migration job status is traced in qemuMigrationUpdateJobStatus
which is called in qemuMigrationRun. But if migration is cancelled
before the trace such as in qemuMigrationDriveMirror, the jobinfo
type won't be updated to CANCELLED. After this patch, we can get
jobinfo type CANCELLED if migration is cancelled during drive
mirror.  Moreover, we can't use qemuMigrationUpdateJobStatus
because from qemu's point of view it's just the drive mirror being
cancelled and the migration hasn't even started yet.

Signed-off-by: Wang Rui <moon.wangrui@huawei.com>

When I pasted some XML from libvirt.org, I've found a small mistake.

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

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



As of b6d4dad1 (1.2.5) we are trying to keep the status of FSFreeze
in the guest. Even though I've tried to fixed couple of corner cases
(6ea54769), it occurred to me just recently, that the approach is
broken by design. Firstly, there are many other ways to talk to
qemu-ga (even through libvirt) that filesystems can be thawed (e.g.
qemu-agent-command) without libvirt noticing. Moreover, there are
plenty of ways to thaw filesystems without even qemu-ga noticing (yes,
qemu-ga keeps internal track of FSFreeze status). So, instead of
keeping the track ourselves, or asking qemu-ga for stale state, it's
the best to let qemu-ga deal with that (and possibly let guest kernel
propagate an error).

Moreover, there's one bug with the following approach, if fsfreeze
command failed, we've executed fsthaw subsequently. So issuing
domfsfreeze in virsh gave the following result:

virsh # domfsfreeze gentoo
Froze 1 filesystem(s)

virsh # domfsfreeze gentoo
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance

virsh # domfsfreeze gentoo
Froze 1 filesystem(s)

virsh # domfsfreeze gentoo
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance

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

virReportSystemError is reserved for reporting system errors, calling it
with VIR_ERR_* error codes produces error messages that do not make any
sense, such as

    internal error: guest failed to start: Kernel doesn't support user
    namespace: Link has been severed

We should prohibit wrong usage with a syntax-check rule.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

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

It looks like it was copy-pasted, so in case anyone wonders what some of
those methods do without looking at them, and for the sake of
completeness, fix them.

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

This reverts commit 433b427f.

The patch was added in order to overcome a bug in iproute2 and since it
was properly identified as a bug, particularly in openSUSE 13.2, and it
is being worked on [1], the best solution for libvirt seems to be to
keep the old behaviour.

[1] https://bugzilla.novell.com/show_bug.cgi?id=907093

Starting from libvirt-1.2.4, network state XML files moved to another
directory (see commit b9e95491) and libvirt automatically migrates the
network state files to a new location. However, the code used
dirent.d_type which is not supported by all filesystems. Thus, when
libvirt was upgraded on a host which used such filesystem, network state
XMLs were not properly moved and running networks disappeared from
libvirt.

This patch falls back to lstat() whenever dirent.d_type is DT_UNKNOWN to
fix this issue.

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


Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Commit 7557ddf8 added some additional block.* stats to
virDomainListGetStats, but failed to document them in 'man
virsh'.  Also, I noticed some inconsistent use of commas.

* tools/virsh.pod (domstats): Tweak commas, add missing stats.

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

Commit 2aa167ca tried to fix the DBus interaction code to allow
callers to use native types instead of 4-byte bools.  But in
fixing the issue, I missed the case of an arrayref; Conrad Meyer
shows the following valid complaint issued by clang:

  CC       util/libvirt_util_la-virdbus.lo
util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
            GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
            x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.

But fixing that points out that we have NEVER supported arrayrefs
of sub-int types (byte, i16, u16, and now bool).  Again, while raw
types promote, arrays do not; so the macros HAVE to deal with both
size possibilities rather than assuming that an arrayref uses the
same sizing as the promoted raw type.

Obviously, our testsuite wasn't covering as much as it should have.

* src/util/virdbus.c (GET_NEXT_VAL): Also fix array cases.
(SET_NEXT_VAL): Fix uses of sub-int arrays.
* tests/virdbustest.c (testMessageArray, testMessageArrayRef):
Test it.

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

Commit 6fcddfcd refactored job statistics but missed the jobinfo type updated
in qemuDomainGetJobInfo. After this patch, we can use virDomainGetJobInfo to
get jobinfo type again.

Signed-off-by: Wang Rui <moon.wangrui@huawei.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Commit 'c264eeaa' didn't do the prerequisite 'make syntax-check' before
pushing. There was a <tab> in the whitespace for the comment.  Replaced
with spaces and aligned.

pushed as build breaker since Jenkins complained loudly

The typical case where we had a problem is with such a filesystem
definition as created by virt-sandbox-service:

    <filesystem type='bind' accessmode='passthrough'>
      <source dir='/var/lib/libvirt/filesystems/mysshd/var'/>
      <target dir='/var'/>
    </filesystem>

In this case, we don't want to unmount the /var subtree or we may
loose the access to the source folder.

Resolving symlinks can fail before mounting any file system if one file
system depends on another being mounted. Symlinks are now resolved in
two passes:

  * Before any file system is mounted, but then we are more gentle if
    the source path can't be accessed
  * Right before mounting a file system, so that we are sure that we
    have the resolved path... but then if it can't be accessed we raise
    an error.

Due to a change (or bug?) in ip link implementation, the command
    'ip link add vnet0...'
is forced into
    'ip link add name vnet0...'
The changed command also works on older versions of iproute2, just the
'name' parameter has been made mandatory.

To get virt-sandbox-service working with AppArmor, virt-aa-helper
needs not to choke on path in /etc/libvirt-sandbox/services.

This turns out to be working by magic but needs to be fixed.

Add attribute to set vgamem_mb parameter of QXL device for QEMU. This
value sets the size of VGA framebuffer for QXL device. Default value in
QEMU is 8MB so reuse it also in libvirt to not break things.

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



Signed-off-by: Pavel Hrdina <phrdina@redhat.com>

So far we didn't have any option to set video memory size for qemu video
devices. There was only the vram (ram for QXL) attribute but it was valid
only for the QXL video device.

To provide this feature to users QEMU has a dedicated device attribute
called 'vgamem_mb' to set the video memory size. We will use the 'vram'
attribute for setting video memory size for other QEMU video devices.

For the cirrus device we will ignore the vram value because it has
hardcoded video size in QEMU.

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



Signed-off-by: Pavel Hrdina <phrdina@redhat.com>