- 07 4月, 2020 2 次提交
-
-
由 Michal Privoznik 提交于
So far, libvirt generates the following path for memory: $memoryBackingDir/$id-$shortName/ram-nodeN where $memoryBackingDir is the path where QEMU mmaps() memory for the guest (e.g. /var/lib/libvirt/qemu/ram), $id is domain ID and $shortName is shortened version of domain name. So for instance, the generated path may look something like this: /var/lib/libvirt/qemu/ram/1-QEMUGuest/ram-node0 While in case of embed driver the following path would be generated by default: $root/lib/qemu/ram/1-QEMUGuest/ram-node0 which is not clashing with other embed drivers, we allow users to override the default and have all embed drivers use the same prefix. This can create clashing paths. Fortunately, we can reuse the approach for machined name generation (v6.1.0-178-gc9bd08ee) and include part of hash of the root in the generated path. Note, the important change is in qemuGetMemoryBackingBasePath(). The rest is needed to pass driver around. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
So far, libvirt generates the following path for hugepages: $mnt/libvirt/qemu/$id-$shortName where $mnt is the mount point of hugetlbfs corresponding to hugepages of desired size (e.g. /dev/hugepages), $id is domain ID and $shortName is shortened version of domain name. So for instance, the generated path may look something like this: /dev/hugepages/libvirt/qemu/1-QEMUGuest But this won't work with embed driver really, because if there are two instances of embed driver, and they both want to start a domain with the same name and with hugepages, both drivers will generate the same path which is not desired. Fortunately, we can reuse the approach for machined name generation (v6.1.0-178-gc9bd08ee) and include part of hash of the root in the generated path. Note, the important change is in qemuGetBaseHugepagePath(). The rest is needed to pass driver around. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 30 3月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
In previous commit: commit e6afacb0 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Wed Feb 12 12:26:11 2020 +0000 qemu: start/stop an event loop thread for domains A bogus comment was added claiming we didn't need to shutdown the event thread in the qemuProcessStop method, because this would be done in the monitor EOF callback. This was wrong because the EOF callback only runs in the case of a QEMU crash or a guest initiated clean shutdown & poweroff. In the case where the libvirt admin calls virDomainDestroy, the EOF callback never fires because we have already unregistered the event callbacks. We must thus always attempt to stop the event thread in qemuProcessStop. Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reported-by: NPeter Krempa <pkrempa@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 24 3月, 2020 2 次提交
-
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Now, that our virCommandSetPidFile() is more intelligent we don't need to rely on the daemon to create and lock the pidfile and use virCommandSetPidFile() at the same time. NOTE that as advertised in the previous commit, this was temporarily broken, because both virCommand and qemuProcessStartManagedPRDaemon() would try to lock the pidfile. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
- 17 3月, 2020 1 次提交
-
-
由 Gaurav Agrawal 提交于
Signed-off-by: NGaurav Agrawal <agrawalgaurav@gnome.org> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 14 3月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
Remove lots of stack-allocated buffers. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 13 3月, 2020 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Sync was introduced in [1] to check for ga presence. This check is racy but in the era before serial events are available there was not better solution I guess. In case we have the events the sync function is different. It allows us to flush stateless ga channel from remnants of previous communications. But we need to do it only once. Until we get timeout on issued command channel state is ok. [1] qemu_agent: Issue guest-sync prior to every command Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 3月, 2020 4 次提交
-
-
由 Daniel P. Berrangé 提交于
This converts the QEMU agent APIs to use the per-VM event loop, which involves switching from virEvent APIs to GMainContext / GSource APIs. A GSocket is used as a convenient way to create a GSource for a socket, but is not yet used for actual I/O. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
This converts the QEMU monitor APIs to use the per-VM event loop, which involves switching from virEvent APIs to GMainContext / GSource APIs. A GSocket is used as a convenient way to create a GSource for a socket, but is not yet used for actual I/O. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
In common with regular QEMU guests, the QMP probing will need an event loop for handling monitor I/O operations. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The event loop thread will be responsible for handling any per-domain I/O operations, most notably the QEMU monitor and agent sockets. We start this event loop when launching QEMU, but stopping the event loop is a little more complicated. The obvious idea is to stop it in qemuProcessStop(), but if we do that we risk loosing the final events from the QEMU monitor, as they might not have been read by the event thread at the time we tell the thread to stop. The solution is to delay shutdown of the event thread until we have seen EOF from the QEMU monitor, and thus we know there are no further events to process. Note that this assumes that we don't have events to process from the QEMU agent. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 3月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
When preparing images for block jobs we modify their seclabels so that QEMU can open them. However, as mentioned in the previous commit, secdrivers base some it their decisions whether the image they are working on is top of of the backing chain. Fortunately, in places where we call secdrivers we know this and the information can be passed to secdrivers. The problem is the following: after the first blockcommit from the base to one of the parents the XATTRs on the base image are not cleared and therefore the second attempt to do another blockcommit fails. This is caused by blockcommit code calling qemuSecuritySetImageLabel() over the base image, possibly multiple times (to ensure RW/RO access). A naive fix would be to call the restore function. But this is not possible, because that would deny QEMU the access to the base image. Fortunately, we can use the fact that seclabels are remembered only for the top of the backing chain and not for the rest of the backing chain. And thanks to the previous commit we can tell secdrivers which images are top of the backing chain. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1803551Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
- 05 3月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Historically threads are given a name based on the C function, and this name is just used inside libvirt. With OS level thread naming this name is now visible to debuggers, but also has to fit in 15 characters on Linux, so function names are too long in some cases. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 04 3月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
Pass logManager to qemuExtDevicesStart for future usage. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Tested-by: NAndrea Bolognani <abologna@redhat.com>
-
- 26 2月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
This function only uses the domain definition. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 25 2月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
Include virutil.h in all files that use it, instead of relying on it being pulled in somehow. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 20 2月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
In two places where virPidFileForceCleanupPath() is called, we try to unlink() the pidfile again. This is needless because virPidFileForceCleanupPath() has done just that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 07 2月, 2020 2 次提交
-
-
由 zhenwei pi 提交于
Pvpanic device supports bit 1 as crashloaded event, it means that guest actually panicked and run kexec to handle error by guest side. Handle crashloaded as a lifecyle event in libvirt. Test case: Guest side: before testing, we need make sure kdump is enabled, 1, build new pvpanic driver (with commit from upstream e0b9a42735f2672ca2764cfbea6e55a81098d5ba 191941692a3d1b6a9614502b279be062926b70f5) 2, insmod new kmod 3, enable crash_kexec_post_notifiers, # echo 1 > /sys/module/kernel/parameters/crash_kexec_post_notifiers 4, trigger kernel panic # echo 1 > /proc/sys/kernel/sysrq # echo c > /proc/sysrq-trigger Host side: 1, build new qemu with pvpanic patches (with commit from upstream 600d7b47e8f5085919fd1d1157f25950ea8dbc11 7dc58deea79a343ac3adc5cadb97215086054c86) 2, build libvirt with this patch 3, handle lifecycle event and trigger guest side panic # virsh event stretch --event lifecycle event 'lifecycle' for domain stretch: Crashed Crashloaded events received: 1 Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com>
-
由 Jiri Denemark 提交于
The usability of a specific CPU mode may depend on machine type, let's prepare for this by passing it to virQEMUCapsIsCPUModeSupported. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 02 2月, 2020 3 次提交
-
-
由 Michal Privoznik 提交于
Now, that every use of virAtomic was replaced with its g_atomic equivalent, let's remove the module. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 27 1月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
This enables support for running QEMU embedded to the calling application process using a URI: qemu:///embed?root=/some/path Note that it is important to keep the path reasonably short to avoid risk of hitting the limit on UNIX socket path names which is 108 characters. When using the embedded mode with a root=/var/tmp/embed, the driver will use the following paths: logDir: /var/tmp/embed/log/qemu swtpmLogDir: /var/tmp/embed/log/swtpm configBaseDir: /var/tmp/embed/etc/qemu stateDir: /var/tmp/embed/run/qemu swtpmStateDir: /var/tmp/embed/run/swtpm cacheDir: /var/tmp/embed/cache/qemu libDir: /var/tmp/embed/lib/qemu swtpmStorageDir: /var/tmp/embed/lib/swtpm defaultTLSx509certdir: /var/tmp/embed/etc/pki/qemu These are identical whether the embedded driver is privileged or unprivileged. This compares with the system instance which uses logDir: /var/log/libvirt/qemu swtpmLogDir: /var/log/swtpm/libvirt/qemu configBaseDir: /etc/libvirt/qemu stateDir: /run/libvirt/qemu swtpmStateDir: /run/libvirt/qemu/swtpm cacheDir: /var/cache/libvirt/qemu libDir: /var/lib/libvirt/qemu swtpmStorageDir: /var/lib/libvirt/swtpm defaultTLSx509certdir: /etc/pki/qemu At this time all features present in the QEMU driver are available when running in embedded mode, availability matching whether the embedded driver is privileged or unprivileged. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 17 1月, 2020 2 次提交
-
-
由 Pavel Hrdina 提交于
The function virSecretGetSecretString calls into secret driver and is used from other hypervisors drivers and as such makes more sense in util. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Libvirt's original atomic ops impls were largely copied from GLib's code at the time. The only API difference was that libvirt's virAtomicIntInc() would return a value, but g_atomic_int_inc was void. We thus use g_atomic_int_add(v, 1) instead, though this means virAtomicIntInc() now returns the original value, instead of the new value. This rewrites libvirt's impl in terms of g_atomic_int* as a short term conversion. The key motivation was to quickly eliminate use of GNULIB's verify_expr() macro which is not a direct match for G_STATIC_ASSERT_EXPR. Long term all the callers should be updated to use g_atomic_int* directly. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 16 1月, 2020 1 次提交
-
-
由 Jiri Denemark 提交于
When pause-before-switchover QEMU capability is enabled, we get STOP event before MIGRATION event with postcopy-active state. To properly handle post-copy migration and emit correct events commit v4.10.0-rc1-4-geca9d21e added a hack to qemuProcessHandleMigrationStatus which translates the paused state reason to VIR_DOMAIN_PAUSED_POSTCOPY and emits VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY event when migration state changes to post-copy. However, the code was effective on both sides of migration resulting in a confusing VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY event on the destination host, where entering post-copy mode is already properly advertised by VIR_DOMAIN_EVENT_RESUMED_POSTCOPY event. https://bugzilla.redhat.com/show_bug.cgi?id=1791458Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 07 1月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
This function needs domain definition really, we don't need to pass the whole domain object. This saves couple of dereferences and characters esp. in more checks to come. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 06 1月, 2020 2 次提交
-
-
由 Peter Krempa 提交于
Commit d75f865f caused a job-deadlock if a VM is running the backup job and being destroyed as it removed the cleanup of the async job type and there was nothing to clean up the backup job. Add an explicit cleanup of the backup job when destroying a VM. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainObjPrivateDataClear clears state which become invalid after VM stopped running and the node name allocator belongs there. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 24 12月, 2019 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
If we use fake reboot then domain goes thru running->shutdown->running state changes with shutdown state only for short period of time. At least this is implementation details leaking into API. And also there is one real case when this is not convinient. I'm doing a backup with the help of temporary block snapshot (with the help of qemu's API which is used in the newly created libvirt's backup API). If guest is shutdowned I want to continue to backup so I don't kill the process and domain is in shutdown state. Later when backup is finished I want to destroy qemu process. So I check if it is in shutdowned state and destroy it if it is. Now if instead of shutdown domain got fake reboot then I can destroy process in the middle of fake reboot process. After shutdown event we also get stop event and now as domain state is running it will be transitioned to paused state and back to running later. Though this is not critical for the described case I guess it is better not to leak these details to user too. So let's leave domain in running state on stop event if fake reboot is in process. Reconnection code handles this patch without modification. It detects that qemu is not running due to shutdown and then calls qemuProcessShutdownOrReboot which reboots as fake reboot flag is set. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 21 12月, 2019 4 次提交
-
-
由 Daniel Henrique Barboza 提交于
The 'cleanup' flag is doing no cleaup in this function. We can remove it and return NULL on error or qemuBuildCommandLine(). Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Daniel Henrique Barboza 提交于
The g_auto*() changes made by the previous patches made a lot of 'cleanup' labels obsolete. Let's remove them. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Daniel Henrique Barboza 提交于
Change all feasible pointers to use g_autoptr(). Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Daniel Henrique Barboza 提交于
Change all feasible strings and scalar pointers to use g_autofree. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 17 12月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
Now, that we have everything prepared, we can generate command line for NVMe disks. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 12 12月, 2019 2 次提交
-
-
由 Daniel P. Berrangé 提交于
This reverts commit 7be5fe66. This commit broke resctrl, because it missed the fact that the virResctrlInfoGetCache() has side-effects causing it to actually change the virResctrlInfo parameter, not merely get data from it. This code will need some refactoring before we can try separating it from virCapabilities again. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
When QEMU uid/gid is set to non-root this is pointless as if we just used a regular setuid/setgid call, the process will have all its capabilities cleared anyway by the kernel. When QEMU uid/gid is set to root, this is almost (always?) never what people actually want. People make QEMU run as root in order to access some privileged resource that libvirt doesn't support yet and this often requires capabilities. As a result they have to go find the qemu.conf param to turn this off. This is not viable for libguestfs - they want to control everything via the XML security label to request running as root regardless of the qemu.conf settings for user/group. Clearing capabilities was implemented originally because there was a proposal in Fedora to change permissions such that root, with no capabilities would not be able to compromise the system. ie a locked down root account. This never went anywhere though, and as a result clearing capabilities when running as root does not really get us any security benefit AFAICT. The root user can easily do something like create a cronjob, which will then faithfully be run with full capabilities, trivially bypassing the restriction we place. IOW, our clearing of capabilities is both useless from a security POV, and breaks valid use cases when people need to run as root. This removes the clear_emulator_capabilities configuration option from qemu.conf, and always runs QEMU with capabilities when root. The behaviour when non-root is unchanged. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 10 12月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
We will want to use the async job infrastructure along with all the APIs and event for the backup job so add the backup job as a new async job type. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 09 12月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
We always refresh the capabilities object when using virResctrlInfo during process startup. This is undesirable overhead, because we can just directly create a virResctrlInfo instead. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-