summaryrefslogtreecommitdiff
path: root/src/libvirt-host.c
Commit message (Collapse)AuthorAgeFilesLines
* src: Update format strings in translated messagesJiri Denemark2023-04-011-4/+2
| | | | | Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
* Drop checks for virURIFormat() retvalMichal Privoznik2023-02-081-9/+1
| | | | | | | | | | The virURIFormat() function either returns a string, or aborts (on OOM). There's no way this function can return NULL (as of v7.2.0-rc1~277). Therefore, it doesn't make sense to check its retval against NULL. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
* Document specifics of virConnectBaselineHypervisorCPUJiri Denemark2022-10-101-0/+9
| | | | | | | | | The API can be used to get usability blockers for an unusable CPU model, which is not obvious. Let's explicitly document this behavior as it is now mentioned in the documentation of domain capabilities XML. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
* docstring: remove 'v' from since metadataVictor Toso2022-05-041-34/+34
| | | | | | | Since: v1.2.3 -> Since: 1.2.3 Signed-off-by: Victor Toso <victortoso@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
* docstring: function: libvirt: Add 'Since version' metadataVictor Toso2022-04-261-0/+68
| | | | | | | | | | Either create or append to existing docstring, the version (git tag) that a given function was introduced in the format: Since: v1.2.3 Signed-off-by: Victor Toso <victortoso@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
* src: adopt to VIR_DRV_SUPPORTS_FEATURE return -1Nikolay Shirokovskiy2021-01-061-4/+14
| | | | | | | | Otherwise in some places we can mistakenly report 'unsupported' error instead of root cause. So let's handle root cause explicitly from the macro. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
* Reduce scope of some variablesJán Tomko2020-09-241-3/+1
| | | | | Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
* src: don't include ref count in debug messages / probesDaniel P. Berrangé2020-06-031-1/+1
| | | | | | | | The ref count will be private to the GObject base class and we must not peek at it, even for debugging messages. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* src: warn against virNodeGetInfo() API call due to inaccurate infoDaniel P. Berrangé2019-12-181-0/+16
| | | | | Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirt-<module>: Check caller-provided buffers to be NULL with size > 0Erik Skultety2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Pre-Glib era which used malloc allowed the size of the client-side buffers to be declared as 0, because malloc documents that it can either return 0 or a unique pointer on 0 size allocations. With glib this doesn't work anymore, because glib documents that for such allocation requests NULL is always returned which results in an error in our public API checks server-side. This patch complements the fix in the RPC layer by explicitly erroring out on the following combination of args used by our legacy APIs (their moder equivalents don't suffer from this): function(caller-allocated-array, size, ...) { if (!caller-allocated-array && size > 0) return error; } treating everything else as a valid input and potentially let that fail on the server-side rather than client-side. https://bugzilla.redhat.com/show_bug.cgi?id=1772842 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
* Use G_N_ELEMENTS instead of ARRAY_CARDINALITYJán Tomko2019-10-151-1/+1
| | | | | | | Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
* api: introduce virConnectSetIdentity for passing uid, gid, selinux infoDaniel P. Berrangé2019-09-161-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | When using the fine grained access control mechanism for APIs, when a client connects to libvirtd, the latter will fetch the uid, gid, selinux info of the remote client on the UNIX domain socket. This is then used as the identity when checking ACLs. With the new split daemons things are a bit more complicated. The user can connect to virtproxyd, which in turn connects to virtqemud. When virtqemud requests the identity over the UNIX domain socket, it will get the identity that virtproxyd is running as, not the identity of the real end user/application. virproxyd knows what the real identity is, and needs to be able to forward this information to virtqemud. The virConnectSetIdentity API provides a mechanism for doing this. Obviously virtqemud should not accept such identity overrides from any client, it must only honour it from a trusted client, aka one running as the same uid/gid as itself. The typed parameters exposed in the API are the same as those currently supported by the internal virIdentity class, with a few small name changes. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirt: remove link to outdated mailing list postDaniel P. Berrangé2019-07-081-3/+0
| | | | | | | | | | | | | | | | The virConnectGetType() method has an unfortunate signature, returning a static string that must not be freed by the caller. The remote driver, however, gets this string dynamically over an RPC call, which raised a design discussion on the mailing list. Eventually the problem was resolved by having the remote driver cache the returned string internally and free it when the connection was closed. The link to the mailing list is thus talking about a problem that does not actually exist in the final implementation, and at best serves to confuse the reader into thinking there might be a memory leak. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* api: disallow virConnect*HypervisorCPU on read-only connectionsJán Tomko2019-06-201-0/+2
| | | | | | | | | These APIs can be used to execute arbitrary emulators. Forbid them on read-only connections. Fixes: CVE-2019-10168 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
* libvirt: Introduce virNodeGetSEVInfo public APIBrijesh Singh2018-06-121-0/+49
| | | | | | | | The API can be used by application to retrieve the Platform Diffie-Hellman Key and Platform Certificate chain. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
* Introduce virConnectBaselineHypervisorCPU public APIJiri Denemark2018-05-281-0/+81
| | | | | | | | | | | The new API computes the most feature-rich CPU which is compatible with all given CPUs and can be provided by the specified hypervisor. It is a more useful version of virConnectBaselineCPU, which doesn't consider any hypervisor capabilities when computing the best CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com>
* Introduce virConnectCompareHypervisorCPU public APIJiri Denemark2018-05-281-1/+71
| | | | | | | | | | | | | | | This new API compares the given CPU description with the CPU the specified hypervisor is able to provide on the host. It is a more useful version of virConnectCompareCPU, which compares the CPU definition with the host CPU without considering any specific hypervisor and its abilities. https://bugzilla.redhat.com/show_bug.cgi?id=1559832 https://bugzilla.redhat.com/show_bug.cgi?id=1559835 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com>
* Improve documentation of virConnectGetCPUModelNamesJiri Denemark2018-05-281-1/+7
| | | | | | | Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
* src: Unify virObject member nameMichal Privoznik2018-04-181-1/+1
| | | | | | | | | | | | | | Whenever we declare a new object the first member of the struct has to be virObject (or any other member of that family). Now, up until now we did not care about the name of the struct member. But lets unify it so that we can do some checks at compile time later. The unified name is 'parent'. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
* Print hex values with '0x' prefix and octal with '0' in debug messagesDaniel P. Berrange2017-09-251-12/+12
| | | | | | | | | | Seeing a log message saying 'flags=93' is ambiguous & confusing unless you happen to know that libvirt always prints flags as hex. Change our debug messages so that they always add a '0x' prefix when printing flags, and '0' prefix when printing mode. A few other misc places gain a '0x' prefix in error messages too. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* cpu: Special case models == NULL in cpuGetModelsJiri Denemark2016-09-221-1/+2
| | | | | | | | Some CPU drivers (such as arm) do not provide list of CPUs libvirt supports and just pass any CPU model from domain XML directly to QEMU. Such driver need to return models == NULL and success from cpuGetModels. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
* Document to not rely on virConnectGetMaxVcpus APIShivaprasad G Bhat2016-06-241-1/+4
| | | | | | | | The API virConnectGetMaxVcpus doesn't really reflect the actual usable number of cpus as the maximum limits can be different for kvm and/or qemu. So update the documentation to use virConnectGetDomainCapabilities() instead. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
* close callback: move it to driverNikolay Shirokovskiy2016-03-011-13/+4
| | | | Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
* close callback API: remove unnecessary locksNikolay Shirokovskiy2016-03-011-10/+0
| | | | | closeCallback pointer is immutable (set on connection object creation) and self-locking.
* factor out virConnectCloseCallbackDataPtr methodsNikolay Shirokovskiy2016-03-011-24/+5
| | | | | | | | | | | Make register and unregister functions return void because we can check the state of callback object beforehand via virConnectCloseCallbackDataGetCallback. This can be done without race conditions if we use higher level locks for registering and unregistering. The fact they return void simplifies task of consistent registering/unregistering. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
* debug: assure NULLSTR() around all %s args in debug at top of public APIsLaine Stump2015-05-281-3/+3
| | | | | | | | | | | | There are also a couple that were very uninformatively just logging the value of the pointer rather than the string itself: * the "name" arg to virNodeDeviceLookupByName() * wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN() All char*'s that make sense should now have their contents logged rather than the pointer, and all %s args should now be inside NULLSTR().
* Change virConnectPtr into virObjectLocklableMartin Kletzander2015-04-151-9/+9
| | | | | | It already had a virMutex inside, so this is just a cleanup. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
* Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flagJán Tomko2015-03-021-0/+3
| | | | | | | This flag for virConnectBaselineCPU will allow filtering out CPU features that block migration from the result. https://bugzilla.redhat.com/show_bug.cgi?id=1171484
* Move virConnect/virNode related APIs out of libvirt.cDaniel P. Berrange2014-10-241-0/+1515
Introduce a src/libvirt-host.c file to hold all the methods related to the virConnect type.
View Lorry Controller Status