- 20 5月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
virConfGetValueString returns an allocated string that needs to be freed. Fixes: 34a59fb5Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 05 5月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
Instead of the following pattern: type ret; ... ret = func(); return ret; we can use: return func() directly. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 07 4月, 2020 5 次提交
-
-
由 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>
-
由 Michal Privoznik 提交于
This reverts commit 06a19921. What I haven't realized when writing this ^^ commit is that the virQEMUDriver structure already stores the root directory path. And since the pointer is immutable it can be accessed right from the structure and thus there is no need to duplicate it in the driver config. 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 提交于
Initially introduced in v3.10.0-rc1~172. When generating a path for memory-backend-file or -mem-path, qemu driver will use the following pattern: $memoryBackingDir/libvirt/qemu/$id-$shortName where $memoryBackingDir defaults to /var/lib/libvirt/qemu/ram but can be overridden in qemu.conf. Anyway, the "/libvirt/qemu/" part looks redundant, because it's already contained in the default, or creates unnecessary nesting if overridden in qemu.conf. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Michal Privoznik 提交于
Introduced in v1.2.17-rc1~121, the assumption was that the driver->privileged is immutable at the time but it might change in the future. Well, it did not ever since. It is still immutable variable. Drop the needless accessor then. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 24 3月, 2020 2 次提交
-
-
由 Marc-André Lureau 提交于
Location of DBus daemon state configuration, socket, pid... Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 3月, 2020 1 次提交
-
-
由 Michal Privoznik 提交于
When initializing virQEMUDriverConfig structure we are given the root directory for possible embed connection. Save it for future use. While we could get it later from @uri member, it's not as easy as dereferencing a pointer (virURIParse() + virURIGetParam() + error reporting). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 04 3月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
Add a 'virtiofsd_debug' option for tuning whether to run virtiofsd in debug mode. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com> Tested-by: NAndrea Bolognani <abologna@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>
-
- 04 2月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Most code now uses the virProcess / virCommand APIs, so the need for sys/wait.h is quite limited. Removing this include removes the dependency on GNULIB providing a dummy sys/wait.h for Windows. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 02 2月, 2020 1 次提交
-
-
由 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>
-
- 31 1月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
The rewrite to use GLib's atomic ops functions changed the behavior of virAtomicIntInc - before it returned the pre-increment value. Most of the callers using its value were adjusted, but the one in qemuDriverAllocateID was not. If libvirtd would reconnect to a running domain during startup, the next started domain would get the same ID: $ virsh list Id Name State -------------------------- 1 f28live running 1 f28live1 running Use the g_atomic_add function directly (as recommended in viratomic.h) and add 1 to the result. This also restores the usual numbering from 1 instead of 0. Signed-off-by: NJán Tomko <jtomko@redhat.com> Fixes: 7b9645a7Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
- 29 1月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
There are a large number of different header files that are related to the sockets APIs. The virsocket.h header includes all of the relevant headers for Windows and UNIX in one convenient place. If virsocketaddr.h is already included, then there's no need for virsocket.h Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@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>
-
- 24 1月, 2020 2 次提交
-
-
由 Michal Privoznik 提交于
Since v5.6.0-48-g270583ed we try to cache domain capabilities, i.e. store filled virDomainCaps in a hash table in virQEMUCaps for future use. However, there's a race condition in the way it's implemented. We use virQEMUCapsGetDomainCapsCache() to obtain the pointer to the hash table, then we search the hash table for cached data and if none is found the domcaps is constructed and put into the table. Problem is that this is all done without any locking, so if there are two threads trying to do the same, one will succeed and the other will fail inserting the data into the table. Also, the API looks a bit fishy - obtaining pointer to the hash table is dangerous. The solution is to use a mutex that guards the whole operation with the hash table. Then, the API can be changes to return virDomainCapsPtr directly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1791790Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
When fixing [1] I've ran attached reproducer and had it spawn 1024 threads and query capabilities XML in each one of them. This lead libvirtd to hit the RLIMIT_NOFILE limit which was kind of expected. What wasn't expected was a subsequent segfault. It happened because virCPUProbeHost failed and returned NULL. We've taken the NULL and passed it to virCapabilitiesHostNUMARef() which dereferenced it. Code inspection showed the same flas in virQEMUDriverGetHostNUMACaps(), so I'm fixing both places. 1: https://bugzilla.redhat.com/show_bug.cgi?id=1791790Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
- 08 1月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
Remove the 'gluster' part and decouple the return from the gluster_debug_level parsing to allow adding more options to this section. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 20 12月, 2019 3 次提交
-
-
由 Fabiano Fidêncio 提交于
virGetUserRuntimeDirectory() *never* *ever* returns NULL, making the checks for it completely unnecessary. Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Fabiano Fidêncio 提交于
virGetUserConfigDirectory() *never* *ever* returns NULL, making the checks for it completely unnecessary. Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Fabiano Fidêncio 提交于
virGetUserCacheDirectory() *never* *ever* returns NULL, making the checks for it completely unnecessary. Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 12 12月, 2019 1 次提交
-
-
由 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>
-
- 09 12月, 2019 5 次提交
-
-
由 Daniel P. Berrangé 提交于
Now that nearly all internal APIs use the QEMU capabilities or other QEMU driver data directly, there's no compelling benefit to create virCapsPtr at driver startup. Skipping this means we don't probe capabilities for all 30 system emulator targets at startup, only those emulators which are referenced by an XML doc. This massively improves libvirtd startup time when the capabilities cache is not populated. It even improves startup time when the cache is up to date, as we don't bother to load files from the cache until we need them. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Avoid grabbing the whole virCapsPtr object when we only need the host CPU information. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Avoid grabbing the whole virCapsPtr object when we only need the NUMA information. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Instead of using the virCapsPtr to get the default security model, pass this in via the parser config. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 22 11月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
This previous commit introduced a simpler free callback for hash data with only 1 arg, the value to free: commit 49288fac Author: Peter Krempa <pkrempa@redhat.com> Date: Wed Oct 9 15:26:37 2019 +0200 util: hash: Add possibility to use simpler data free function in virHash It missed two functions in the hash table code which need to call the alternate data free function, virHashRemoveEntry and virHashRemoveSet. After the previous patch though, there is no code that makes functional use of the 2nd key arg in the data free function. There is merely one log message that can be dropped. We can thus purge the current virHashDataFree callback entirely, and rename virHashDataFreeSimple to replace it. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 12 11月, 2019 2 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
There are two ways for specifying loader:nvram pairs: 1) --with-loader-nvram configure option 2) nvram variable in qemu.conf Since we have FW descriptors, using this old style is discouraged, but not as strong as one would expect. Produce more warnings: 1) produce a warning if somebody tries the configure option 2) produce a warning if somebody sets nvram variable and at least on FW descriptor was found The reason for producing warning in case 1) is that package maintainers, who set the configure option in the first place should start moving towards FW descriptors and abandon the configure option. After all, the warning is printed into config output only in this case. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1763477Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 21 10月, 2019 1 次提交
-
-
由 Ján Tomko 提交于
Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 10月, 2019 1 次提交
-
-
由 Cole Robinson 提交于
When searching qemuCaps->domCapsCache for existing domCaps data, we check for a matching pair of arch+virttype+machine+emulator. However for the hash table key we only use the machine string. So if the cache already contains: x86_64 + kvm + pc + /usr/bin/qemu-kvm But a new VM is defined with x86_64 + qemu + pc + /usr/bin/qemu-kvm We correctly fail to find matching cached domCaps, but then attempt to use a colliding key with virHashAddEntry Fix this by building a hash key from the 4 values, not just machine Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 16 10月, 2019 4 次提交
-
-
由 Ján Tomko 提交于
Prefer: return g_steal_pointer(&ptr); Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Now that all the types using VIR_AUTOUNREF have a cleanup func defined to virObjectUnref, use g_autoptr instead of VIR_AUTOUNREF. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Since commit 44e7f029 util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOPTR aliases to g_autoptr. Replace all of its use by the GLib macro version. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Since commit 44e7f029 util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 10月, 2019 2 次提交
-
-
由 Ján Tomko 提交于
Prefer the GLib version of the macro. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-