- 13 9月, 2016 1 次提交
-
-
由 Laine Stump 提交于
virQEMUDriverConfigNew() always initializes the bitmap in its cgroupControllers member to -1 (i.e. all 1's). Prior to commit a9331394, if qemu.conf had a line with "cgroup_controllers", cgroupControllers would get reset to 0 before going through a loop setting a bit for each named cgroup controller. commit a9331394 left out the "reset to 0" part, so cgroupControllers would always be -1; if you didn't want a controller included, there was no longer a way to make that happen. This was discovered by users who were using qemu commandline passthrough to use the "input-linux" method of directing keyboard/mouse input to a virtual machine: https://www.redhat.com/archives/vfio-users/2016-April/msg00105.html Here's the first report I found of the problem encountered after upgrading libvirt beyond v2.0.0: https://www.redhat.com/archives/vfio-users/2016-August/msg00053.html Thanks to sL1pKn07 SpinFlo <sl1pkn07@gmail.com> for bringing the problem up in IRC, and then taking the time to do a git bisect and find the patch that started the problem.
-
- 09 9月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Add a new TLS X.509 certificate type - "chardev". This will handle the creation of a TLS certificate capability (and possibly repository) for properly configured character device TCP backends. Unlike the vnc and spice there is no "listen" or "passwd" associated. The credentials eventually will be handled via a libvirt secret provided to a specific backend. Make use of the default verify option as well. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than specify perhaps multiple TLS X.509 certificate directories, let's create a "default" directory which can then be used if the service (e.g. for now vnc and spice) does not supply a default directory. Since the default for vnc and spice may have existed before without being supplied, the default check will first check if the service specific path exists and if so, set the cfg entry to that; otherwise, the default will be set to the (now) new defaultTLSx509certdir. Additionally add a "default_tls_x509_verify" entry which can also be used to force the peer verification option (for vnc it's a x509verify option). Add/alter the macro for the option being found in the config file to accept the default value. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 06 9月, 2016 2 次提交
-
-
由 Daniel P. Berrange 提交于
We already have the ability to turn off dumping of guest RAM via the domain XML. This is not particularly useful though, as it is under control of the management application. What is needed is a way for the sysadmin to turn off guest RAM defaults globally, regardless of whether the mgmt app provides its own way to set this in the domain XML. So this adds a 'dump_guest_core' option in /etc/libvirt/qemu.conf which defaults to false. ie guest RAM will never be included in the QEMU core dumps by default. This default is different from historical practice, but is considered to be more suitable as a default because a) guest RAM can be huge and so inflicts a DOS on the host I/O subsystem when dumping core for QEMU crashes b) guest RAM can contain alot of sensitive data belonging to the VM owner. This should not generally be copied around inside QEMU core dumps submitted to vendors for debugging c) guest RAM contents are rarely useful in diagnosing QEMU crashes Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the QEMU processes inherit their core dump rlimit from libvirtd, which is really suboptimal. This change allows their limit to be directly controlled from qemu.conf instead.
-
- 10 8月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
Since a9331394 (first release v2.1.0), specifying a manual security_driver setting in qemu.conf causes the daemon to fail to start, erroring with 'Duplicate security driver X'. The duplicate checking was incorrectly comparing every entry against itself, guaranteeing a false positive. https://bugzilla.redhat.com/show_bug.cgi?id=1365607
-
- 04 8月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 7月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 14 6月, 2016 1 次提交
-
-
由 Jim Fehlig 提交于
The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 09 6月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 09 5月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
For disks sources described by a libvirt volume we don't need to do a complicated check since virStorageTranslateDiskSourcePool already correctly determines the actual disk type. Replace the checks using a new accessor that does not open-code the whole logic.
-
- 28 4月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Instead of setting the default qemu stdio logging approach in virQEMUDriverConfigLoadFile set it in virQEMUDriverConfigNew so that it's properly set even when the config is not present. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325075
-
- 18 2月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
Which is the only user. That was the only reason for including qemu_command.h, though we need to explicitly include qemu_domain.h afterwards.
-
- 26 11月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
Currently the QEMU stdout/stderr streams are written directly to a regular file (eg /var/log/libvirt/qemu/$GUEST.log). While those can be rotated by logrotate (using copytruncate option) this is not very efficient. It also leaves open a window of opportunity for a compromised/broken QEMU to DOS the host filesystem by writing lots of text to stdout/stderr. This makes it possible to connect the stdout/stderr file handles to a pipe that is provided by virtlogd. The virtlogd daemon will read from this pipe and write data to the log file, performing file rotation whenever a pre-determined size limit is reached. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 22 9月, 2015 1 次提交
-
-
由 John Ferlan 提交于
This reverts commit 69b850fe. This change broke the ability to "clear" or reset unfiltered back to filtered.
-
- 14 8月, 2015 1 次提交
-
-
由 Guido Günther 提交于
RedHat and Debian based distros use different locations Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790935
-
- 04 8月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Rather than provide a somewhat generic error message when the API returns false, allow the caller to supply a "report = true" option in order to cause virReportError's to describe which of the 3 paths that can cause failure. Some callers don't care about what caused the failure, they just want to have a true/false - for those, calling with report = false should be sufficient.
-
- 29 7月, 2015 1 次提交
-
-
由 Erik Skultety 提交于
Our atomic increment (virAtomicIntInc) uses (if available) gcc __sync_add_and_fetch builtin. In qemu driver though, we'd profit more from __sync_fetch_and_add builtin. To keep it simplistic, this patch adjusts qemu driver initialization rather than adding a new atomic increment macro.
-
- 10 7月, 2015 1 次提交
-
-
由 Guido Günther 提交于
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]
-
- 09 7月, 2015 6 次提交
-
-
由 John Ferlan 提交于
Setting of 'val' is a boolean expression, so handle it that way and adjust the check/return logic to be clearer Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Set to ret = -1 and prove otherwise, like usual Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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 Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Introduce a convenience function to handle formulating the hostdev path Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
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. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 18 6月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
The privileged flag will not change while the configuration might change. Make the 'privileged' flag member of the driver again and mark it immutable. Should that ever change add an accessor that will group reads of the state.
-
- 24 4月, 2015 3 次提交
-
-
由 Cole Robinson 提交于
Similar to what was done for the channel socket in the previous commit.
-
由 Cole Robinson 提交于
Rather than depend on the RPM to put it in place, since this doesn't cover the qemu:///session case. Currently auto allocated socket path is completely busted with qemu:///session https://bugzilla.redhat.com/show_bug.cgi?id=1105274 And because we chown the directory at driver startup now, this also fixes autosocket startup failures when using user/group=root https://bugzilla.redhat.com/show_bug.cgi?id=1044561 https://bugzilla.redhat.com/show_bug.cgi?id=1146886
-
由 Cole Robinson 提交于
Rather than duplicate libDir for each new path
-
- 21 4月, 2015 1 次提交
-
-
由 Cole Robinson 提交于
- Remove all qemu emulators - Restart libvirtd - Install qemu emulators - Call 'virsh version' -> errors The only thing that will force the qemu driver to refresh it's cached capablities info is an explict API call to GetCapabilities. However in the case when the initial caps lookup at driver connect didn't find a single qemu emulator to poll, the driver is effectively useless and really can't do anything until it's populated some qemu capabilities info. With the above steps, the user would have to either know about the magic refresh capabilities call, or restart libvirtd to pick up the changes. Instead, this patch changes things so that every time a part of th driver requests access to capabilities info, check to see if we've previously seen any emulators. If not, force a refresh. In the case of 'still no emulators found', this is still very quick, so I can't think of a downside. https://bugzilla.redhat.com/show_bug.cgi?id=1000116
-
- 22 2月, 2015 1 次提交
-
-
由 Cole Robinson 提交于
The AAVMF and OVMF names were swapped. Reorder the one usage where it matters so behavior doesn't change.
-
- 29 1月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
Well, even though users can pass the list of UEFI:NVRAM pairs at the configure time, we may maintain the list of widely available UEFI ourselves too. And as arm64 begin to rises, OVMF was ported there too. With a slight name change - it's called AAVMF, with AAVMF_CODE.fd being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Up until now there are just two ways how to specify UEFI paths to libvirt. The first one is editing qemu.conf, the other is editing qemu_conf.c and recompile which is not that fancy. So, new configure option is introduced: --with-loader-nvram which takes a list of pairs of UEFI firmware and NVRAM store. This way, the compiled in defaults can be passed during compile time without need to change the code itself. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 19 1月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
Using the same driver multiple times is pointless and it can result in confusing errors: $ virsh start test error: Failed to start domain test error: internal error: security label already defined for VM https://bugzilla.redhat.com/show_bug.cgi?id=1153891
-
- 17 12月, 2014 1 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1174569 There's nothing we need to do for shared iSCSI devices in qemuAddSharedHostdev and qemuRemoveSharedHostdev. The iSCSI layer takes care about that for us. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 12月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1160995 In our config files users are expected to pass several integer values for different configuration knobs. However, majority of them expect a nonnegative number and only a few of them accept a negative number too (notably keepalive_interval in libvirtd.conf). Therefore, a new type to config value is introduced: VIR_CONF_ULONG that is set whenever an integer is positive or zero. With this approach knobs accepting VIR_CONF_LONG should accept VIR_CONF_ULONG too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 10月, 2014 2 次提交
-
-
由 Chen Fan 提交于
When enabling the migration_address option, by default it is set to "127.0.0.1", but it's not a valid address for migration. so we should add verification and set the default migration_address to "0.0.0.0". Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Chen Fan 提交于
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 18 9月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Commit f36a94f2 introduced a double free on all success paths in qemuSharedDeviceEntryInsert. Only call qemuSharedDeviceEntryFree on the error path and set entry to NULL before jumping there if the entry already is in the hash table. https://bugzilla.redhat.com/show_bug.cgi?id=1142722
-