- 26 3月, 2015 2 次提交
- 18 3月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
Not all NICs (esp. the virtual ones like TUN) must have a hardware address. Teach our RPC that it's possible. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 3月, 2015 1 次提交
-
-
由 Nehal J Wani 提交于
daemon/remote.c * Define remoteSerializeDomainInterface, remoteDispatchDomainInterfaceAddresses src/remote/remote_driver.c * Define remoteDomainInterfaceAddresses src/remote/remote_protocol.x * New RPC procedure: REMOTE_PROC_DOMAIN_INTERFACE_ADDRESSES * Define structs remote_domain_ip_addr, remote_domain_interface, remote_domain_interfaces_addresse_args, remote_domain_interface_addresses_ret * Introduce upper bounds (to handle DoS attacks): REMOTE_DOMAIN_INTERFACE_MAX = 2048 REMOTE_DOMAIN_IP_ADDR_MAX = 2048 Restrictions on the maximum number of aliases per interface were removed after kernel v2.0, and theoretically, at present, there are no upper limits on number of interfaces per virtual machine and on the number of IP addresses per interface. src/remote_protocol-structs * New structs added Signed-off-by: NNehal J Wani <nehaljw.kkd1@gmail.com>
-
- 12 3月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Implement the remote plumbing.
-
- 06 3月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Implement the remote plumbing for virDomainGetIOThreadsInfo Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 19 2月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Not all files we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH. Both RNG schemas and cpu_map.xml are distributed in source tarball. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 1月, 2015 2 次提交
-
-
由 Daniel P. Berrange 提交于
For stateless, client side drivers, it is never correct to probe for secondary drivers. It is only ever appropriate to use the secondary driver that is associated with the hypervisor in question. As a result the ESX & HyperV drivers have both been forced to do hacks where they register no-op drivers for the ones they don't implement. For stateful, server side drivers, we always just want to use the same built-in shared driver. The exception is virtualbox which is really a stateless driver and so wants to use its own server side secondary drivers. To deal with this virtualbox has to be built as 3 separate loadable modules to allow registration to work in the right order. This can all be simplified by introducing a new struct recording the precise set of secondary drivers each hypervisor driver wants struct _virConnectDriver { virHypervisorDriverPtr hypervisorDriver; virInterfaceDriverPtr interfaceDriver; virNetworkDriverPtr networkDriver; virNodeDeviceDriverPtr nodeDeviceDriver; virNWFilterDriverPtr nwfilterDriver; virSecretDriverPtr secretDriver; virStorageDriverPtr storageDriver; }; Instead of registering the hypervisor driver, we now just register a virConnectDriver instead. This allows us to remove all probing of secondary drivers. Once we have chosen the primary driver, we immediately know the correct secondary drivers to use. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
A bunch of code is wrapped in #if WITH_LIBVIRTD in order to enable the virStateDriver to be disabled when libvirtd is not built. Disabling this code doesn't have any real functional benefit beyond removing 1 pointer from the virConnectPtr struct, while having a cost of many more conditionals. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 13 1月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virDomainDefineXML method is one of the few that still lacks an 'unsigned int flags' parameter. This will be needed for adding XML validation to this API. virDomainCreateXML fortunately already has flags.
-
- 03 12月, 2014 10 次提交
-
-
由 John Ferlan 提交于
Since virDomainSnapshotFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virInterfaceFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virNWFilterFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virSecretFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virStreamFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virStoragePoolFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virStorageVolFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virNodeDeviceFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virNetworkFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
由 John Ferlan 提交于
Since virDomainFree will call virObjectUnref anyway, let's just use that directly so as to avoid the possibility that we inadvertently clear out a pending error message when using the public API.
-
- 24 11月, 2014 2 次提交
-
-
由 Tomoki Sekiyama 提交于
Add daemon and driver code to (de-)serialize virDomainFSInfo. Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>
-
由 Peter Krempa 提交于
As qemu is now able to notify us about change of the channel state used for communication with the guest agent we now can more precisely track the state of the guest agent. To allow notifying management apps this patch implements a new event that will be triggered on changes of the guest agent state.
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 07 11月, 2014 2 次提交
-
-
由 Daniel P. Berrange 提交于
Since the secondary drivers are only active when the primary driver is also the remote driver, there is no need to use the different type specific privateData fields.
-
由 Daniel P. Berrange 提交于
The remote driver has had a long term hack to deal with the fact that the old Xen driver worked outside libvirtd, but the rest of the drivers worked inside. So you could have a local hypervisor driver but everything else go via the remote driver. The Xen driver long ago moved inside libvirtd, so this hack is no longer needed. Thus we should open use the remote driver for secondary drivers if the primary driver is already the remote driver.
-
- 05 11月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
The remote call actually doesn't free the arguments array so we leak memory in case a domain list is specified. As the remote domain list array consists only of stolen pointers from the actual domain objects it's sufficient just to free the array. Valgrind message: ==1081452== 64 bytes in 1 blocks are definitely lost in loss record 632 of 726 ==1081452== at 0x4C296D0: calloc (vg_replace_malloc.c:618) ==1081452== by 0x4EA5CB4: virAllocN (viralloc.c:191) ==1081452== by 0x505D21E: remoteConnectGetAllDomainStats (remote_driver.c:7785) ==1081452== by 0x50081AA: virDomainListGetStats (libvirt-domain.c:11080) ==1081452== by 0x155249: cmdDomstats (virsh-domain-monitor.c:2147) ==1081452== by 0x12FB73: vshCommandRun (virsh.c:1935) ==1081452== by 0x133FEB: main (virsh.c:3719)
-
- 29 10月, 2014 2 次提交
-
-
由 Eric Blake 提交于
C guarantees that static variables are zero-initialized. Some older compilers (and also gcc -fno-zero-initialized-in-bss) create larger binaries if you explicitly zero-initialize a static variable. * src/libxl/libxl_driver.c: Fix initialization. * src/lxc/lxc_controller.c: Likewise. * src/openvz/openvz_util.c (openvzKBPerPages): Likewise. * src/phyp/phyp_driver.c: Likewise. * src/remote/remote_driver.c: Likewise. * src/test/test_driver.c: Likewise. * src/uml/uml_driver.c: Likewise. * src/vbox/vbox_XPCOMCGlue.c: Likewise. * src/vbox/vbox_tmpl.c: Likewise. * src/xen/xen_driver.c: Likewise. * src/xen/xen_hypervisor.c: Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Jincheng Miao 提交于
Currently remote driver only initializes partial fields of remote_connect_get_all_domain_stats_args. But xdr_array() will check the uninitialised field 'doms_val'. For safty reason, memset all fields of args is better. Fix the following error from valgrind, like: ==30515== 1 errors in context 1 of 3: ==30515== Conditional jump or move depends on uninitialised value(s) ==30515== at 0x85E9402: xdr_array (xdr_array.c:88) ==30515== by 0x4FD8FC9: xdr_remote_connect_get_all_domain_stats_args (remote_protocol.c:6473) ==30515== by 0x4FE72F2: virNetMessageEncodePayload (virnetmessage.c:350) ==30515== by 0x4FDD21C: virNetClientProgramCall (virnetclientprogram.c:326) ==30515== by 0x4FB4D01: callFull.isra.2 (remote_driver.c:6667) ==30515== by 0x4FCBD45: call (remote_driver.c:6689) ==30515== by 0x4FCBD45: remoteConnectGetAllDomainStats (remote_driver.c:7793) ==30515== by 0x4FA0E75: virConnectGetAllDomainStats (libvirt.c:21678) ==30515== by 0x147FD1: cmdDomstats (virsh-domain-monitor.c:2148) ==30515== by 0x13006B: vshCommandRun (virsh.c:1915) ==30515== by 0x12A9E1: main (virsh.c:3699) Signed-off-by: NJincheng Miao <jmiao@redhat.com>
-
- 23 10月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
To prepare for introducing a single global driver, rename the virDriver struct to virHypervisorDriver and the registration API to virRegisterHypervisorDriver()
-
- 26 9月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
There's no one to free() it anyway. Instead, we can just pass the provided array pointer directly. ==20039== 48 bytes in 4 blocks are definitely lost in loss record 658 of 787 ==20039== at 0x4C2A700: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20039== by 0x4EA661F: virAllocN (viralloc.c:191) ==20039== by 0x50386EF: remoteNodeGetFreePages (remote_driver.c:7625) ==20039== by 0x5003504: virNodeGetFreePages (libvirt.c:21379) ==20039== by 0x154625: cmdFreepages (virsh-host.c:374) ==20039== by 0x12F718: vshCommandRun (virsh.c:1935) ==20039== by 0x1339FB: main (virsh.c:3747) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 25 9月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
A long time ago in a galaxy far, far away it has been decided that libvirt will manage not only domains but host as well. And with my latest work on qemu driver supporting huge pages, we miss the cherry on top: an API to allocate huge pages on the run. Currently users are forced to log into the host and adjust the huge pages pool themselves. However, with this API the problem is gone - they can both size up and size down the pool. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 9月, 2014 1 次提交
-
-
由 Pavel Hrdina 提交于
This new event will use typedParameters to expose what has been actually updated and the reason is that we can in the future extend any tunable values or add new tunable values. With typedParameters we don't have to worry about creating some other events, we will just use this universal event to inform user about updates. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 18 9月, 2014 1 次提交
-
-
由 Wang Yufei 提交于
Clean up all _virDomainMemoryStat. Signed-off-by: NJames <james.wangyufei@huawei.com> Signed-off-by: NWang Rui <moon.wangrui@huawei.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 15 9月, 2014 1 次提交
-
-
由 John Ferlan 提交于
Since 98b9acf5 This was a false positive where Coverity was complaining that the remoteDeserializeTypedParameters() could allocate 'params', but none of the callers could return the allocated memory back to their caller since on input the param was passed by value. Additionally, the flow of the code was that if params was NULL on entry, then each function would return 'nparams' as the number of params entries the caller would need to allocate in order to call the function again with 'nparams' and 'params' being set. By the time the deserialize routine was called params would have something. For other callers where the 'params' was passed by reference as NULL since it's expected that the deserialize allocates the memory and then have that passed back to the original caller to dispose there was no Coverity issue. As it turns out Coverity didn't quite seem to understand the relationship between 'nparams' and 'params'; however, if the !userAllocated path of the deserialize code compared against limit in any manner, then the Coverity error went away which was quite strange, but useful. As it turns out one code path remoteDomainGetJobStats had a comparison against 'limit' while another remoteConnectGetAllDomainStats did not assuming that limit would be checked. So I refactored the code a bit to cause the limit check to occur in deserialize for both conditions and then only made the check of current returned size against the incoming *nparams fail the non allocation case. This means the job code doesn't need to check the limit any more, while the stats code now does check the limit. Additionally, to help perhaps decipher which of the various callers to the deserialize code caused the failure - I used a #define to pass the __FUNCNAME__ of the caller along so that error messages could have something like: error: remoteConnectGetAllDomainStats: too many parameters '2' for nparams '0' error: Reconnected to the hypervisor (it's a contrived error just to show the funcname in the error)
-
- 07 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
Fairly straightforward - I got lucky that the generated functions worked out of the box :) * src/remote/remote_protocol.x (remote_domain_block_copy_args): New struct. (REMOTE_PROC_DOMAIN_BLOCK_COPY): New RPC. * src/remote/remote_driver.c (remote_driver): Wire it up. * src/remote_protocol-structs: Regenerate. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 05 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This patch focuses on all remaining problems, where there weren't enough issues to warrant splitting it further. * src/remote/remote_driver.c (doRemoteOpen): Correct use of {}. * src/security/virt-aa-helper.c (vah_add_path, valid_path, main): Likewise. * src/rpc/virnetsocket.c (virNetSocketNewConnectLibSSH2): Likewise. * src/esx/esx_vi_types.c (esxVI_Type_FromString): Likewise. * src/uml/uml_driver.c (umlDomainDetachDevice): Likewise. * src/util/viralloc.c (virShrinkN): Likewise. * src/util/virbuffer.c (virBufferURIEncodeString): Likewise. * src/util/virdbus.c (virDBusCall): Likewise. * src/util/virnetdev.c (virNetDevValidateConfig): Likewise. * src/util/virnetdevvportprofile.c (virNetDevVPortProfileGetNthParent): Likewise. * src/util/virpci.c (virPCIDeviceIterDevices) (virPCIDeviceWaitForCleanup) (virPCIDeviceIsBehindSwitchLackingACS): Likewise. * src/util/virsocketaddr.c (virSocketAddrGetNumNetmaskBits): Likewise. * src/util/viruri.c (virURIParseParams): Likewise. * daemon/stream.c (daemonStreamHandleAbort): Likewise. * tests/testutils.c (virtTestResult): Likewise. * tests/cputest.c (cpuTestBaseline): Likewise. * tools/virsh-domain.c (cmdDomPMSuspend): Likewise. * tools/virsh-host.c (cmdNodeSuspend): Likewise. * src/esx/esx_vi_generator.py (Type.generate_typefromstring): Tweak generated code. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 02 9月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
The 'elem' variable along with the domain object would be leaked when taking the error path. Found by coverity.
-
- 28 8月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
Implement the remote driver support for shuffling the domain stats around.
-
- 27 8月, 2014 2 次提交
-
-
由 Eric Blake 提交于
Let's fix this before we bake in a painful API. Since we know that we have exactly one non-negative fd on success, we might as well return the fd directly instead of forcing the user to pass in a pointer. Furthermore, I found some memory and fd leaks while reviewing the code - the idea is that on success, libvirtd will have handed two fds in two different directions: one to qemu, and one to the RPC client. * include/libvirt/libvirt.h.in (virDomainOpenGraphicsFD): Drop unneeded parameter. * src/driver.h (virDrvDomainOpenGraphicsFD): Likewise. * src/libvirt.c (virDomainOpenGraphicsFD): Adjust interface to return fd directly. * daemon/remote.c (remoteDispatchDomainOpenGraphicsFd): Adjust semantics. * src/qemu/qemu_driver.c (qemuDomainOpenGraphicsFD): Likewise, and plug fd leak. * src/remote/remote_driver.c (remoteDomainOpenGraphicsFD): Likewise, and plug memory and fd leak. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Ján Tomko 提交于
-