- 15 10月, 2014 5 次提交
-
-
由 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 5 次提交
-
-
由 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).
-
由 Laine Stump 提交于
NIC_RX_FILTER_CHANGED is sent by qemu any time a NIC driver in the guest modified the NIC's RX Filter (for example, if the MAC address of the NIC is changed by the guest). This patch doesn't do anything useful with that event; it just sets up all the plumbing to get news of the event into a worker thread with all proper locking/reference counting, and provide an easy place to add in desired functionality. See src/qemu/EVENTHANDLERS.txt for information/instructions on adding a libvirt-internal handler for a qemu event (using NIC_RX_FILTER_CHANGED as an example).
-
由 Laine Stump 提交于
This text was in the commit log for the patch that added the event handler for NIC_RX_FILTER_CHANGED, and John Ferlan expressed a desire that the information not be "lost", so I've put it into a file in the qemu directory, hoping that it might catch the attention of future writers of handlers for qemu events.
-
由 Laine Stump 提交于
This function can be called at any time to get the current status of a guest's network device rx-filter. In particular it is useful to call after libvirt recieves a NIC_RX_FILTER_CHANGED event - this event only tells you that something has changed in the rx-filter, the details are retrieved with the query-rx-filter monitor command (only available in the json monitor). The command sent to the qemu monitor looks like this: {"execute":"query-rx-filter", "arguments": {"name":"net2"} }' and the results will look something like this: { "return": [ { "promiscuous": false, "name": "net2", "main-mac": "52:54:00:98:2d:e3", "unicast": "normal", "vlan": "normal", "vlan-table": [ 42, 0 ], "unicast-table": [ ], "multicast": "normal", "multicast-overflow": false, "unicast-overflow": false, "multicast-table": [ "33:33:ff:98:2d:e3", "01:80:c2:00:00:21", "01:00:5e:00:00:fb", "33:33:ff:98:2d:e2", "01:00:5e:00:00:01", "33:33:00:00:00:01" ], "broadcast-allowed": false } ], "id": "libvirt-14" } This is all parsed from JSON into a virNetDevRxFilter object for easier consumption. (unicast-table is usually empty, but is also an array of mac addresses similar to multicast-table). (NB: LIBNL_CFLAGS was added to tests/Makefile.am because virnetdev.h now includes util/virnetlink.h, which includes netlink/msg.h when appropriate. Without LIBNL_CFLAGS, gcc can't find that file (if libnl/netlink isn't available, LIBNL_CFLAGS will be empty and virnetlink.h won't try to include netlink/msg.h anyway).)
-
由 Laine Stump 提交于
This same structure will be used to retrieve RX filter info for interfaces on the host via netlink messages, and RX filter info for interfaces on the guest via the qemu "query-rx-filter" command.
-
- 06 10月, 2014 8 次提交
-
-
由 Laine Stump 提交于
As is done with other items such as vlan, virtualport, and bandwidth, set the actual trustGuestRxFilters value to be used by a domain interface according to a merge of the same attribute in the interface, portgroup, and network in use. the interface setting always takes precedence (if specified), followed by portgroup, and finally the setting in the network is used if it's not specified in the interface or portgroup.
-
由 Laine Stump 提交于
This new attribute will control whether or not libvirt will pay attention to guest notifications about changes to network device mac addresses and receive filters. The default for this is 'no' (for security reasons). If it is set to 'yes' *and* the specified device model and connection support it (currently only macvtap+virtio) then libvirt will watch for NIC_RX_FILTER_CHANGED events, and when it receives one, it will issue a query-rx-filter command, retrieve the result, and modify the host-side macvtap interface's mac address and unicast/multicast filters accordingly. The functionality behind this attribute will be in a later patch. This patch merely adds the attribute to the top-level of a domain's <interface> as well as to <network> and <portgroup>, and adds documentation and schema/xml2xml tests. Rather than adding even more test files, I've just added the net attribute in various applicable places of existing test files.
-
由 John Ferlan 提交于
Check for !dev->info.alias was done after a VIR_DEBUG() statement that already tried to print - just flip sequence
-
由 John Ferlan 提交于
Prior patch removed the need for the virConnectPtr in the unplug detach host path which caused ripple effect to remove in multiple callers. The previous patch just left things as ATTRIBUTE_UNUSED - this patch will remove the variable.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1141732 Introduced by commit id '8f76ad99' the logic to detach a scsi_host device (SCSI or iSCSI) fails when attempting to remove the 'drive' because as I found in my investigation - the DelDevice takes care of that for us. The investigation turned up commits to adjust the logic for the qemuMonitorDelDevice and qemuMonitorDriveDel processing for interfaces (commit id '81f76598'), disk bus=VIRTIO,SCSI,USB (commit id '0635785b'), and chr devices (commit id '55b21f9b'), but nothing with the host devices. This commit uses the model for the previous set of changes and applies it to the hostdev path. The call to qemuDomainDetachHostSCSIDevice will return to qemuDomainDetachThisHostDevice handling either the audit of the failure or the wait for the removal and then call into qemuDomainRemoveHostDevice for the event, removal from the domain hostdev list, and audit of the removal similar to other paths. NOTE: For now the 'conn' param to +qemuDomainDetachHostSCSIDevice is left as ATTRIBUTE_UNUSED. Removing requires a cascade of other changes to be left for a future patch.
-
由 Eric Blake 提交于
Consolidate several commits made by James: https://www.redhat.com/archives/libvir-list/2014-September/msg01156.htmlSigned-off-by: NEric Blake <eblake@redhat.com>
-
由 Ján Tomko 提交于
This lets me build against an uninstalled source tree without libtool.
-
由 Chen Hanxiao 提交于
s/the/The Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
-
- 04 10月, 2014 6 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5 libxml2 removes two slashes from the URI when there is no server part. This is fixed with beb7281055dbf0ed4d041022a67c6c5cfd126f25, but only if the calling application calls xmlSaveUri() on URI that xmlURIParse() parsed. And that is not the case in virURIFormat(). virURIFormat() accepts virURIPtr that can be created without parsing it and we do that when we format network storage paths for gluster for example. Even though virStorageSourceParseBackingURI() uses virURIParse(), it throws that data structure right away. Since we want to format URIs as URIs and not absolute URIs or opaque URIs (see RFC 3986), we can specify that with a special hack thanks to commit beb7281055dbf0ed4d041022a67c6c5cfd126f25, by setting port to -1. This fixes qemuxml2argvtest test where the disk-drive-network-gluster case was failing. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Since 87dea4fc vboxGetDrivers() is not used for getting the vbox network driver. The only call the code does is using NULL as the @networkDriver_ret param , but the code still used vbox[0-9][0-9]NetworkDriver that didn't exist anymore. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This patch implements support for the ivshmem device in QEMU. Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Maxime Leroy 提交于
Ivshmem is supported by QEMU since 0.13 release. Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This patch adds parsing/formatting code as well as documentation for shared memory devices. This will currently be only accessible in QEMU using it's ivshmem device, but is designed as generic as possible to allow future expansion for other hypervisors. In the devices section in the domain XML users may specify: - For shmem device using a server: <shmem name='shmem0'> <server path='/tmp/socket-ivshmem0'/> <size unit='M'>32</size> <msi vectors='32' ioeventfd='on'/> </shmem> - For ivshmem device not using an ivshmem server: <shmem name='shmem1'> <size unit='M'>32</size> </shmem> Most of the configuration is made optional so it also allows specifications like: <shmem name='shmem1/> <shmem name='shmem2'> <server/> </shmem> Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-