Michal Privoznik [Fri, 10 Jul 2015 14:32:00 +0000 (17:32 +0300)]
virt-driver-vz: Require parallels-7.0.22 at least
With the latest patch to the vz driver (7d73ca06cefe) I was
getting some compilation errors. It turned out, my installation
of the parallels SDK was not as fresh as it could be. Parallels
installed in my system were missing the
PRL_USE_VNET_NAME_FOR_BRIDGE_NAME symbol which simply was not
introduced at the time I was installing the SDK. The symbol was
introduced in 86e62a5d which was then part of the 7.0.22 release.
Require that version at least therefore.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 13 Jul 2015 12:15:03 +0000 (14:15 +0200)]
qemuProcessHandleMigrationStatus: Update migration status more frequently
After Jirka's migration patches libvirt is listening on migration
events from qemu instead of actively polling on the monitor. There is,
however, a little regression (introduced in 6d2edb6a42d0d41). The
problem is, the current status of migration job is updated in
qemuProcessHandleMigrationStatus if and only if migration job was
started. But eventually every asynchronous job may result in
migration. Therefore, since this job is not strictly a
migration job, internal state was not updated and later checks failed:
virsh # save fedora22 /tmp/fedora22_ble.save
error: Failed to save domain fedora22 to /tmp/fedora22_ble.save
error: operation failed: domain save job: is not active
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We create a virtual network of special type, which
has the same name as bridge name to create bridged
network adapter in vz. So when we delete such an
adapter we have to remove corresponding virtual
network.
So let's rename prlsdkDelNet to prlsdkCleanupBridgedNet
and don't check for return value.
qemu: Use error from Finish instead of "unexpectedly failed"
When QEMU exits on destination during migration, the source reports
either success (if the failure happened at the very end) or unhelpful
"unexpectedly failed" error message. However, the Finish API called on
the destination may report a real error so let's use it instead of the
generic one.
virDomainMigrateFinish* APIs were unfortunately designed to return the
pointer to the domain on destination and NULL on error. This looks OK in
normal cases but the same API is also called when we know migration
failed and thus we expect Finish to return NULL even if it actually did
all it was supposed to do without any error. The call is defined to
return nonnull domain pointer over RPC, which means returning NULL will
always result in an error being send. If this was not in fact an error,
the API itself wouldn't set anything to the thread local virError, which
makes the RPC layer come up with it's own "Library function returned
error but did not set virError" error.
This is quite confusing and also hard to detect by the caller. This
patch adds a special error code which can be used to check that Finish
successfully aborted migration.
If QEMU fails during incoming migration, the domain disappears including
a possibly useful error message read from QEMU log file. Let's remember
the error in virQEMUDriver so that Finish can report more than just "no
such domain".
This is a self-locking wrapper around virHashTable. Only a limited set
of APIs are implemented now (the ones which are used in the following
patch) as more can be added on demand.
Cédric Bosdonnat [Thu, 25 Jun 2015 08:36:52 +0000 (10:36 +0200)]
Get more libvirt errors from virt-aa-helper
Initializing libvirt log in virt-aa-helper and getting it to output
libvirt log to stderr. This will help debugging problems happening in
libvirt functions called from within virt-aa-helper
Daemon used false logic for determining whether there were any clients.
When the timer was inactive, it was activated if at least one of the
servers did not have clients. So the bool was being flipped there and
back all the time in case there was one client, for example.
Peter Krempa [Wed, 8 Jul 2015 14:10:05 +0000 (16:10 +0200)]
qemu: Check duplicate WWNs also for hotplugged disks
In commit 714b38cb232bcbbd7487af4c058fa6d0999b3326 I tried to avoid
having two disks with the same WWN in a VM. I forgot to check the
hotplug paths though which make it possible bypass that check. Reinforce
the fix by checking the wwn when attaching the disk.
Prerna Saxena [Fri, 26 Jun 2015 11:43:26 +0000 (17:13 +0530)]
Fix cloning of raw, sparse volumes
When virsh vol-clone is attempted on a raw file where capacity > allocation,
the resulting cloned volume has a size that matches the virtual-size of
the parent; in place of matching its actual, disk size.
This patch fixes the cloned disk to have same _allocated_size_ as
the parent file from which it was cloned.
Ján Tomko [Fri, 3 Jul 2015 10:47:02 +0000 (12:47 +0200)]
Rewrite allocation tracking when cloning volumes
Instead of storing the remaining bytes, store the position of the first
unallocated byte. This will allow changing the amount of bytes copied
by virStorageBackendCopyToFD without changing the safezero call.
Libvirt's error messages do not end with a LF. However, when reading the
error from QEMU log, we would read the LF from the log and keep it in
the message.
Jiri Denemark [Fri, 29 May 2015 06:38:44 +0000 (08:38 +0200)]
qemu: Wait for migration events on domain condition
Since we already support the MIGRATION event, we just need to make sure
the domain condition is signalled whenever a p2p connection drops or the
domain is paused due to IO error and we can avoid waking up every 50 ms
to check whether something happened.
Jiri Denemark [Tue, 26 May 2015 11:42:06 +0000 (13:42 +0200)]
qemuDomainGetJobStatsInternal: Support migration events
When QEMU supports migration events the qemuDomainJobInfo structure will
no longer be updated with migration statistics. We have to enter a job
and explicitly ask QEMU every time virDomainGetJob{Info,Stats} is
called.
Even if QEMU supports migration events it doesn't send them by default.
We have to enable them by calling migrate-set-capabilities. Let's enable
migration events everytime we can and clear QEMU_CAPS_MIGRATION_EVENT in
case migrate-set-capabilities does not support events.
qemu: don't use initialized ret in qemuRemoveSharedDevice
This fixes
CC qemu/libvirt_driver_qemu_impl_la-qemu_conf.lo
qemu/qemu_conf.c: In function 'qemuRemoveSharedDevice':
qemu/qemu_conf.c:1384:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Pavel Hrdina [Mon, 29 Jun 2015 14:19:44 +0000 (16:19 +0200)]
qemu_hotplug: try harder to eject media
Some guests lock the tray and QEMU eject command will simply fail to
eject the media. But the guest OS can handle this attempt to eject the
media and can unlock the tray and open it. In this case, we should try
again to actually eject the media.
If the first attempt fails to detect a tray_open we will fail with
error, from monitor. If we receive that event, we know, that the guest
properly reacted to the eject request, unlocked the tray and opened it.
In this case, we need to run the command again to actually eject the
media from the device. The reason to call it again is, that QEMU
doesn't wait for the guest to react and report an error, that the tray
is locked.
Pavel Hrdina [Mon, 29 Jun 2015 14:18:53 +0000 (16:18 +0200)]
monitor: detect that eject fails because the tray is locked
Modify the eject monitor functions to parse the return code and detect,
whether the error contains "is locked" to report this type of failure to
upper layers.
Commit id 'e0e290552' added a check to determine if the same bus
had the same target value. It seems that's not quite good enough
as the check should check the target name value regardless of bus type.
Also added a DO_TEST_DIFFERENT to exhibit the issue
Erik Skultety [Thu, 9 Jul 2015 09:17:12 +0000 (11:17 +0200)]
storage: Revert volume obj list updating after volume creation (4749d82a)
This patch reverts commit 4749d82a which tried to tweak the logic in
volume creation. We did realloc and update our object list before we executed
volume building within a specific storage backend. If that failed, we
had to update (again) our object list to the original state as it was before the
build and delete the volume from the pool (even though it didn't exist - this
truly depends on the backend).
I misunderstood the base idea to be able to poll the status of the volume
creation using vol-info. After commit 4749d82a this wasn't possible
anymore, although no BZ has been reported yet.
Commit 4749d82a also claimed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1223177, but commit c8be606b of the
same series as 4749d82ad (which was more of a refactor than a fix)
fixes the same issue so the revert should be pretty straightforward.
Further more, BZ https://bugzilla.redhat.com/show_bug.cgi?id=1241454 can be
fixed with this revert.
John Ferlan [Tue, 16 Jun 2015 15:34:06 +0000 (11:34 -0400)]
qemu: Inline qemuGetHostdevPath
Since a future patch will need the device path generated when adding a
shared host device, remove the qemuAddSharedHostdev and inline the two
calls into qemuAddSharedHostdev and qemuRemoveSharedHostdev
John Ferlan [Mon, 6 Jul 2015 17:08:32 +0000 (13:08 -0400)]
qemu: Refactor qemuCheckSharedDisk to create qemuCheckUnprivSGIO
Split out the current function in order to share the code with hostdev
in a future patch. Failure to match the expected sgio value against what
is stored will cause an error which the caller would need to handle since
only the caller has the disk (or eventually hostdev) specific data in
order to uniquely identify the disk in an error message.
Jim Fehlig [Tue, 7 Jul 2015 18:29:24 +0000 (12:29 -0600)]
libxl: rework setting the state of virDomainObj
Set the state of virDomainObj in the functions that
actually change the domain state, instead of the generic
libxlDomainCleanup function. This approach gives functions
calling libxlDomainCleanup more flexibility wrt when and
how they change virDomainObj state via virDomainObjSetState.
The prior approach of calling virDomainObjSetState in
libxlDomainCleanup resulted in the following incorrect
coding pattern in the various functions that change
domain state
libxlDomain<DoStateTransition>
call libxl function to do state transition
emit lifecycle event
libxlDomainCleanup
virDomainObjSetState
Once simple manifestation of this bug is seeing a domain
running in virt-manager after selecting the shutdown button,
even after the domain has long shutdown.
Jim Fehlig [Mon, 22 Jun 2015 17:36:59 +0000 (11:36 -0600)]
libxl: support dom0
In Xen, dom0 is really just another domain that supports ballooning,
adding/removing devices, changing vcpu configuration, etc. This patch
adds support to the libxl driver for managing dom0. Note that the
legacy xend driver has long supported managing dom0.
Operations that are not supported on dom0 are filtered in libvirt
where a sensible error is reported. Errors from libxl are not
always helpful. E.g., attempting a save on dom0 results in
2015-06-23 15:25:05 MDT libxl: debug: libxl_dom.c:1570:libxl__toolstack_save: domain=0 toolstack data size=8
2015-06-23 15:25:05 MDT libxl: debug: libxl.c:979:do_libxl_domain_suspend: ao 0x7f7e68000b70: inprogress: poller=0x7f7e68000930, flags=i
2015-06-23 15:25:05 MDT libxl-save-helper: debug: starting save: Success
2015-06-23 15:25:05 MDT xc: detail: xc_domain_save_suse: starting save of domid 0
2015-06-23 15:25:05 MDT xc: error: Couldn't map live_shinfo (3 = No such process): Internal error
2015-06-23 15:25:05 MDT xc: detail: Save exit of domid 0 with errno=3
2015-06-23 15:25:05 MDT libxl-save-helper: debug: complete r=1: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:1876:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: No such process
2015-06-23 15:25:05 MDT libxl: error: libxl_dom.c:2033:remus_teardown_done: Remus: failed to teardown device for guest with domid 0, rc -8
John Ferlan [Tue, 16 Jun 2015 17:33:37 +0000 (13:33 -0400)]
qemu: Introduce qemuIsSharedHostdev
Add a single boolean function to handle whether the hostdev is shared or not.
Use the new function for the qemu{Add|Remove}SharedHostdev calls as well
as qemuSetUnprivSGIO. NB: This third usage fixes a possible bug where
if this feature is enabled at some time in the future and the shareable flag
wasn't set, the sgio would have been erroneously set.
Luyao Huang [Wed, 17 Jun 2015 03:56:21 +0000 (11:56 +0800)]
qemu: report error when shmem has an invalid address
If user passes an invalid address for shared memory device to qemu,
neither libvirt nor qemu will report an error, but qemu will auto assign
a pci address to the shared memory device.
It is better not to assume that newly created network should be
connected to a bridge with same name, but specify it explicitly
by PRL_USE_VNET_NAME_FOR_BRIDGE_NAME flag.
Erik Skultety [Thu, 2 Jul 2015 12:41:37 +0000 (14:41 +0200)]
storage: Fix regression in storagePoolUpdateAllState
Commit 2a31c5f0 introduced support for storage pool state XMLs, however
it also introduced a regression:
if (!virstoragePoolObjIsActive(pool)) {
virStoragePoolObjUnlock(pool);
continue;
}
The idea behind this was that since we've got state XMLs and the pool
wasn't marked as active by autostart routine (if the autostart flag had been
set earlier), the pool is inactive and we can leave it be and continue with
other pools. However, filesystem type pools like fs,dir, possibly netfs are
supposed to be active if the filesystem is mounted on the host. And this is
exactly where the regression occurs, e.g. pool type 'dir' which has been
previously destroyed and marked as !autostart gets filtered out
by the condition above.
The resolution should be simply to remove the condition completely,
all pools will get their 'active' flag updated by check callback and if
they do not support such callback, the logic doesn't change and such
pools will be inactive by default (e.g. RBD, even if a state XML exists).
Peter Krempa [Thu, 2 Jul 2015 14:46:46 +0000 (16:46 +0200)]
util: bitmap: Don't alloc overly large binary bitmaps
Optimize the virBitmap to array-of-char bitmap conversion by skipping
trailing zero bytes.
This also fixes a regression when requesting iothread information from a
live VM since after commit 825df8c3158cfaf5f398418471f10f4ff3c3515a the
bitmap returned from virProcessGetAffinity is too big to be formatted
properly via RPC. A user would get the following error:
error: Unable to get domain IOThreads information
error: Unable to encode message payload
qemu: move the guest status check before agent config and status check
When use setvcpus command with --guest option to a offline vm,
we will get error:
# virsh setvcpus test3 1 --guest
error: Guest agent is not responding: QEMU guest agent is not connected
However guest is not running, agent status could not be connected.
In this case, report domain is not running will be better than agent is
not connected. Move the guest status check more early to output error to
point out guest status is not right.
Also from the logic, a running vm is a basic requirement to use
agent, we cannot use agent if vm is not running.
Signed-off-by: Luyao Huang <lhuang@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
vz: assign static IPs and default gateways for network adapter
We support only one IPv4 and one IPv6 default gateway.
If static IPs are not present in instance config,
then we switch on DHCP for this adapter.
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
Current version of SDK event dispatcing is incorrect. For most VM events (add,
delete etc) issuer type is PIE_DISPATCHER. Actually analyzing issuer type
doesn't have any benifints so this patch get rid of it. All dispatching is done
only on event type.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
John Ferlan [Wed, 1 Jul 2015 13:35:43 +0000 (09:35 -0400)]
util: Avoid Coverity FORWARD_NULL
Avoid a false positive since Coverity find a path in virResizeN which
could return 0 prior to the allocation of memory and thus flags a
possible NULL dereference. Instead allocate the output buffer based
on 'nparams' and only fill it partially if need be - shouldn't be too
much a waste of space. Quicker than multiple VIR_RESIZE_N calls or
two loops of STREQ's sandwiched around a single VIR_ALLOC_N using
'n' matches from a first loop to generate the 'n' addresses to return
Luyao Huang [Mon, 29 Jun 2015 02:10:15 +0000 (10:10 +0800)]
virsh: report error if vcpu number exceed the guest maxvcpu number
Commit id '81dd81e' caused a regression when attempting to print a
specific vcpuid that is out of the range of the maximum vcpus for
the guest, such as:
$ virsh vcpupin $dom 1000
VCPU: CPU Affinity
----------------------------------
$
Rather than just recover the old message, let's adjust the message based
on what would be displayed for a similar failure in the set path, such as:
$ virsh vcpupin $dom 1000
error: vcpu 1000 is out of range of persistent cpu count 2
$ virsh vcpupin $dom 1000 --live
error: vcpu 1000 is out of range of live cpu count 2
Michal Dubiel [Wed, 1 Jul 2015 08:15:29 +0000 (10:15 +0200)]
virt-aa-helper: Fix permissions for vhost-user socket files
QEMU working in vhost-user mode communicates with the other end (i.e.
some virtual router application) via unix domain sockets. This requires
that permissions for the socket files are correctly written into
/etc/apparmor.d/libvirt/libvirt-UUID.files.
Jiri Denemark [Tue, 23 Jun 2015 13:14:22 +0000 (15:14 +0200)]
cpu_map.xml: Expand Opteron_G4 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:12:27 +0000 (15:12 +0200)]
cpu_map.xml: Expand Opteron_G2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:11:53 +0000 (15:11 +0200)]
cpu_map.xml: Expand Opteron_G1 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:10:28 +0000 (15:10 +0200)]
cpu_map.xml: Expand Broadwell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:10:28 +0000 (15:10 +0200)]
cpu_map.xml: Expand Haswell-noTSX CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:08:40 +0000 (15:08 +0200)]
cpu_map.xml: Expand SandyBridge CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:06:32 +0000 (15:06 +0200)]
cpu_map.xml: Expand Westmere CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:05:47 +0000 (15:05 +0200)]
cpu_map.xml: Expand Nehalem CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:04:24 +0000 (15:04 +0200)]
cpu_map.xml: Expand Penryn CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 13:03:07 +0000 (15:03 +0200)]
cpu_map.xml: Expand Conroe CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:47:08 +0000 (14:47 +0200)]
cpu_map.xml: Expand kvm64 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:45:51 +0000 (14:45 +0200)]
cpu_map.xml: Expand cpu64-rhel5 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:43:52 +0000 (14:43 +0200)]
cpu_map.xml: Expand kvm32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:42:43 +0000 (14:42 +0200)]
cpu_map.xml: Expand qemu32 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:40:28 +0000 (14:40 +0200)]
cpu_map.xml: Expand n270 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:39:27 +0000 (14:39 +0200)]
cpu_map.xml: Expand coreduo CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:38:06 +0000 (14:38 +0200)]
cpu_map.xml: Expand pentiumpro CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:36:15 +0000 (14:36 +0200)]
cpu_map.xml: Expand pentium2 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:34:41 +0000 (14:34 +0200)]
cpu_map.xml: Expand pentium CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Jiri Denemark [Tue, 23 Jun 2015 12:33:39 +0000 (14:33 +0200)]
cpu_map.xml: Expand 486 CPU model
Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
John Ferlan [Wed, 1 Jul 2015 10:32:34 +0000 (06:32 -0400)]
phyp: Resolve Coverity FORWARD_NULL
Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.
So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:
virsh # start --console test
error: Reconnected to the hypervisor
error: Failed to start domain test
error: internal error: guest failed to start: unexpected exit status 125
So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:
Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.
In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.
Peter Krempa [Fri, 26 Jun 2015 08:59:33 +0000 (10:59 +0200)]
conf: qemu: Taint VMs using custom device tree blob
Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.
projects / libvirt.git / log