Well, the remaining drivers that already had the get/set
scheduler parameter functionality to begin with.
For now, this blindly treats VIR_DOMAIN_SCHEDINFO_CURRENT as
the only supported operation for these 5 domains; it will
take domain-specific patches if more specific behavior is
preferred.
* src/esx/esx_driver.c (esxDomainGetSchedulerParameters)
(esxDomainSetSchedulerParameters): Move guts...
(esxDomainGetSchedulerParametersFlags)
(esxDomainSetSchedulerParametersFlags): ...to new functions.
* src/libxl/libxl_driver.c (libxlDomainGetSchedulerParameters)
(libxlDomainSetSchedulerParameters)
(libxlDomainGetSchedulerParametersFlags)
(libxlDomainSetSchedulerParametersFlags): Likewise.
* src/lxc/lxc_driver.c (lxcGetSchedulerParameters)
(lxcSetSchedulerParameters, lxcGetSchedulerParametersFlags)
(lxcSetSchedulerParametersFlags): Likewise.
* src/test/test_driver.c (testDomainGetSchedulerParams)
(testDomainSetSchedulerParams, testDomainGetSchedulerParamsFlags)
(testDomainSetSchedulerParamsFlags): Likewise.
* src/xen/xen_driver.c (xenUnifiedDomainGetSchedulerParameters)
(xenUnifiedDomainSetSchedulerParameters)
(xenUnifiedDomainGetSchedulerParametersFlags)
(xenUnifiedDomainSetSchedulerParametersFlags): Likewise.
Before commit 145d6cb05c (in August 2010) absolute file names
in VMX and domain XML configs were handled correctly. But this got
lost during the refactoring. The test cases didn't highlight this
problem because they have their own set of file name handling
functions. The actual ones require a real connection to an ESX
server. Also the test case functions always worked correctly.
Fix the regression and add a new in-the-wild VMX file that contains
such a problematic absolute path. Even though this test case won't
protect against new regressions.
Reported by lofic (IRC nick)
Otherwise an attempt to use virConnectOpen or virConnectOpenAuth without
auth pointer results in the driver declining the URI and libvirt falling
back to the remote driver for an esx:// URI.
Some drivers assumed it can be NULL (e.g. qemu and lxc) and check it
before assigning to it, other drivers assumed it must be non-NULL
(e.g. test and esx) and just assigned to it.
Unify this to nparams being optional and document it.
When the session has expired then multiple threads can race while
reestablishing it.
This race condition is not that critical as it requires a special usage
pattern to be triggered. It can only happen when an application doesn't
do API calls for quite some time (the session expires after 30 min
inactivity) and then multiple threads doing simultaneous API calls and
end up doing simultaneous calls to esxVI_EnsureSession.
Change all the driver struct initializers to use the
C99 style, leaving out unused fields. This will make
it possible to add new APIs without changing every
driver. eg change:
qemudDomainResume, /* domainResume */
qemudDomainShutdown, /* domainShutdown */
NULL, /* domainReboot */
qemudDomainDestroy, /* domainDestroy */
to
.domainResume = qemudDomainResume,
.domainShutdown = qemudDomainShutdown,
.domainDestroy = qemudDomainDestroy,
And get rid of any existing C99 style initializersr which
set NULL, eg change
.listPools = vboxStorageListPools,
.numOfDefinedPools = NULL,
.listDefinedPools = NULL,
.findPoolSources = NULL,
.poolLookupByName = vboxStoragePoolLookupByName,
to
.listPools = vboxStorageListPools,
.poolLookupByName = vboxStoragePoolLookupByName,
Fix some driver names:
s/virDrvCPUCompare/virDrvCompareCPU/
s/virDrvCPUBaseline/virDrvBaselineCPU/
s/virDrvQemuDomainMonitorCommand/virDrvDomainQemuMonitorCommand/
s/virDrvSecretNumOfSecrets/virDrvNumOfSecrets/
s/virDrvSecretListSecrets/virDrvListSecrets/
And some driver struct field names:
s/getFreeMemory/nodeGetFreeMemory/
Several vSphere API methods are called on global objects like the
FileManager, the PerformanceManager or the SearchIndex. The generator
input file allows to mark such methods and the generator generates
such method in a way that automatically handles marked parameter. This
is done by some special macros. Those were manually written and this
patch moves them to the generator.
These VIR_XXXX0 APIs make us confused, use the non-0-suffix APIs instead.
How do these coversions works? The magic is using the gcc extension of ##.
When __VA_ARGS__ is empty, "##" will swallow the "," in "fmt," to
avoid compile error.
example: origin after CPP
high_level_api("%d", a_int) low_level_api("%d", a_int)
high_level_api("a string") low_level_api("a string")
About 400 conversions.
8 special conversions:
VIR_XXXX0("") -> VIR_XXXX("msg") (avoid empty format) 2 conversions
VIR_XXXX0(string_literal_with_%) -> VIR_XXXX(%->%%) 0 conversions
VIR_XXXX0(non_string_literal) -> VIR_XXXX("%s", non_string_literal)
(for security) 6 conversions
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
This matches the public API and helps to get rid of some special
case code in the remote generator.
Rename driver API functions and XDR protocol structs.
No functional change included outside of the remote generator.
We already have virAsprintf, so picking a similar name helps for
seeing a similar purpose. Furthermore, the prefix V before printf
generally implies 'va_list', even though this variant was '...', and
the old name got in the way of adding a new va_list version.
global rename performed with:
$ git grep -l virBufferVSprintf \
| xargs -L1 sed -i 's/virBufferVSprintf/virBufferAsprintf/g'
then revert the changes in ChangeLog-old.
Add missing early exits and convert error logging to proper API level
error reporting.
Centralize cleanup code for the PerfQuerySpec object.
Reported by Eric Blake, detected by clang.
The ++ on preliminaryFileName was a left over from a previous version
of this function that explicitly returned the filename and did a strdup
on preliminaryFileName afterwards.
As the filename isn't returned explicitly anymore remove the preliminary
variable for it and reuse the tmp variable instead.
Reported by Eric Blake, detected by clang.
This was broken by the refactoring in ac1e6586ec. It resulted in a
segfault for 'virsh vol-dumpxml' and related volume functions.
Before the refactoring all users of the ESX_VI__TEMPLATE__DISPATCH
macro dispatched on the item type, as the item is the input to all those
functions.
Commit ac1e6586ec made the dynamically dispatched CastFromAnyType
functions use this macro too, but this functions dispatched on the
actual type of the AnyType object. The item is the output of the
CastFromAnyType functions.
This difference was missed in the refactoring, making CastFromAnyType
functions dereferencing the item pointer that is NULL at the time of
the dispatch.
This warnings come from partly generated code. Therefore, the best
solution is to mark them as potentially being unused using the
ATTRIBUTE_UNUSED macro. This is suggested by the gcc documentation.
Reported by Christophe Fergeau
New APIs are added allowing streaming of content to/from
storage volumes.
* include/libvirt/libvirt.h.in: Add virStorageVolUpload and
virStorageVolDownload APIs
* src/driver.h, src/libvirt.c, src/libvirt_public.syms: Stub
code for new APIs
* src/storage/storage_driver.c, src/esx/esx_storage_driver.c:
Add dummy entries in driver table for new APIs
It is possible to set a migration speed limit when starting
migration. This new API allows the speed limit to be changed
on the fly to adjust to changing conditions
* src/driver.h, src/libvirt.c, src/libvirt_public.syms,
include/libvirt/libvirt.h.in: Add virDomainMigrateSetMaxSpeed
* src/esx/esx_driver.c, src/lxc/lxc_driver.c,
src/opennebula/one_driver.c, src/openvz/openvz_driver.c,
src/phyp/phyp_driver.c, src/qemu/qemu_driver.c,
src/remote/remote_driver.c, src/test/test_driver.c,
src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
src/vmware/vmware_driver.c, src/xen/xen_driver.c,
src/libxl/libxl_driver.c: Stub new API
This patch introduces a new libvirt API (virDomainSetMemoryFlags) and
a flag (virDomainMemoryModFlags).
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Etienne Gosset reported that libvirt fails to connect to his ESX
server because it failed to parse its malformed host UUID, that
contains an additional space and lacks one hexdigit in the last
group:
xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxx
Don't treat this as a fatal error, just ignore it.
