Detected in valgrind run:
==9184== 1 bytes in 1 blocks are definitely lost in loss record 1 of 19
==9184== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==9184== by 0x3073715F78: xdr_array (xdr_array.c:97)
==9184== by 0x4CF97C9: xdr_remote_domain_get_security_label_ret (remote_protocol.c:1696)
==9184== by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
==9184== by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
==9184== by 0x4CE3887: call (remote_driver.c:3933)
==9184== by 0x4CF71C6: remoteDomainGetSecurityLabel (remote_driver.c:1580)
==9184== by 0x4CCA480: virDomainGetSecurityLabel (libvirt.c:7340)
==9184== by 0x41993A: cmdDominfo (virsh.c:2414)
==9184== by 0x411E92: vshCommandRun (virsh.c:12730)
==9184== by 0x4211ED: main (virsh.c:14076)
==9184==
==9184== 2 bytes in 1 blocks are definitely lost in loss record 2 of 19
==9184== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==9184== by 0x3073715F78: xdr_array (xdr_array.c:97)
==9184== by 0x4CF974F: xdr_remote_node_get_security_model_ret (remote_protocol.c:1713)
==9184== by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
==9184== by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
==9184== by 0x4CE3887: call (remote_driver.c:3933)
==9184== by 0x4CF6F96: remoteNodeGetSecurityModel (remote_driver.c:1648)
==9184== by 0x4CBF799: virNodeGetSecurityModel (libvirt.c:7382)
==9184== by 0x4197D7: cmdDominfo (virsh.c:2394)
==9184== by 0x411E92: vshCommandRun (virsh.c:12730)
==9184== by 0x4211ED: main (virsh.c:14076)
==9184==
==9184== 8 bytes in 1 blocks are definitely lost in loss record 3 of 19
==9184== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==9184== by 0x3073715F78: xdr_array (xdr_array.c:97)
==9184== by 0x4CF9729: xdr_remote_node_get_security_model_ret (remote_protocol.c:1710)
==9184== by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
==9184== by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
==9184== by 0x4CE3887: call (remote_driver.c:3933)
==9184== by 0x4CF6F96: remoteNodeGetSecurityModel (remote_driver.c:1648)
==9184== by 0x4CBF799: virNodeGetSecurityModel (libvirt.c:7382)
==9184== by 0x4197D7: cmdDominfo (virsh.c:2394)
==9184== by 0x411E92: vshCommandRun (virsh.c:12730)
==9184== by 0x4211ED: main (virsh.c:14076)
==9184==
==9184== LEAK SUMMARY:
==9184== definitely lost: 11 bytes in 3 blocks
* src/remote/remote_driver.c: Avoid leak on remoteDomainGetSecurityLabel
and remoteNodeGetSecurityModel.
When closing a remote connection we issue a (fairly pointless)
'CLOSE' RPC call to the daemon. If this fails we skip all the
cleanup of private data, but the virConnectPtr object still
gets released as normal. This causes a memory leak. Since the
CLOSE RPC call is pretty pointless, just carry on freeing the
remote driver if it fails.
* src/remote/remote_driver.c: Ignore failure to issue CLOSE
RPC call
The virDomainMigratePrepareTunnel3 impl in the remote driver
was using the procedure number for the virDomainMigratePrepareTunnel
method. This doesn't work out so well, because it makes the server
ignore & drop all stream packets
* src/remote/remote_driver.c: Fix procedure for PrepareTunnel3
The client stream object can be used independently of the
virNetClientPtr object, so must have full locking of its
own and not rely on any caller.
* src/remote/remote_driver.c: Remove locking around stream
callback
* src/rpc/virnetclientstream.c: Add locking to all APIs
and callbacks
Detected by gcc -O2:
remote/remote_driver.c: In function 'doRemoteOpen':
remote/remote_driver.c:2753:26: error: 'sasl' may be used uninitialized in this function [-Werror=uninitialized]
* src/remote/remote_driver.c (remoteAuthSASL): Initialize sasl.
This guts the current remote driver, removing all its networking
handling code. Instead it calls out to the new virClientPtr and
virClientProgramPtr APIs for all RPC & networking work.
* src/Makefile.am: Link remote driver with generic RPC code
* src/remote/remote_driver.c: Gut code, replacing with RPC
API calls
* src/rpc/gendispatch.pl: Update for changes in the way
streams are handled
We already have a public virDomainPinVcpu, which implies that
Pin and Vcpu are treated as separate words. Unreleased commit
e261987c introduced virDomainGetVcpupinInfo as the first public
API that used Vcpupin, although we had prior internal uses of
that spelling. For consistency, change the spelling to be two
words everywhere, regardless of whether pin comes first or last.
* daemon/remote.c: Treat vcpu and pin as separate words.
* include/libvirt/libvirt.h.in: Likewise.
* src/conf/domain_conf.c: Likewise.
* src/conf/domain_conf.h: Likewise.
* src/driver.h: Likewise.
* src/libvirt.c: Likewise.
* src/libvirt_private.syms: Likewise.
* src/libvirt_public.syms: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.
* src/remote/remote_protocol.x: Likewise.
* src/remote_protocol-structs: Likewise.
Suggested by Matthias Bolte.
Integer overflow and remote code are never a nice mix.
This has existed since commit 56cd414.
* src/libvirt.c (virDomainGetVcpus): Reject overflow up front.
* src/remote/remote_driver.c (remoteDomainGetVcpus): Avoid overflow
on sending rpc.
* daemon/remote.c (remoteDispatchDomainGetVcpus): Avoid overflow on
receiving rpc.
Since we virEventRegisterDefaultImpl is now a public API, callers need
a way to invoke the default registered Handle and Timeout functions. We
already have general functions for these internally, so promote
them to the public API.
v2:
Actually add APIs to libvirt.h
When an operation started by virDomainBlockPullAll completes (either with
success or with failure), raise an event to indicate the final status. This
allows an API user to avoid polling on virDomainBlockPullInfo if they would
prefer to use the event mechanism.
* daemon/remote.c: Dispatch events to client
* include/libvirt/libvirt.h.in: Define event ID and callback signature
* src/conf/domain_event.c, src/conf/domain_event.h,
src/libvirt_private.syms: Extend API to handle the new event
* src/qemu/qemu_driver.c: Connect to the QEMU monitor event
for block_stream completion and emit a libvirt block pull event
* src/remote/remote_driver.c: Receive and dispatch events to application
* src/remote/remote_protocol.x: Wire protocol definition for the event
* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
src/qemu/qemu_monitor_json.c: Watch for BLOCK_STREAM_COMPLETED event
from QEMU monitor
Signed-off-by: Adam Litke <agl@us.ibm.com>
The generator can handle DomainBlockPullAll and DomainBlockPullAbort.
DomainBlockPull and DomainBlockPullInfo must be written by hand.
* src/remote/remote_protocol.x: provide defines for the new entry points
* src/remote/remote_driver.c daemon/remote.c: implement the client and
server side
* src/remote_protocol-structs: structure definitions for protocol verification
Signed-off-by: Adam Litke <agl@us.ibm.com>
Coverity couldn't see that priv is NULL on failure. But on failure,
we might as well guarantee that callers don't try to free uninitialized
memory.
* src/remote/remote_driver.c (remoteGenericOpen): Even on failure,
pass priv back to caller.
Remove some special case code that took care of mapping hyper to the
correct C types.
As the list of procedures that is allowed to map hyper to long is fixed
put it in the generator instead annotations in the .x files. This
results in simpler .x file parsing code.
Use macros for hyper to long assignments that perform overflow checks
when long is smaller than hyper. Map hyper to long long by default.
Suggested by Eric Blake.
The gnutls_certificate_type_set_priority method is deprecated.
Since we already set the default gnutls priority, and do not
support OpenGPG credentials in any case, it was not serving
any useful purpose and can be removed
* src/remote/remote_driver.c: Remove src/remote/remote_driver.c
call
This introduces a new domain
VIR_DOMAIN_EVENT_ID_CONTROL_ERROR
Which uses the existing generic callback
typedef void (*virConnectDomainEventGenericCallback)(virConnectPtr conn,
virDomainPtr dom,
void *opaque);
This event is intended to be emitted when there is a failure in
some part of the domain virtualization system. Whether the domain
continues to run/exist after the failure is an implementation
detail specific to the hypervisor.
The idea is that with some types of failure, hypervisors may
prefer to leave the domain running in a "degraded" mode of
operation. For example, if something goes wrong with the QEMU
monitor, it is possible to leave the guest OS running quite
happily. The mgmt app will simply loose the ability todo various
tasks. The mgmt app can then choose how/when to deal with the
failure that occured.
* daemon/remote.c: Dispatch of new event
* examples/domain-events/events-c/event-test.c: Demo catch
of event
* include/libvirt/libvirt.h.in: Define event ID and callback
* src/conf/domain_event.c, src/conf/domain_event.h: Internal
event handling
* src/remote/remote_driver.c: Receipt of new event from daemon
* src/remote/remote_protocol.x: Wire protocol for new event
* src/remote_protocol-structs: add new event for checks
The current virDomainMigrateFinish3 method signature attempts to
distinguish two types of errors, by allowing return with ret== 0,
but ddomain == NULL, to indicate a failure to start the guest.
This is flawed, because when ret == 0, there is no way for the
virErrorPtr details to be sent back to the client.
Change the signature of virDomainMigrateFinish3 so it simply
returns a virDomainPtr, in the same way as virDomainMigrateFinish2
The disk locking code will protect against the only possible
failure mode this doesn't account for (loosing conenctivity to
libvirtd after Finish3 starts the CPUs, but before the client
sees the reply for Finish3).
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Change
virDomainMigrateFinish3 to return a virDomainPtr instead of int
* src/remote/remote_driver.c, src/remote/remote_protocol.x,
daemon/remote.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c:
Update for API change
The virDomainMigratePerform3 currently has a single URI parameter
whose meaning varies. It is either
- A QEMU migration URI (normal migration)
- A libvirtd connection URI (peer2peer migration)
Unfortunately when using peer2peer migration, without also
using tunnelled migration, it is possible that both URIs are
required.
This adds a second URI parameter to the virDomainMigratePerform3
method, to cope with this scenario. Each parameter how has a fixed
meaning.
NB, there is no way to actually take advantage of this yet,
since virDomainMigrate/virDomainMigrateToURI do not have any
way to provide the 2 separate URIs
* daemon/remote.c, src/remote/remote_driver.c,
src/remote/remote_protocol.x, src/remote_protocol-structs: Add
the second URI parameter to perform3 message
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Add
the second URI parameter to Perform3 method
* src/libvirt_internal.h, src/qemu/qemu_migration.c,
src/qemu/qemu_migration.h: Update to handle URIs correctly
This extends the v3 migration protocol such that the
virDomainMigrateBegin3 and virDomainMigratePerform3
methods accept an application supplied XML config for
the target VM.
If the 'xmlin' parameter is NULL, then Begin3 uses the
current guest XML as normal. A driver implementing the
Begin3 method should either reject all non-NULL 'xmlin'
parameters, or strictly validate that the app supplied
XML does not change guest ABI.
The Perform3 method also needed the xmlin parameter to
cope with the Peer2Peer migration sequence.
NB it is not yet possible to use this capability since
neither of the public virDomainMigrate/virDomainMigrateToURI
methods have a way to pass in XML.
* daemon/remote.c, src/remote/remote_driver.c,
src/remote/remote_protocol.x, src/remote_protocol-structs:
Add 'remote_string xmlin' parameter to begin3/perform3
RPC messages
* src/libvirt.c, src/driver.h, src/libvirt_internal.h: Add
'const char *xmlin' parameter to Begin3/Perform3 methods
* src/qemu/qemu_driver.c, src/qemu/qemu_migration.c,
src/qemu/qemu_migration.h: Pass xmlin parameter around
migration methods
When using TLS authentication and operating as the non-root user,
initially attempt to use that specific user's TLS certificates before
attempting to use the system wide TLS certificates.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
When failing to marshall an XDR message, include the
full program/version/status/proc/type info, to allow
easier debugging & diagnosis of the problem.
* src/remote/remote_driver.c: Improve error when marshalling
fails
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/
