- 14 6月, 2019 1 次提交
-
-
由 Jie Wang 提交于
If libvirt receives DISCONNECTED event and prDaemonRunning is set to false, and qemuDomainRemoveDiskDevice() is performing in the meantime, then qemuDomainRemoveDiskDevice() will fail to remove pr-helper object because prDaemonRunning is false. But removing that check from qemuHotplugRemoveManagedPR() is not enough, because after removing the object through monitor the qemuProcessKillManagedPRDaemon() is called which contains the same check. Thus the pr-helper process might be left behind. Signed-off-by: NJie Wang <wangjie88@huawei.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 6月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
The hash table returned by qemuMonitorGetAllBlockJobInfo is organized by the frontend name (which skipps the 'drive-' prefix). While our code properly matches the jobs to the disk, qemu needs the full job name including the 'drive-' prefix to be able to identify jobs. Fix this by adding an argument to qemuMonitorGetAllBlockJobInfo which does not modify the job name before filling the hash. This fixes a regression where users would not be able to cancel/pivot block jobs after restarting libvirtd while a blockjob is running. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 06 6月, 2019 1 次提交
-
-
由 Andrea Bolognani 提交于
Commit 2f2254c7 attempted to fix a memory leak by ensuring cpumapToSet is always a freshly allocated bitmap, but regrettably introduced a NULL pointer access while doing so, because it called virBitmapCopy() without allocating the destination bitmap first. Solve the issue by using virBitmapNewCopy() instead. Reported-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 6月, 2019 4 次提交
-
-
由 Andrea Bolognani 提交于
We're using VIR_AUTOPTR() for everything now, plus the cleanup section was not doing anything useful anyway. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
In two out of three scenarios we are cleaning up properly after ourselves, but commit 5f2212c0 has changed the remaining one in a way that caused it to start leaking cpumapToSet. Refactor the logic so that cpumapToSet is always a freshly allocated bitmap that gets cleaned up automatically thanks to VIR_AUTOPTR(); this also allows us to remove the hostcpumap variable. Reported-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
Ever since the feature was introduced with commit 0f8e7ae3, it has contained a logic error in that it attempted to use a NUMA node map where a CPU map was expected. Because of that, guests using <numatune> might fail to start: # virsh start guest error: Failed to start domain guest error: cannot set CPU affinity on process 40055: Invalid argument This was particularly easy to trigger on POWER 8 machines, where secondary threads always show up as offline in the host: having <numatune> <memory mode='strict' placement='static' nodeset='1'/> </numatune> in the guest configuration, for example, would result in libvirt trying to set the process affinity so that it would prefer running on CPU 1, but since that's a secondary thread and thus shows up as offline, the operation would fail, and so would starting the guest. Use the newly introduced virNumaNodesetToCPUset() to convert the NUMA node map to a CPU map, which in the example above would be 48,56,64,72,80,88 - a valid input for virProcessSetAffinity(). https://bugzilla.redhat.com/show_bug.cgi?id=1703661Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
When migrating a domain with invtsc CPU feature enabled, the TSC frequency of the destination host must match the frequency used when the domain was started on the source host or the destination host has to support TSC scaling. If the frequencies do not match and the destination host does not support TSC scaling, QEMU will fail to set the right TSC frequency when starting vCPUs on the destination and thus migration will fail. However, this is quite late since both host might have spent significant time transferring memory and perhaps even storage data. By adding the check to libvirt we can let migration fail before any data starts to be sent over. If for some reason libvirt is unable to detect the host's TSC frequency or scaling support, we'll just let QEMU try and the migration will either succeed or fail later. Luckily, we mandate TSC frequency to be explicitly set in the domain XML to even allow migration of domains with invtsc. We can just check whether the requested frequency is compatible with the current host before starting QEMU. https://bugzilla.redhat.com/show_bug.cgi?id=1641702Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 5月, 2019 1 次提交
-
-
由 Martin Kletzander 提交于
If the scheduler is set before vCPU0 cannot be moved into its cpu,cpuacct cgroup. While it is not yet known whether this is a bug or not, it makes sense for us to do that later as otherwise the scheduler would be inherited by vCPU and I/O Threads even when they do not have any such setting specified. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 30 4月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
This reverts commit 2f5e6502. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 18 4月, 2019 2 次提交
-
-
由 Michal Privoznik 提交于
It's funny how this went unnoticed for such a long time. Long story short, if a domain is configured with VIR_DOMAIN_NUMATUNE_MEM_STRICT libvirt doesn't really honour that. This is because of 7e72ac78 after which libvirt allowed qemu to allocate memory just anywhere and only after that it used some magic involving cpuset.memory_migrate and cpuset.mems to move the memory to desired NUMA nodes. This was done in order to work around some KVM bug where KVM would fail if there wasn't a DMA zone available on the NUMA node. Well, while the work around might stopped libvirt tickling the KVM bug it also caused a bug on libvirt side: if there is not enough memory on configured NUMA node(s) then any attempt to start a domain must fail. Because of the way we play with guest memory domains can start just happily. The solution is to move the child we've just forked into emulator cgroup, set up cpuset.mems and exec() qemu only after that. This basically reverts 7e72ac78 which was a workaround for kernel bug. This bug was apparently fixed because I've tested this successfully with recent kernel. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel P. Berrangé 提交于
The call to resolve the actual network type will turn any NICs with type=network into one of the other types. Thus there should be no need to handle type=network in later switch() statements jumping off the actual type. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 16 4月, 2019 3 次提交
-
-
由 Daniel P. Berrangé 提交于
The APIs for allocating/notifying/removing network ports just take an internal domain interface struct right now. As a step towards turning these into public facing APIs, add a virNetworkPtr argument to all of them. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The port allocation APIs are currently called unconditionally for all types of NIC, but (mostly) only do anything for NICs with type=network. The exception is the port allocate API which does some validation even for NICs with type!=network. Relying on this validation is flawed, however, since the network driver may not even be installed. IOW virt drivers must not delegate validation to the network driver for NICs with type != network. This change allows us to report errors when the virtual network driver is not registered. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Martin Kletzander 提交于
This helps in a scenarios where vCPUs run with a priority that is so high they might starve the emulator thread. And it also fits with the rest of the settings. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 13 4月, 2019 1 次提交
-
-
由 Martin Kletzander 提交于
This does not cause a problem in usual scenarios thanks to us allowing CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be an issue because the directory is created with mkdtemp(3) which explicitly creates that with 0700 permissions and qemu running as non-root cannot access that. The scenarios include: - Builds without CAPNG - Running libvirtd in certain container configurations [1] - and possibly others. [1] https://github.com/kubevirt/kubevirt/pull/2181#issuecomment-481840304Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 04 4月, 2019 3 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Since the STOP event handler can use the pausedReason as sent to qemuProcessStopCPUs, we no longer need to send duplicate suspended lifecycle events because we know what caused the stop along with extra details. This processing allows us to also remove the duplicated state change from qemuProcessStopCPUs. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Map is based on existing cases in code where we send suspended event after changing domain state to paused. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Similar to commit [1] which saves and passes the running reason to the RESUME event handler, during qemuProcessStopCPUs let's save and pass the pause reason in the domain private data so that the STOP event handler can use it. [1] 5dab984e : qemu: Pass running reason to RESUME event handler Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 22 3月, 2019 1 次提交
-
-
由 Eric Blake 提交于
Now that the core of SnapshotObj is agnostic to snapshots and can be shared with upcoming checkpoint code, it is time to rename the struct and the functions specific to list operations. A later patch will shuffle which file holds the common code. This is a fairly mechanical patch. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 12 3月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
When preparing domain call qemuFirmwareFillDomain() to fill in desired firmware. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 25 2月, 2019 2 次提交
-
-
由 Marc Hartmayer 提交于
Replace virDomainChrSourceDefFree with virObjectUnref. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Marc Hartmayer 提交于
Use refcounting for priv->monConfig instead of asymmetric freeing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 20 2月, 2019 18 次提交
-
-
由 Chris Venteicher 提交于
qemuProcessQMPStart starts a QEMU process and monitor connection that can be used by multiple functions possibly for multiple QMP commands. The QMP exchange to exit capabilities negotiation mode and enter command mode can only be performed once after the monitor connection is established. Move responsibility for entering QMP command mode into the qemuProcessQMP code so multiple functions can issue QMP commands in arbitrary orders. This also simplifies the functions using the connection provided by qemuProcessQMPStart to issue QMP commands. Test code now needs to call qemuMonitorSetCapabilities to send the message to switch to command mode because the test code does not use the qemuProcessQMP command that internally calls qemuMonitorSetCapabilities. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
Multiple QEMU processes for QMP commands can operate concurrently. Use a unique directory under libDir for each QEMU process to avoid pidfile and unix socket collision between processes. The pid file name is changed from "capabilities.pidfile" to "qmp.pid" because we no longer need to avoid a possible clash with a qemu domain called "capabilities" now that the processes artifacts are stored in their own unique temporary directories. "Capabilities" was changed to "qmp" in the pid file name because these processes are no longer specific to the capabilities usecase and are more generic in terms of being used for any general purpose QMP message exchanges with a QEMU process that is not associated with a domain. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Users qemuProcessQMP struct were always forced to call both qemuProcessQMPStop and qemuProcessQMPFree when they are done with the process. We can just call qemuProcessQMPStop from qemuProcessQMPFree and let users call qemuProcessQMPFree only. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
qemuProcessQMPNew is one of the public functions used to create and manage a QEMU process for QMP command exchanges outside of domain operations. Add descriptive comment block, debug statement and make source consistent with the cleanup / VIR_STEAL_PTR format used elsewhere. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
The monitor config data is removed from the qemuProcessQMP struct. The monitor config data can be initialized immediately before call to qemuMonitorOpen and does not need to be maintained after the call because qemuMonitorOpen copies any strings it needs. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
Move code for setting paths and prepping file system from qemuProcessQMPNew to qemuProcessQMPInit. This keeps qemuProcessQMPNew limited to data structures and path initialization is done in qemuProcessQMPInit. The patch is a non-functional, cut / paste change, however goto is now "cleanup" rather than "error". Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
Store libDir path in the qemuProcessQMP struct in anticipation of moving path construction code into qemuProcessQMPInit function. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
All code related to QEMU monitor is moved from qemuProcessQMPNew and qemuProcessQMPInit into qemuProcessQMPConnectMonitor. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
This is a replacement for qemuProcessQMPRun to make the name consistent with qemuProcessStart. The original qemuProcessQMPRun function is renamed as qemuProcessQMPLaunch and becomes one of the simpler functions called from the main qemuProcessQMPStart entry point. The following patches will move parts of the code in qemuProcessQMPLaunch to the other functions (qemuProcessQMPInit and qemuProcessQMPConnectMonitor). Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
While qemuProcessQMPRun and virQEMUCapsInitQMPMonitor* functions called from virQEMUCapsInit ignore some errors, the caller of virQEMUCapsInit would report an error unless usedQMP is true anyway. And since usedQMP can only be true if the probing code really succeeded (i.e., no errors were ignored), we can just simplify the logic by not ignoring the errors in the first place. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
In new process code, move from model where qemuProcessQMP struct can be used to activate a series of Qemu processes to model where one qemuProcessQMP struct is used for one and only one Qemu process. By allowing only one process activation per qemuProcessQMP struct, the struct can safely store process outputs like status and stderr, without being overwritten, until qemuProcessQMPFree is called. By doing this, process outputs like status and stderr can remain stored in the qemuProcessQMP struct without being overwritten by subsequent process activations. The forceTCG parameter (use / don't use KVM) will be passed when the qemuProcessQMP struct is initialized since the qemuProcessQMP struct won't be reused. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
virQEMUCapsInitQMP now stops QEMU process in all execution paths, before freeing the process structure. The qemuProcessQMPStop function can be called multiple times without problems... Won't attempt to stop processes and free resources multiple times. Follow the convention established in qemu_process of 1) alloc process structure 2) start process 3) use process 4) stop process 5) free process data structure The process data structure persists after the process activation fails or the process dies or is killed so stderr strings can be retrieved until the process data structure is freed. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
s/qemuProcessQMPAbort/qemuProcessQMPStop/ applied to change function name used to stop QEMU processes in process code moved from qemu_capabilities. No functionality change. The new name, qemuProcessQMPStop, is consistent with the existing function qemuProcessStop used to stop Domain processes. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
s/cmd/proc/ in process code imported from qemu_capabilities. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
Add the const qualifier on non modified strings (string only copied inside qemuProcessQMPNew) so that const strings can be used directly in calls to qemuProcessQMPNew in future patches. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
s/virQEMUCapsInitQMPCommand/qemuProcessQMP/ Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
QEMU process code in qemu_capabilities.c is moved to qemu_process.c in order to make the code usable outside the original capabilities use cases. The moved code activates and manages QEMU processes without establishing a guest domain. This patch is a straight cut/paste move between files. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-