If a storage file would be backed with a NBD device without path
(nbd://localhost) libvirt would crash when parsing the backing path for
the disk as the URI structure's path element is NULL in such case but
the NBD parser would access it shamelessly.

(cherry picked from commit fdb80ed4)

If the memory mode is specified as 'strict' and with one node, we
get the following error when starting domain.

error: Unable to write to '$cgroup_path/cpuset.mems': Device or resource busy

XML is configured with numatune as follows:
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>

It's broken by Commit 411cea63
which moved qemuSetupCgroupForEmulator() before setting cpuset.mems
in qemuSetupCgroupPostInit.

Directory '$cgroup_path/emulator/' is created in qemuSetupCgroupForEmulator.
But '$cgroup_path/emulator/cpuset.mems' it not set and has a default value
(all nodes, such as 0-1). Then we setup '$cgroup_path/cpuset.mems' to the
nodemask (in this case it's '0') in qemuSetupCgroupPostInit. It must fail.

This patch makes '$cgroup_path/emulator/cpuset.mems' is set before
'$cgroup_path/cpuset.mems'. The action is similar with that in
qemuDomainSetNumaParamsLive.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
(cherry picked from commit c6e90248)

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

When storageDriverAutostart is called path virStateReload via a 'service
libvirtd reload', then because the volume list in the pool wasn't cleared
prior to the call, each volume would be listed multiple times (as many
times as we reload). I believe the issue would be introduced by commit
id '9e093f0b' at least for the libvirtd reload path, although I suppose
the introduction of virStateReload (commit id '70da0494') could be a
different cause.

Thus like other places prior to calling refreshPool, we need to call
virStoragePoolObjClearVols

(cherry picked from commit 1d2e4d8c)

The function is called from all {Attach,Update,Detach}Device APIs to
create config strings that are later passed to the xend to perform the
desired action. The function is intended to handle all supported
devices. However, as of 5b05358a we
are trying to get disk driver of the device without checking if the
device really is a disk. This leads to an segmentation fault:

  #0 0x00007ffff7571815 in virDomainDiskGetDriver () from /usr/lib/libvirt.so.0
  #1 0x00007fffeb9ad471 in ?? () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #2 0x00007fffeb9b1062 in xenDaemonAttachDeviceFlags () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #3 0x00007fffeb9a8a86 in ?? () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #4 0x00007ffff7609266 in virDomainAttachDevice () from /usr/lib/libvirt.so.0
  #5 0x0000555555593c9d in ?? ()
  #6 0x00007ffff76743c9 in virNetServerProgramDispatch () from /usr/lib/libvirt.so.0
  #7 0x00005555555a678d in ?? ()
  #8 0x00007ffff755460e in ?? () from /usr/lib/libvirt.so.0
  #9 0x00007ffff7553b06 in ?? () from /usr/lib/libvirt.so.0
  #10 0x00007ffff4998b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
  #11 0x00007ffff46e30ed in clone () from /lib/x86_64-linux-gnu/libc.so.6
  #12 0x0000000000000000 in ?? ()
Reported-by: NXiaolin Su <linxxnil@126.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit cd7702d4)

The ACL check didn't check the VIR_DOMAIN_XML_SECURE flag and the
appropriate permission for it. Found via code inspection while fixing
permissions for save images.

(cherry picked from commit b347c0c2)

The ACL check didn't check the VIR_DOMAIN_XML_SECURE flag and the
appropriate permission for it.

(cherry picked from commit 03c3c0c8)

Output error when we try to set a too large max_sectors.
Just like queues and cmd_per_lun here.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
(cherry picked from commit ce1d2f63)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Commit ca91ba78 moved qemuSetupDiskCgroup into the qemuDomainPrepareDisk
helper, but failed to call it for usb disks.

https://bugzilla.redhat.com/show_bug.cgi?id=1175668`
(cherry picked from commit 1cddf000)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

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

When we try to hotplug a channel chr device with no target, we
will get success (which should fail) in virDomainChrDefParseXML,
because we use goto cleanup this place and return an incomplete
definition (with no target). In qemuDomainAttachChrDevice,
we add it to the domain definition, but fail to remove it from
there when chardev-add fails, because virDomainChrRemove
matches chardevices according to the target name.
The device definition is then freed in qemuDomainAttachDeviceFlags,
leaving a stale pointer in the domain definition.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit fba7173f)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Avoid leaving the domain locked on a failed ACL check in
qemuDomainMigratePerform() and qemuDomainMigrateFinish2().

Introduced in commit abf75aea (Add ACL checks into the QEMU driver).

(cherry picked from commit 2bdcd29c)

https://bugzilla.redhat.com/show_bug.cgi?id=1087104#c5

When trying to use an invalid offset to virStorageVolUpload(), libvirt
fails in virFDStreamOpenFileInternal(), although it seems libvirt does
not check the return in storageVolUpload(), and calls
virFDStreamSetInternalCloseCb() right after.  But stream doesn't have a
privateData (is NULL) yet, and the daemon crashes then.

0  0x00007f09429a9c10 in pthread_mutex_lock () from /lib64/libpthread.so.0
1  0x00007f094514dbf5 in virMutexLock (m=<optimized out>) at util/virthread.c:88
2  0x00007f09451cb211 in virFDStreamSetInternalCloseCb at fdstream.c:795
3  0x00007f092ff2c9eb in storageVolUpload at storage/storage_driver.c:2098
4  0x00007f09451f46e0 in virStorageVolUpload at libvirt.c:14000
5  0x00007f0945c78fa1 in remoteDispatchStorageVolUpload at remote_dispatch.h:14339
6  remoteDispatchStorageVolUploadHelper at remote_dispatch.h:14309
7  0x00007f094524a192 in virNetServerProgramDispatchCall at rpc/virnetserverprogram.c:437
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
(cherry picked from commit 87b9437f)

A logic bug in qemuConnectGetAllDomainStats makes the code mark the
monitor as available when qemuDomainObjBeginJob fails, instead of when
it succeeds, as the correct flow requires.

This patch fixes the check and updates the code documentation
accordingly.

Broken by commit 57023c0a.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
(cherry picked from commit cb104ef7)
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

When user doesn't have read access on one of the domains he requested,
the for loop could exit abruptly or continue and override pointer which
pointed to locked object.

This patch fixed two issues at once.  One is that domflags might have
had QEMU_DOMAIN_STATS_HAVE_JOB even when there was no job started (this
is fixed by doing domflags |= QEMU_DOMAIN_STATS_HAVE_JOB only when the
job was acquired and cleaning domflags on every start of the loop.
Second one is that the domain is kept locked when
virConnectGetAllDomainStatsCheckACL() fails and continues the loop when
it didn't end.  Adding a simple virObjectUnlock() and clearing the
pointer ought to do.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 57023c0a)
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

As discussed on the upstream list, it's better not to make this
kind of predictions in libvirt. It may happen that qemu learns
how to enable OVMF on other architectures too and we shouldn't
try to chase that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 36148120)

Currently, we are whitelisting architectures, that we know how to run
OVMF on. So far, only x86_64 was enabled. However, looking at qemu
code, the same commandline can be used to enable OVMF for armv7l and
aarch64.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 6d8054b6)

Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
(and other commands, such as -cpu ?) output. However, if QMP probing
failed, we still tried starting QEMU with various options and parsing
the output, which was guaranteed to fail because the output changed.
Let's just refuse parsing -help for QEMU >= 1.2.0.

https://bugzilla.redhat.com/show_bug.cgi?id=1160318Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit ae3e29e6)

Conflicts:
	tests/qemuhelptest.c

We used to set migration capabilities only when a user asked for them in
flags. This is fine when migration succeeds since the QEMU process is
killed in the end but in case migration fails or if it's cancelled, some
capabilities may remain turned on with no way to turn them off. To fix
that, migration capabilities have to be turned on if requested but
explicitly turned off in case they were not requested but QEMU supports
them.

https://bugzilla.redhat.com/show_bug.cgi?id=1163953Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit ab393383)

Commit 6e5c79a1 tried to fix deadlock between nwfilter{Define,Undefine}
and starting of guest, but this same deadlock exists for
updating/attaching network device to domain.

The deadlock was introduced by removing global QEMU driver lock because
nwfilter was counting on this lock and ensure that all driver locks are
locked inside of nwfilter{Define,Undefine}.

This patch extends usage of virNWFilterReadLockFilterUpdates to prevent
the deadlock for all possible paths in QEMU driver. LXC and UML drivers
still have global lock.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1143780Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit 41127244)

In one of my previous patches (3a3c3780) I've tried to fix the
problem of nvram path disappearing on a domain that's been
started and shut down again. I fixed this by explicitly saving
domain's config file.  However, I did a bit of clumsy without
realizing we have a transient domains for which we don't save the
config file. Hence, any domain using UEFI became persistent.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 54ddc08d)

virStorageFileBackendGlusterInit did not check nhosts.

https://bugzilla.redhat.com/show_bug.cgi?id=1162974
(cherry picked from commit b66288fa)

Use the device type name if we know it instead of its number,
even if we can't hotplug it:
qemuMonitorJSONAttachCharDevCommand:6094 : operation failed: Unsupported
char device type '10'

(cherry picked from commit cce8e5f7)

virDomainChrSourceDefIsEqual should return 'true' for
identical SPICEVMC chardevs, and those that have no source
specification.

After this change, a failed hotplug no longer leaves a stale
pointer in the domain definition.

https://bugzilla.redhat.com/show_bug.cgi?id=1162097
(cherry picked from commit b987684f)

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

As of b6d4dad1 (1.2.5) libvirt keeps track if domain disks have been
frozen. However, this falls into that set of information which don't
survive domain restart. Therefore, we need to clear the flag upon some
state transitions. Moreover, once we clear the flag we must update the
status file too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 6ea54769)

When start a network fail, libvirt still call virNetworkEventLifecycleNew
to send a event.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
(cherry picked from commit 45d9ea5c)

A domain without a console quietly dies soon after start,
because we try to set /dev/null as a controlling TTY
2014-10-30 15:10:59.705+0000: 1: error : lxcContainerSetupFDs:283 :
ioctl(TIOCSCTTY) failed: Inappropriate ioctl for device

Report an error early instead of trying to start it.

https://bugzilla.redhat.com/show_bug.cgi?id=1155410
(cherry picked from commit 44686f65)

It fails after 30 seconds with this error:
error : virDBusCall:1429 : error from service: CanSuspend:
Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the
network connection was broken.

Only probe for the power mgmt capabilities when driver is non-NULL.
This speeds up domain startup by 30 seconds.

https://bugzilla.redhat.com/show_bug.cgi?id=1159227
(cherry picked from commit 7ead1a5d)

Coverity found out the very obvious problem in the code.  That is that
virPidFileReleasePath() was called only if
virPidFileAcquirePath() returned 0.  But virPidFileAcquirePath() doesn't
return only 0 on success, but the FD that needs to be closed.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 3f43bb83)

In qemuMigrationFinish mig->nbd can not be initialized by
qemuMigrationEatCookie without the QEMU_MIGRATION_COOKIE_NBD flag.
That causes qemuMigrationStopNBDServer to return early without
stopping the NBD server properly.
Signed-off-by: NWeiwei Li <nuonuoli@tencent.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit c3012a02)

When daemon is killed right in the middle of probing a qemu binary for
its capabilities, the qemu process is left running.  Next time the
daemon is starting, it cannot start the probing qemu process because the
one that's already running does have the pidfile flock()'d.
Reported-by: NWang Yufei <james.wangyufei@huawei.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 0ed1b55b)

This function is used to cleanup a pidfile doing whatever it takes, even
killing the owning process.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit d1fd086e)

Particularly in qemuBuildNumaArgStr(), there was a need for the advice
due to memory backing, which needs to know the nodeset it will be pinned
to.  With newer qemu this caused the following error when starting
domain:

  error: internal error: Advice from numad is needed in case of
  automatic numa placement

even when starting perfectly valid domain, e.g.:

  ...
  <vcpu placement='auto'>4</vcpu>
  <numatune>
    <memory mode='strict' placement='auto'/>
  </numatune>
  <cpu>
    <numa>
      <cell id='0' cpus='0' memory='524288'/>
      <cell id='1' cpus='1' memory='524288'/>
    </numa>
  </cpu>
  ...

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138545Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 11a48758)

commit 3e1e16aa (Use a port from the
migration range for NBD as well) changed ndb port allocation from
remotePorts to migrationPorts, but did not change the port releasing
process, which makes an error when migrating several times (above 64):
error: internal error: Unable to find an unused port in range
'migration' (49152-49215)

https://bugzilla.redhat.com/show_bug.cgi?id=1159245Signed-off-by: NWeiwei Li <nuonuoli@tencent.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit be598c5f)

https://bugzilla.redhat.com/show_bug.cgi?id=1140981 reports that
the qemu-kvm shipped as part of RHEL 7.0 intentionally[1] cripples
block jobs by removing the 'block-stream' QMP command, while still
leaving 'block-job-cancel' as an unusable no-op.  Meanwhile, we
already had existing code that checked whether block jobs were
completely missing (such as qemu 0.15), old style (cancel is
synchronous, and all commands spelled with '_'), or new style
(cancel is asynchronous, and all commands spelled with '-'), and
used that three-way probe to give decent error messages.  At the
time that code was added, all existing qemu versions fell in one
of three buckets, and the code was using the presence of
'block-job-cancel' as the witness of which of the three buckets.
But now that RHEL qemu has shipped with intentionally crippled
'block-stream', we have a fourth bucket, which results in ugly
error messages when trying 'virsh blockpull':

 error: Requested operation is not valid: Command 'block-stream' is not found

In reality, the fourth bucket should be treated the same as the
first bucket (no block job support); we can do that by realizing
that no existing build of qemu has working block-stream while
lacking block-job-cancel, so it is easiest to change our witness
to the command that starts a job rather than ends one.  We still
act correctly regarding command spelling and whether cancel is
asynchronous.  And on crippled RHEL builds, we now get the desired:

 error: unsupported configuration: block jobs not supported with this qemu binary

[1] The intentional cripple is limited to qemu-kvm of RHEL; when using
qemu-kvm-rhev of RHEV, block job functionality is supported.  Don't ask
me to explain the "why" behind it all - I'm just dealing with fallout
from someone else's decision.

* src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC): Tweak comment.
* src/qemu/qemu_capabilities.c (virQEMUCapsCommands): Look for stream
rather than cancel when determining the flavor of block jobs supported.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 00331bfb)

Add two test cases to verify that the helpers split and parse the
backing store components properly.

(cherry picked from commit 95a56835)

The code that parses the schema from the URI touches the "hosts[0]"
member of the storage file source structure in case the URI contains a
schema. The hosts array was not yet allocated at the point in the code
where the transport protocol was parsed and set. This lead to a crash of
libvirtd.

Fix the code by allocating the "hosts" array upfront and add a test case
to verify this scenario. (Unfortunately this requires shuffling the test
case numbers too).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1156288
(cherry picked from commit 98784369)

Currently remote driver only initializes partial fields of
remote_connect_get_all_domain_stats_args. But xdr_array()
will check the uninitialised field 'doms_val'.
For safty reason, memset all fields of args is better.

Fix the following error from valgrind, like:
==30515== 1 errors in context 1 of 3:
==30515== Conditional jump or move depends on uninitialised value(s)
==30515==    at 0x85E9402: xdr_array (xdr_array.c:88)
==30515==    by 0x4FD8FC9: xdr_remote_connect_get_all_domain_stats_args (remote_protocol.c:6473)
==30515==    by 0x4FE72F2: virNetMessageEncodePayload (virnetmessage.c:350)
==30515==    by 0x4FDD21C: virNetClientProgramCall (virnetclientprogram.c:326)
==30515==    by 0x4FB4D01: callFull.isra.2 (remote_driver.c:6667)
==30515==    by 0x4FCBD45: call (remote_driver.c:6689)
==30515==    by 0x4FCBD45: remoteConnectGetAllDomainStats (remote_driver.c:7793)
==30515==    by 0x4FA0E75: virConnectGetAllDomainStats (libvirt.c:21678)
==30515==    by 0x147FD1: cmdDomstats (virsh-domain-monitor.c:2148)
==30515==    by 0x13006B: vshCommandRun (virsh.c:1915)
==30515==    by 0x12A9E1: main (virsh.c:3699)
Signed-off-by: NJincheng Miao <jmiao@redhat.com>
(cherry picked from commit 28b7601d)

Not every error message from qemu-ga has to have the 'class' field
filled out. For instance, I've seen this error message lately:

  qemuAgentCheckError:1047 : unable to execute QEMU agent command \
  {"execute":"guest-set-time"}: \
  {"error":{"desc":"Invalid parameter type, expected: integer"}}

However, this got translated into rather generic error message:

  internal error: unable to execute QEMU agent command
  'guest-set-time': unknown QEMU command error

So we've dropped better error message in favor of a generic one.
This is due to our code which expects 'class' which is not
present here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit b7fe5a65)

https://bugzilla.redhat.com/show_bug.cgi?id=956506 documents that
given a domain where an internal snapshot parent has an external
snapshot child, we lacked a safety check when trying to use the
--children-only option to snapshot-delete:

$ virsh start dom
$ virsh snapshot-create-as dom internal
$ virsh snapshot-create-as dom external --disk-only
$ virsh snapshot-delete dom external
error: Failed to delete snapshot external
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet
$ virsh snapshot-delete dom internal --children
error: Failed to delete snapshot internal
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet
$ virsh snapshot-delete dom internal --children-only
Domain snapshot internal children deleted

While I'd still like to see patches that actually do proper external
snapshot deletion, we should at least fix the inconsistency in the
meantime.  With this patch:

$ virsh snapshot-delete dom internal --children-only
error: Failed to delete snapshot internal
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet

* src/qemu/qemu_driver.c (qemuDomainSnapshotDelete): Fix condition.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 2086a990)