- 27 1月, 2020 1 次提交
-
-
由 Daniel P. Berrangé 提交于
The intent here is to allow the virt drivers to be run directly embedded in an arbitrary process without interfering with libvirtd. To achieve this they need to store all their configuration & state in a separate directory tree from the main system or session libvirtd instances. This can be useful for doing testing of the virt drivers in "make check" without interfering with the user's own libvirtd instances. It can also be used for applications using KVM/QEMU as a piece of infrastructure to build an service, rather than for general purpose OS hosting. A long standing example is libguestfs, which would prefer if its temporary VMs did show up in the main libvirtd VM list, because this confuses apps such as OpenStack Nova. A more recent example would be Kata which is using KVM as a technology to build containers. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 25 1月, 2020 4 次提交
-
-
由 Jonathon Jongsma 提交于
If a domain is configured to have an egl-headless display and a virtio video device, virgl will be enabled automatically within the guest, even if the video device is configured with accel3d='no'. In this case we should explicitly pass 'virgl=off' to qemu. See https://bugzilla.redhat.com/show_bug.cgi?id=1791236 for more information. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Han Han 提交于
Since v4.2-rc0, QEMU introduced a builtin rng backend that uses getrandom() syscall to generate random. Add it to libvirt with the backend model 'builtin'. https://bugzilla.redhat.com/show_bug.cgi?id=1785091Signed-off-by: NHan Han <hhan@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Han Han 提交于
The 'builtin' rng backend model can be used as following: <rng model='virtio'> <backend model='builtin'/> </rng> Signed-off-by: NHan Han <hhan@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Han Han 提交于
It is used to check if qemu is capable of rng-builtin object. This object is added since qemu-4.2.0-rc0, commit 6c4e9d48. Signed-off-by: NHan Han <hhan@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 1月, 2020 11 次提交
-
-
由 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>
-
由 Peter Krempa 提交于
Don't use ERANGE as it doesn't make much sense in the error message. Also point out that the reply from qemu was too large which is not obvious from the original error: error: No complete monitor response found in 10485760 bytes: Numerical result out of range The new message will read: error: internal error: QEMU monitor reply exceeds buffer size (10485760 bytes) Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
libvirt treats 'luks' images as raw+encryption. The logic in qemuBlockStorageSourceCreateFormat skipped the creation if the requested image was raw but didn't take into account the encryption. This manifested itself e.g. when attempting to do a virsh blockcopy with the following XML: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/tmp/enccpy'> <encryption format='luks'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f'/> </encryption> </source> </disk> Where qemu would report the following error: unable to execute QEMU command 'blockdev-add': Volume is not in LUKS format rather than actually formatting the image first. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use the user-configured name of the bitmap when merging the appropriate bitmaps for an incremental backup so that the user can see it as configured. Additionally expose the default bitmap name if nothing is configured. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Peter Krempa 提交于
Pass the exportname as configured when exporting the image via NBD and fill it with the default if it's not configured. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
When using blockdev configurations the 'device' argument of 'blockdev-commit' must correspond to the topmost node in the block node graph. Libvirt didn't do this properly in case when 'copy_on_read' option was enabled on the disk. Use qemuDomainDiskGetTopNodename to fix it when calling block-commit. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
When using blockdev configurations the 'device' argument of 'blockdev-mirror' must correspond to the topmost node in the block node graph. Libvirt didn't do this properly in case when 'copy_on_read' option was enabled on the disk. Use qemuDomainDiskGetTopNodename to fix it for the blockdev-mirror calls in qemuDomainBlockCopy and the non-shared-storage migration. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
There are more places which require getting the topmost nodename to be passed to qemu. Separate it out into a new function. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
If a mirror job fails to start in -blockdev mode we'd not unplug the backing files we added first because the code on the error path checked the wrong value. 'rc' is used as status of the code which added the images, but the state of the 'block(dev)-mirror' call is stored in 'ret' at that point. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af0 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: NRichard W.M. Jones <rjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 23 1月, 2020 2 次提交
-
-
由 Thomas Huth 提交于
The "ps2" bus is only available on certain machines like x86. On machines like s390x, we should refuse to add a device to this bus instead of silently ignoring it. Looking at the QEMU sources, PS/2 is only available if the QEMU binary has the "i8042" device, so let's check for that and only allow "ps2" devices if this QEMU device is available, or if we're on x86 anyway (so we don't have to fake the QEMU_CAPS_DEVICE_I8042 capability in all the tests that use <input ... bus='ps2'/> in their xml data). Reported-by: NSebastian Mitterle <smitterl@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1763191Signed-off-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Julio Faracco 提交于
QEMU driver has two functions: qemuGetDHCPInterfaces() and qemuARPGetInterfaces() that are being used inside only one single function. They can be turned into generic functions that other drivers can use. This commit move both from QEMU driver tree to domain conf tree. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 1月, 2020 1 次提交
-
-
由 Ján Tomko 提交于
This function grabs an agent job but ends a monitor job. End the agent job instead. https://bugzilla.redhat.com/show_bug.cgi?id=1792723Signed-off-by: NJán Tomko <jtomko@redhat.com> Reported-by: NDan Zheng <dzheng@redhat.com> Fixes: e005c95f
-
- 17 1月, 2020 4 次提交
-
-
由 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é 提交于
gmtime_r/localtime_r are mostly used in combination with strftime to format timestamps in libvirt. This can all be replaced with GDateTime resulting in simpler code that is also more portable. There is some boundary condition problem in parsing POSIX timezone offsets in GLib which tickles our test suite. The test suite is hacked to avoid the problem. The upsteam GLib bug report is https://gitlab.gnome.org/GNOME/glib/issues/1999Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
G_STATIC_ASSERT() is a drop-in functional equivalent of the GNULIB verify() macro. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-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 16 次提交
-
-
由 Jonathon Jongsma 提交于
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
Switch from old VIR_ allocation APIs to glib equivalents. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
This function potentially grabs both a monitor job and an agent job at the same time. This is problematic because it means that a malicious (or just buggy) guest agent can cause a denial of service on the host. The presence of this function makes it easy to do the wrong thing and hold both jobs at the same time. All existing uses have already been removed by previous commits. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
In order to avoid holding an agent job and a normal job at the same time, we want to avoid accessing the domain's definition while holding the agent job. To achieve this, qemuAgentGetFSInfo() only returns the raw information from the agent query to the caller. The caller can then release the agent job and then proceed to look up the disk alias from the vm definition. This necessitates moving a few helper functions to qemu_driver.c and exposing the agent data structure (qemuAgentFSInfo) in the header. In addition, because the agent function no longer returns the looked-up disk alias, we can't test the alias within qemuagenttest. Instead we simply test that we parse and return the raw agent data correctly. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
The qemuAgentDiskInfo structure is filled with information received from the agent command response, except for the 'alias' field, which is retrieved from the vm definition. Limit this structure only to data that was received from the agent message. This is another intermediate step in moving the responsibility for searching the vmdef from qemu_agent.c to qemu_driver.c so that we can avoid holding an agent job and a normal job at the same time. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
In an effort to avoid holding both an agent and normal job at the same time, we shouldn't access the vm definition from within qemu_agent.c (i.e. while the agent job is being held). In preparation, we need to store the full filesystem disk information in qemuAgentDiskInfo. In a following commit, we can pass this information back to the caller and the caller can search the vm definition to match the filsystem disk to an alias. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
The function name doesn't give a good idea of what the function does. Rename to qemuAgentGetFSInfoFillDisks() to make it more obvious than it is filling in the disk information in the fsinfo struct. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrangé 提交于
QEMU since 4.1.0 supports the "dies" parameter for -smp Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Recently CPU hardware vendors have started to support a new structure inside the CPU package topology known as a "die". Thus the hierarchy is now: sockets > dies > cores > threads This adds support for "dies" in the XML parser, with the value defaulting to 1 if not specified for backwards compatibility. For example a system with 64 logical CPUs might report <topology sockets="4" dies="2" cores="4" threads="2"/> Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 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>
-
由 Michal Privoznik 提交于
When resuming a domain from a save file, we read the domain XML from the file, add it onto our internal list of domains, start the qemu process, let it load the incoming migration stream and resume its vCPUs afterwards. If anything goes wrong, the domain object is removed from the list of domains and error is returned to the caller. However, the qemu process might be left behind - if resuming vCPUs fails (e.g. because qemu is unable to acquire write lock on a disk) then due to a bug the qemu process is not killed but the domain object is removed from the list. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1718707Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Julio Faracco 提交于
We have to keep the default - querying the agent if no flag is set. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 13 1月, 2020 1 次提交
-
-
由 Thomas Huth 提交于
libvirt currently always reports that USB is available as a bus subsystem type when running "virsh domcapabilities". However, this is not always true, for example the qemu-system-s390x binary normally never has support for USB. Thus we should only report that USB is available if there is also a USB host controller available where we can attach USB devices. Reported-by: NSebastian Mitterle <smitterl@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1759849Signed-off-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-