- 15 10月, 2014 23 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Chen Fan 提交于
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 Peter Krempa 提交于
Shove it to the top of the file so that it can be reused earlier.
-
由 Peter Krempa 提交于
To allow easy implementation of a callback check this patch adds empty post parse callbacks to drivers that were missing them.
-
由 Peter Krempa 提交于
To allow live modification of device backends in qemu libvirt needs to be able to hot-add/remove "objects". Add monitor backend functions to allow this. This function will be used for hot-add/remove of RNG backends, IOThreads, memory backing objects, etc.
-
由 Peter Krempa 提交于
Add a new option specifier that will optionally add a JSON key=value pair containing a nested object if the added object isn't NULL.
-
由 Peter Krempa 提交于
The JSON structure constructor has an option to add JSON arrays to the constructed object. The description is inaccurate as it can add any json object even a dict. Change the docs to cover this option and reject adding NULL objects.
-
由 Peter Krempa 提交于
Our qemu monitor code has a converter from key-value pairs to a json value object. I want to re-use the code later and having it part of the monitor command generator is inflexible. Split it out into a separate helper.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
As in the device info iterator add a switch that will force the compiler to check that new device types are added to the ABI stability checker.
-
由 Peter Krempa 提交于
Although the device will probably inhibit migration add checks to make sure that the configuration change gets caught.
-
由 Peter Krempa 提交于
Use typecasted switch statement and note the type used to select the address type in a comment.
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Cole Robinson 提交于
-
由 Chen Fan 提交于
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 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>
-
由 Chen Fan 提交于
if specifying migration_host to an Ipv6 address without brackets, it was resolved to an incorrect address, such as: tcp:2001:0DB8::1428:4444, but the correct address should be: tcp:[2001:0DB8::1428]:4444 so we should add brackets when parsing it. Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 Ján Tomko 提交于
Helper function to strip the brackets from an IPv6 address. Tested by viruritest.
-
- 14 10月, 2014 2 次提交
-
-
由 Peter Krempa 提交于
Few places still used hardcoded limit for maximum XML size for commands that accept XML files. The hardcoded limits ranged from 8k to 1M. Use VSH_MAX_XML_FILE to express this limit in a unified way. This will bump the limit for the commands that used hardcoded string lengths to 10M. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1152427
-
由 Peter Krempa 提交于
dommemstat and blkdeviotune's man page incorrectly stated the usage of --live and --config.
-
- 13 10月, 2014 1 次提交
-
-
由 Wang Rui 提交于
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
-
- 12 10月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
The actual origin of this so called typo are two commits. The first one was commit 72f8a7f1 that came up with the following condition: if ((i == 8) & (flags & VIR_QEMU_PROCESS_KILL_FORCE)) Fortunately this succeeded thanks to bool being (int)1 and VIR_QEMU_PROCESS_KILL_FORCE having the value of 1 << 0. The check was then moved and altered in 8fd38231 to current state: if ((i == 50) & force) that will work again (both sides of '&' being booleans), but since this was missed so many times, it may pose a problem in the future in case it gets copy-pasted again. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 10月, 2014 4 次提交
-
-
由 Stefan Bader 提交于
This started as an investigation into an issue where libvirt (using the libxl driver) and the Xen host, like an old couple, could not agree on who is responsible for selecting the VNC port to use. Things usually (and a bit surprisingly) did work because, just like that old couple, they had the same idea on what to do by default. However it was possible that this ended up in a big argument. The problem is that display information exists in two different places: in the vfbs list and in the build info. And for launching the device model, only the latter is used. But that never gets initialized from libvirt. So Xen allows the device model to select a default port while libvirt thinks it has told Xen that this is done by libvirt (though the vfbs config). While fixing that, I made a stab at actually evaluating the configuration of the video device. So that it is now possible to at least decide between a Cirrus or standard VGA emulation and to modify the VRAM within certain limits using libvirt. Signed-off-by: NStefan Bader <stefan.bader@canonical.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
This patch introduces a function to detect whether the specified emulator is QEMU_XEN or QEMU_XEN_TRADITIONAL. Detection is based on the string "Options specific to the Xen version:" in '$qemu -help' output. AFAIK, the only qemu containing that string in help output is the old Xen fork (aka qemu-dm). Note: QEMU_XEN means a qemu that contains support for Xen. QEMU_XEN_TRADITIONAL means Xen's old forked qemu 0.10.2 Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
Allow the Xen drivers to determine default vram values. Sane default vaules depend on the device model being used, so the drivers are in the best position to determine the defaults. For the legacy xen driver, it is best to maintain the existing logic for setting default vram values to ensure there are no regressions. The libxl driver currently does not support configuring a video device. Support will be added in a subsequent patch, where the benefit of this change will be reaped. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
Commit 4dfc34c3 missed copying the user-specified keymap to libxl_domain_build_info struct when creating a VFB device. Signed-off-by: NStefan Bader <stefan.bader@canonical.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 09 10月, 2014 4 次提交
-
-
由 Shanzhi Yu 提交于
After set domain's numa parameters for running domain, save the change, save the change into live xml is needed to survive restarting the libvirtd, same story with bug 1146511; meanwihle add call qemuDomainObjBeginJob/qemuDomainObjEndJob in qemuDomainSetNumaParameters Signed-off-by: NShanzhi Yu <shyu@redhat.com>
-
由 Shanzhi Yu 提交于
add call qemuDomainObjBeginJob/qemuDomainObjEndJob in qemuDomainSetInterfaceParameters Signed-off-by: NShanzhi Yu <shyu@redhat.com>
-
由 Shanzhi Yu 提交于
After set the blkio parameters for running domain, save the change into live xml is needed to survive restarting the libvirtd, same story with bug 1146511, meanwhile add call qemuDomainObjBeginJob/qemuDomainObjEndJob in qemuDomainSetBlkioParameters Signed-off-by: NShanzhi Yu <shyu@redhat.com>
-
由 Jiri Denemark 提交于
The pkg-config files in src/ make it pretty easy to build language bindings against an uninstalled libvirt, however, they don't work with VPATH builds. The reason is that all *-api.xml files are generated in source rather than build directory. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 10月, 2014 4 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1147057 The code for relabelling the TAP FD is there due to a race. When libvirt creates a /dev/tapN device it's labeled as 'system_u:object_r:device_t:s0' by default. Later, when udev/systemd reacts to this device, it's relabelled to the expected label 'system_u:object_r:tun_tap_device_t:s0'. Hence, we have a code that relabels the device, to cut the race down. For more info see ae368ebf. But the problem is, the relabel function is called on all TUN/TAP devices. Yes, on /dev/net/tun too. This is however a special kind of device - other processes uses it too. We shouldn't touch it's label then. Ideally, there would an API in SELinux that would label just the passed FD and not the underlying path. That way, we wouldn't need to care as we would be not labeling /dev/net/tun but the FD passed to the domain. Unfortunately, there's no such API so we have to workaround until then. Tested-by: NRichard W.M. Jones <rjones@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Matthias Bolte 提交于
This implementation uses the https://esx-server/screen?id=<id> way to get a screenshot of a running domain. Compared to the CreateScreenshot_Task way this works since ESX 2.5 while CreateScreenshot_Task was added in version 4.0. The newly added libcurl stream driver is used to directly provide the downloaded data without saving it to a temporary file first.
-
由 Matthias Bolte 提交于
This allows to implement libvirt functions that use streams, such as virDoaminScreenshot, without the need to store the downloaded data in a temporary file first. The stream driver directly interacts with libcurl to send and receive data. The driver uses the libcurl multi interface that allows to do a transfer in multiple curl_multi_perform() calls. The easy interface would do the whole transfer in a single curl_easy_perform() call. This doesn't work with the libvirt stream API that is driven by multiple calls to the virStreamSend() and virStreamRecv() functions. The curl_multi_wait() function is used to do blocking operations. But it was added in libcurl 7.28.0. For older versions it is emulated using the socket callback of the multi interface. The current driver only supports blocking operations. There is already some code in place for non-blocking mode but it is not complete.
-
- 07 10月, 2014 1 次提交
-
-
由 Laine Stump 提交于
This patch fills in the functionality of processNicRxFilterChangedEvent(). It now checks if it is appropriate to respond to the NIC_RX_FILTER_CHANGED event (based on device type and configuration) and takes appropriate action. Currently it checks if the guest interface has been configured with trustGuestRxFilters='yes', and if the host side device is macvtap. If so, and the MAC address on the guest has changed, the MAC address of the macvtap device is changed to match. The result of this is that networking from the guest will continue to work if the mac address of a macvtap-connected network device is changed from within the guest, as long as trustGuestRxFilters='yes' (previously changing the MAC address in the guest would break networking).
-