To allow the new virDomainUpdateDeviceFlags() API to be universally
used with all drivers, this patch adds an impl to all the current
drivers which support CDROM or Floppy disk media change via the
current virDomainAttachDeviceFlags API
* src/qemu/qemu_driver.c, src/vbox/vbox_tmpl.c,
src/xen/proxy_internal.c, src/xen/xen_driver.c,
src/xen/xend_internal.c: Implement media change via the
virDomainUpdateDeviceFlags API
* src/xen/xen_driver.h, src/xen/xen_hypervisor.c,
src/xen/xen_inotify.c, src/xen/xm_internal.c,
src/xen/xs_internal.c: Stubs for Xen driver entry points
The current virDomainAttachDevice API can be (ab)used to change
the media of an existing CDROM/Floppy device. Going forward there
will be more devices that can be configured on the fly and overloading
virDomainAttachDevice for this is not too pleasant. This patch adds
a new virDomainUpdateDeviceFlags() explicitly just for modifying
existing devices.
* include/libvirt/libvirt.h.in: Add virDomainUpdateDeviceFlags
* src/driver.h: Internal API for virDomainUpdateDeviceFlags
* src/libvirt.c, src/libvirt_public.syms: Glue public API to
driver API
* 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/xen/xen_driver.c, src/xenapi/xenapi_driver.c: Add
stubs for new driver entry point
The libvirtd daemon impl will need to switch over to using the
new event APIs. To make this simpler, ensure all drivers currently
providing events support both the new APIs and old APIs.
* src/lxc/lxc_driver.c, src/qemu/qemu_driver.c, src/test/test_driver.c,
src/vbox/vbox_tmpl.c, src/xen/xen_driver.c: Implement the new
virConnectDomainEvent(Dereg|Reg)isterAny driver entry points
The internal domain events APIs are designed to handle the lifecycle
events. This needs to be refactored to allow arbitrary new event
types to be handled.
* The signature of virDomainEventDispatchFunc changes to use
virConnectDomainEventGenericCallback instead of the lifecycle
event specific virConnectDomainEventCallback
* Every registered callback gains a unique ID to allow its
removal based on ID, instead of function pointer
* Every registered callback gains an 'eventID' to allow callbacks
for different types of events to be distinguished
* virDomainEventDispatch is adapted to filter out callbacks
whose eventID does not match the eventID of the event being
dispatched
* virDomainEventDispatch is adapted to filter based on the
domain name and uuid, if this filter is set for a callback.
* virDomainEvent type/detail fields are moved into a union to
allow different data fields for other types of events to be
added later
* src/conf/domain_event.h, src/conf/domain_event.c: Refactor
to allow handling of different types of events
* src/lxc/lxc_driver.c, src/qemu/qemu_driver.c,
src/remote/remote_driver.c, src/test/test_driver.c,
src/xen/xen_driver.c: Change dispatch function signature
to use virConnectDomainEventGenericCallback
The current API for domain events has a number of problems
- Only allows for domain lifecycle change events
- Does not allow the same callback to be registered multiple times
- Does not allow filtering of events to a specific domain
This introduces a new more general purpose domain events API
typedef enum {
VIR_DOMAIN_EVENT_ID_LIFECYCLE = 0, /* virConnectDomainEventCallback */
...more events later..
}
int virConnectDomainEventRegisterAny(virConnectPtr conn,
virDomainPtr dom, /* Optional, to filter */
int eventID,
virConnectDomainEventGenericCallback cb,
void *opaque,
virFreeCallback freecb);
int virConnectDomainEventDeregisterAny(virConnectPtr conn,
int callbackID);
Since different event types can received different data in the callback,
the API is defined with a generic callback. Specific events will each
have a custom signature for their callback. Thus when registering an
event it is neccessary to cast the callback to the generic signature
eg
int myDomainEventCallback(virConnectPtr conn,
virDomainPtr dom,
int event,
int detail,
void *opaque)
{
...
}
virConnectDomainEventRegisterAny(conn, NULL,
VIR_DOMAIN_EVENT_ID_LIFECYCLE,
VIR_DOMAIN_EVENT_CALLBACK(myDomainEventCallback)
NULL, NULL);
The VIR_DOMAIN_EVENT_CALLBACK() macro simply does a "bad" cast
to the generic signature
* include/libvirt/libvirt.h.in: Define new APIs for registering
domain events
* src/driver.h: Internal driver entry points for new events APIs
* src/libvirt.c: Wire up public API to driver API for events APIs
* src/libvirt_public.syms: Export new APIs
* 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/xen/xen_driver.c,
src/xenapi/xenapi_driver.c: Stub out new API entries
A few more non-literal format strings in error log messages have crept
in. Fix them in the standard way - turn the format string into "%s"
with the original string as the arg.
* src/xen/proxy_internal.c (xenProxyDomainDumpXML): An invalid packet
could include a too-large "ans.len" value, which would make us allocate
too much memory and then copy data from beyond the end of "ans",
possibly evoking a segfault. Ensure that the value we use is no
larger than the remaining portion of "ans".
Also, change unnecessary memmove to memcpy (src and dest obviously
do not overlap, so no need to use memmove).
(xenProxyDomainGetOSType): Likewise.
(xenProxyGetCapabilities): Likewise.
This provides the internal glue for the driver API
* src/driver.h: Internal API contract
* src/libvirt.c, src/libvirt_public.syms: Connect public API
to driver API
* 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/xen/xen_driver.c: Stub out entry points
The internal glue layer for the new pubic API
* src/driver.h: Define internal driver API contract
* src/libvirt.c, src/libvirt_public.syms: Wire up public
API to internal driver API
* 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/xen/xen_driver.c: Stub new entry point
This extends the XML to allow for
<clock offset='timezone' timezone='Europe/Paris'/>
This is useful if the admin has not configured any timezone on the
host OS, but still wants to synchronize a guest to a specific one.
* src/conf/domain_conf.h, src/conf/domain_conf.c: Support extra
'timezone' attribute on clock configuration
* docs/schemas/domain.rng: Add 'timezone' attribute
* src/xen/xend_internal.c, src/xen/xm_internal.c: Reject configs
with a configurable timezone
The XML will soon be extended to allow more than just a simple
localtime/utc boolean flag. This change replaces the plain
'int localtime' with a separate struct to prepare for future
extension
* src/conf/domain_conf.c, src/conf/domain_conf.h: Add a new
virDomainClockDef structure
* src/libvirt_private.syms: Export virDomainClockOffsetTypeToString
and virDomainClockOffsetTypeFromString
* src/qemu/qemu_conf.c, src/vbox/vbox_tmpl.c, src/xen/xend_internal.c,
src/xen/xm_internal.c: Updated to use new structure for localtime
* src/xen/xend_internal.c (xenDaemonDomainSetAutostart): Avoid a NULL
dereference upon non-SEXPR_VALUE'd on_xend_start. This bug was
introduced by commit 37ce5600c0.
* src/xen/xend_internal.c (xenDaemonDomainSetAutostart): Rewrite to
avoid dereferencing the result of sexpr_lookup. While in this
particular case, it was guaranteed never to be NULL, due to the
preceding "if sexpr_node(...)" guard, it's cleaner to skip the
sexpr_node call altogether, and also saves a lookup.
The virConnectPtr is no longer required for error reporting since
that is recorded in a thread local. Remove use of virConnectPtr
from all APIs in node_device_conf.{h,c} and update all callers to
match
* src/xen/xs_internal.c (xenStoreDomainIntroduced): Don't use -1
as an allocation size upon xenStoreNumOfDomains failure.
(xenStoreDomainReleased): Likewise.
* src/xen/xen_hypervisor.c: Remove all "domain == NULL" tests.
* src/xen/xen_hypervisor.h: Instead, use ATTRIBUTE_NONNULL to
mark each "domain" parameter as "known always to be non-NULL".
xen-unstable c/s 20762 bumped XEN_SYSCTL_INTERFACE_VERSION to 7. The
interface change does not affect libvirt, other than xenHypervisorInit()
failing since version 7 is not tried.
The attached patch accommodates the upcoming Xen 4.0 release by checking
for XEN_SYSCTL_INTERFACE_VERSION 7. If found, it sets
XEN_DOMCTL_INTERFACE_VERSION to 6, which is also new to Xen 4.0.
I noticed some debug messages are printed with an empty lines after
them. This patch removes these empty lines from all invocations of the
following macros:
VIR_DEBUG
VIR_DEBUG0
VIR_ERROR
VIR_ERROR0
VIR_INFO
VIR_WARN
VIR_WARN0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Upstream xen has changed parameters to the migration operation
several times over the past 18 months. Changeset 17553 removed
the resouce parameter, Changesets 17709, 17753, and 20326 added
ssl, node, and change_home_server parameters respectively.
Fortunately, testing has revealed that xend will fail the
operation if a parameter is missing but happily honor it if
unknown parameters are provided. Thus all currently supported
parameters can be provided, satisfying current xend but not
regressing older versions.
xen-unstable c/s 20685 changed the domctl interface, adding a field to
xen_domctl_getdomaininfo structure. This additional field causes stack
corruption in libvirt. xen-unstable c/s 20711 rightly bumped the domctl
interface version so it is at least possible to handle the new field.
This change accounts for shr_pages field added to xen_domctl_getdomaininfo
structure.
When querying about a domain from 0.3.3 (or RHEL 5.3) domain located
on a 0.6.3 (RHEL-5) machine, the errors are not properly reported.
This patch from Olivier Fourdan <ofourdan@redhat.com> , slightly
modified to not change the semantic when the domain os details cannot
be provided
* src/xen/proxy_internal.c src/xen/xen_hypervisor.c: add some missing
error reports
The Xen code for making HVM VT-d PCI passthrough attach and detach
wasn't working properly:
1) In xenDaemonAttachDevice(), we were always trying to reconfigure
a PCI passthrough device, even the first time we added it. This was
because the code in virDomainXMLDevID() was not checking xenstore for
the existence of the device, and always returning 0 (meaning that
the device already existed).
2) In xenDaemonDetachDevice(), we were trying to use "device_destroy"
to detach a PCI device. While you would think that is the right
method to call, it's actually wrong for PCI devices. In particular,
in upstream Xen (and soon in RHEL-5 Xen), device_configure is actually
used to destroy a PCI device.
To fix the attach
problem I add a lookup into xenstore to see if the device we are
trying to attach already exists. To fix the detach problem I change
it so that for PCI detach (only), we use device_configure with the
appropriate sxpr to do the detachment.
* src/xen/xend_internal.c: don't use device_destroy for PCI devices
and fix the other issues.
* src/xen/xs_internal.c src/xen/xs_internal.h: add
xenStoreDomainGetPCIID()
Set up the types for the domainMemoryStats function and insert it into the
virDriver structure definition. Because of static initializers, update
every driver and set the new field to NULL.
* include/libvirt/libvirt.h.in: new API
* src/driver.h src/*/*_driver.c src/vbox/vbox_tmpl.c: add the new
entry to the driver structure
* python/generator.py: fix compiler errors, the actual python binding is
implemented later
* src/driver.h: add an extra entry point in the structure
* 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/xen/xen_driver.c: add NULL entry points for
all drivers
* src/xen/xm_internal.c (xenXMConfigGetULong): Remove useless and
misleading test (always false) for val->str == NULL before code that
always dereferences val->str. "val" comes from virConfGetValue, and
at that point, val->str is guaranteed to be non-NULL.
(xenXMConfigGetBool): Likewise.
* src/util/conf.c (virConfSetValue): Ensure that vir->str is never NULL,
not even if someone tries to set such a value via virConfSetValue.
This is trivial for QEMU since you just have to not stop the vm before
starting the dump. And for Xen, you just pass the flag down to xend.
* include/libvirt/libvirt.h.in (virDomainCoreDumpFlags): Add VIR_DUMP_LIVE.
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Support live dumping.
* src/xen/xend_internal.c (xenDaemonDomainCoreDump): Support live dumping.
* tools/virsh.c (opts_dump): Add --live. (cmdDump): Map it to VIR_DUMP_LIVE.
This patch adds the --crash option (already present in "xm dump-core")
to "virsh dump". virDomainCoreDump already has a flags argument, so
the API/ABI is untouched.
* include/libvirt/libvirt.h.in (virDomainCoreDumpFlags): New flag for
CoreDump
* src/test/test_driver.c (testDomainCoreDump): Do not crash
after dump unless VIR_DUMP_CRASH is given.
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Shutdown the domain
instead of restarting it if --crash is passed.
* src/xen/xend_internal.c (xenDaemonDomainCoreDump): Support --crash.
* tools/virsh.c (opts_dump): Add --crash.
(cmdDump): Map it to flags for virDomainCoreDump and pass them.
This patch fixes the bug where paused/running state is not
transmitted during migration. As a result, in the QEMU driver
for example the machine was always started on the destination
end.
In order to do so, just read the state and if it is appropriate and
set the VIR_MIGRATE_PAUSED flag.
* src/libvirt.c (virDomainMigrateVersion1, virDomainMigrateVersion2):
Automatically add VIR_MIGRATE_PAUSED when appropriate.
* src/xen/xend_internal.c (xenDaemonDomainMigratePerform): Give a nicer
error message when migration of paused domains is attempted.
Replace free(virBufferContentAndReset()) with virBufferFreeAndReset().
Update documentation and replace all remaining calls to free() with
calls to VIR_FREE(). Also add missing calls to virBufferFreeAndReset()
and virReportOOMError() in OOM error cases.
xen-unstable changesets 20321 and 20521 added support for
description in xend domain config. This patch extends that
support in xend backend.
* src/xen/xend_internal.c: add parse and output of domain description
Xen HVM guests with PV drivers end up with two network interfaces for
each configured interface. One of them being emulated by qemu and the
other one paravirtual. As this might not be desirable, the attached
patch provides a way for users to specify that only paravirtual network
interface should be presented to the guest.
The configuration was inspired by qemu/kvm driver, for which users can
specify model='virtio' to use paravirtual network interface.
The patch adds support for model='netfront' which results in
type=netfront instead of type=ioemu (or nothing for newer xen versions)
in guests native configuration. Xen's qemu ignores interfaces with
type != ioemu and only paravirtual network device will be seen in the
guest.
Four possible configuration scenarios follow:
- no model specified in domain's XML
- libvirt will behave like before this change; it will set
type=ioemu for HVM guests on xen host which is not newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU
- covered by existing tests
- PV guest, any model
- no functional change, model is passed as is (and ignored by the
hypervisor)
- covered by existing tests (e.g., *-net-e1000.*)
- HVM guest, model=netfront
- type is set to "netfront", model is not specified
- covered by new *-net-netfront.* tests
- HVM guest, model != netfront
- type is set to "ioemu", model is passed as is
- covered by new *-net-ioemu.* tests
The fourth scenario feels like a regression for xen newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU as users who had a model specified
in their guest's configuration won't see a paravirtual interface in
their guests any more. On the other hand, the reason for specifying a
model is most likely the fact that they want to use such model which
implies emulated interface. Users of older xen won't be affected at all
as their xen provides paravirtual interface regardless of the type used.
- src/xen/xend_internal.c: add netfront support for the xend backend
- src/xen/xm_internal.c: add netfront support for the XM serialization too
Commit 790f0b3057 causes the contents of
the names array to be freed even on success, resulting in no listing of
defined but inactive Xen domains.
Spotted by Jim Fehlig
Introduce a new type="dir" mode for <disks> that allows use of
QEMU's virtual FAT block device driver. eg
<disk type='dir' device='floppy'>
<source dir='/tmp/test'/>
<target dev='fda' bus='fdc'/>
<readonly/>
</disk>
gets turned into
-drive file=fat:floppy:/tmp/test,if=floppy,index=0
Only read-only disks are supported with virtual FAT mode
* src/conf/domain_conf.c, src/conf/domain_conf.h: Add type="dir"
* docs/schemas/domain.rng: Document new disk type
* src/xen/xend_internal.c, src/xen/xm_internal.c: Raise error for
unsupported disk types
* tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom-empty.args: Fix
empty disk file handling
* tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fat.args,
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fat.xml,
tests/qemuxml2argvdata/qemuxml2argv-floppy-drive-fat.args,
tests/qemuxml2argvdata/qemuxml2argv-floppy-drive-fat.xml
tests/qemuxml2argvtest.c: Test QEMU vitual FAT driver
* src/qemu/qemu_conf.c: Support generating fat:/some/dir type
disk args
* src/security/security_selinux.c: Temporarily skip labelling
of directory based disks
* src/xen/xen_hypervisor.c: xen-unstable changeset 19788 removed
MAX_VIRT_CPUS from public headers, breaking compilation of libvirt
on -unstable. Its semanitc was retained with XEN_LEGACY_MAX_VCPUS.
Ensure MAX_VIRT_CPUS is defined accordingly.
There is currently no way to determine the libvirt version of a remote
libvirtd we are connected to. This is a useful piece of data to enable
feature detection.
* src/xen/xen_driver.c: Add support for VIR_MIGRATE_PERSIST_DEST flag
* src/xen/xend_internal.c: Add support for VIR_MIGRATE_UNDEFINE_SOURCE flag
* include/libvirt/virterror.h, src/util/virterror.c: Add new errorcode
VIR_ERR_MIGRATE_PERSIST_FAILED
The xenstore database sometimes has stale domain IDs which are not
present in the hypervisor anymore. Filter these out to avoid causing
confusion
* src/xen/xs_internal.c: Filter domain IDs against HV's list
* src/xen/xen_hypervisor.h, src/xen/xen_hypervisor.c: Add new
xenHypervisorHasDomain() method for checking ID validity
The xenUnifiedNumOfDomains and xenUnifiedListDomains methods work
together as a pair, so it is critical they both apply the same
logic. With the current mis-matched logic it is possible to sometimes
get into a state when you miss certain active guests.
* src/xen/xen_driver.c: Change xenUnifiedNumOfDomains ordering to
match xenUnifiedListDomains.
Introduce a number of new APIs to expose some boolean properties
of objects, which cannot otherwise reliably determined, nor are
aspects of the XML configuration.
* virDomainIsActive: Checking virDomainGetID is not reliable
since it is not possible to distinguish between error condition
and inactive domain for ID of -1.
* virDomainIsPersistent: Check whether a persistent config exists
for the domain
* virNetworkIsActive: Check whether the network is active
* virNetworkIsPersistent: Check whether a persistent config exists
for the network
* virStoragePoolIsActive: Check whether the storage pool is active
* virStoragePoolIsPersistent: Check whether a persistent config exists
for the storage pool
* virInterfaceIsActive: Check whether the host interface is active
* virConnectIsSecure: whether the communication channel to the
hypervisor is secure
* virConnectIsEncrypted: whether any network based commnunication
channels are encrypted
NB, a channel can be secure, even if not encrypted, eg if it does
not involve the network, like a UNIX socket, or pipe.
* include/libvirt/libvirt.h.in: Define public API
* src/driver.h: Define internal driver API
* src/libvirt.c: Implement public API entry point
* src/libvirt_public.syms: Export API symbols
* src/esx/esx_driver.c, src/lxc/lxc_driver.c,
src/interface/netcf_driver.c, src/network/bridge_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/xen/xen_driver.c: Stub out driver tables
* src/libvirt.c src/lxc/lxc_conf.c src/lxc/lxc_container.c
src/lxc/lxc_controller.c src/node_device/node_device_hal.c
src/openvz/openvz_conf.c src/qemu/qemu_driver.c
src/qemu/qemu_monitor_text.c src/remote/remote_driver.c
src/storage/storage_backend_disk.c src/storage/storage_driver.c
src/util/logging.c src/xen/sexpr.c src/xen/xend_internal.c
src/xen/xm_internal.c: Steve Grubb <sgrubb@redhat.com> sent a code
review and those are the fixes correcting the problems
A character device's target (it's interface in the guest) had only a
single property: port. This patch is in preparation for adding targets
which require other properties.
Since this changes the conf type for character devices this affects
a number of drivers:
* src/conf/domain_conf.[ch] src/esx/esx_vmx.c src/qemu/qemu_conf.c
src/qemu/qemu_driver.c src/uml/uml_conf.c src/uml/uml_driver.c
src/vbox/vbox_tmpl.c src/xen/xend_internal.c src/xen/xm_internal.c:
target properties are moved into a union in virDomainChrDef, and a
targetType field is added to identify which union member should be
used. All current code which touches a virDomainChrDef is updated both
to use the new union field, and to populate targetType if necessary.
- Don't duplicate SystemError
- Use proper error code in domain_conf
- Fix a broken error call in qemu_conf
- Don't use VIR_ERR_ERROR in security driver (isn't a valid code in this case)
All drivers have copy + pasted inadequate error reporting which wraps
util.c:virGetHostname. Move all error reporting to this function, and improve
what we report.
Changes from v1:
Drop the driver wrappers around virGetHostname. This means we still need
to keep the new conn argument to virGetHostname, but I think it's worth
it.
The LXC driver was mistakenly returning -1 for lxcStartup()
in scenarios that are not an error. This caused the libvirtd
to quit for unprivileged users. This fixes the return code
of LXC driver, and also adds a "name" field to the virStateDriver
struct and logging to make it easier to find these problems
in the future
* src/driver.h: Add a 'name' field to state driver to allow
easy identification during failures
* src/libvirt.c: Log name of failed driver for virStateInit
failures
* src/lxc/lxc_driver.c: Don't return a failure code for
lxcStartup() if LXC is not available on this host, simply
disable the driver.
* src/network/bridge_driver.c, src/node_device/node_device_devkit.c,
src/node_device/node_device_hal.c, src/opennebula/one_driver.c,
src/qemu/qemu_driver.c, src/remote/remote_driver.c,
src/secret/secret_driver.c, src/storage/storage_driver.c,
src/uml/uml_driver.c, src/xen/xen_driver.c: Fill in name
field in virStateDriver struct
Nearly all of the methods in src/util/util.h have error codes that
must be checked by the caller to correct detect & report failure.
Add ATTRIBUTE_RETURN_CHECK to ensure compile time validation of
this
* daemon/libvirtd.c: Add explicit check on return value of virAsprintf
* src/conf/domain_conf.c: Add missing check on virParseMacAddr return
value status & report error
* src/network/bridge_driver.c: Add missing OOM check on virAsprintf
and report error
* src/qemu/qemu_conf.c: Add missing check on virParseMacAddr return
value status & report error
* src/security/security_selinux.c: Remove call to virRandomInitialize
that's done in libvirt.c already
* src/storage/storage_backend_logical.c: Add check & log on virRun
return status
* src/util/util.c: Add missing checks on virAsprintf/Run status
* src/util/util.h: Annotate all methods with ATTRIBUTE_RETURN_CHECK
if they return an error status code
* src/vbox/vbox_tmpl.c: Add missing check on virParseMacAddr
* src/xen/xm_internal.c: Add missing checks on virAsprintf
* tests/qemuargv2xmltest.c: Remove bogus call to virRandomInitialize()
In xenInotifyXendDomainsDirLookup() the wrong UUID variable is used
to search in the config info list.
In xenInotifyEvent() the event is dispatched if it's NULL.
Both were introduced in bc898df2c7.
xenUnifiedDomainEventRegister() calls out to
virDomainEventCallbackListAdd(), which increments the reference
count on the connection. That is fine, but then
xenUnifiedDomainEventRegister() increments the usage count again,
leading to a usage count leak. Remove the increment in the xen
register, and the UnrefConnect in the xen unregister.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Most of the hash iterators need to modify either payload of
data args. The const annotation prevents this.
* src/util/hash.h, src/util/hash.c: Remove const-ness from
virHashForEach/Iterator
* src/xen/xm_internal.c: Remove bogus casts
If one has e.g.
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.11</machine>
<machine canonical='pc-0.11'>pc</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/kvm</emulator>
<machine>pc</machine>
<machine>isapc</machine>
</domain>
</arch>
</guest>
and start a guest with:
<domain type='kvm'>
...
<os>
<type arch='x86_64'>hvm</type>
...
</os>
</domain>
then the default machine type should be 'pc' and not 'pc-0.11'
Issue was reported by Anton Protopopov.
* src/capabilities.[ch]: pass the domain type to
virCapabilitiesDefaultGuestArch() and use it to look up the default
machine type from a specific guest domain if needed.
* src/conf/domain_conf.c, src/xen/xm_internal.c: update
* tests/qemuxml2argvdata/qemuxml2argv-machine-aliases2.xml: update
the domain type to 'kvm' and remove the machine type to check
that the default gets looked up correctly
Introduces several new public API options for migration
- VIR_MIGRATE_PEER2PEER: With this flag the client only
invokes the virDomainMigratePerform method, expecting
the source host driver to do whatever is required to
complete the entire migration process.
- VIR_MIGRATE_TUNNELLED: With this flag the actual data
for migration will be tunnelled over the libvirtd RPC
channel. This requires that VIR_MIGRATE_PEER2PEER is
also set.
- virDomainMigrateToURI: This is variant of the existing
virDomainMigrate method which does not require any
virConnectPtr for the destination host. Given suitable
driver support, this allows for all the same modes as
virDomainMigrate()
The URI for VIR_MIGRATE_PEER2PEER must be a valid libvirt
URI. For non-p2p migration a hypervisor specific migration
URI is used.
virDomainMigrateToURI without a PEER2PEER flag is only
support for Xen currently, and it involves XenD talking
directly to XenD, no libvirtd involved at all.
* include/libvirt/libvirt.h.in: Add VIR_MIGRATE_PEER2PEER
flag for migration
* src/libvirt_internal.h: Add feature flags for peer to
peer migration (VIR_FEATURE_MIGRATE_P2P) and direct
migration (VIR_MIGRATE_PEER2PEER mode)
* src/libvirt.c: Implement support for VIR_MIGRATE_PEER2PEER
and virDomainMigrateToURI APIs.
* src/xen/xen_driver.c: Advertise support for DIRECT migration
* src/xen/xend_internal.c: Add TODO item for p2p migration
* src/libvirt_public.syms: Export virDomainMigrateToURI
method
* src/qemu/qemu_driver.c: Add support for PEER2PEER and
migration, and adapt TUNNELLED migration.
* tools/virsh.c: Add --p2p and --direct args and use the
new virDomainMigrateToURI method where possible.
Implementation of tunnelled migration, using a Unix Domain Socket
on the qemu backend. Note that this requires very new versions of
qemu (0.10.7 at least) in order to get the appropriate bugfixes.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Add the virStrncpy function, which takes a dst string, source string,
the number of bytes to copy and the number of bytes available in the
dest string. If the source string is too large to fit into the
destination string, including the \0 byte, then no data is copied and
the function returns NULL. Otherwise, this function copies n bytes
from source into dst, including the \0, and returns a pointer to the
dst string. This function is intended to replace all unsafe uses
of strncpy in the code base, since strncpy does *not* guarantee that
the buffer terminates with a \0.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
The commit cb51aa48a7 "Fix up connection
reference counting." changed the driver closing and virConnectPtr
unref-logic in virConnectClose().
Before this commit virConnectClose() closed all drivers of the given
virConnectPtr and virUnrefConnect()'ed it afterwards. After this
commit the driver-closing is done in virUnrefConnect() if and only if
the ref-count of the virConnectPtr dropped to zero.
This change in execution order leads to a virConnectPtr leak, at least
for connections to Xen.
The relevant call sequences:
virConnectOpen() -> xenUnifiedOpen() ...
... xenInotifyOpen() -> virConnectRef(conn)
... xenStoreOpen() -> xenStoreAddWatch() -> conn->refs++
virConnectClose() -> xenUnifiedClose() ...
... xenInotifyClose() -> virUnrefConnect(conn)
... xenStoreClose() -> xenStoreRemoveWatch() -> virUnrefConnect(conn)
Before the commit this additional virConnectRef/virUnrefConnect calls
where no problem, because virConnectClose() closed the drivers
explicitly and the additional refs added by the Xen subdrivers were
removed properly. After the commit this additional refs result in a
virConnectPtr leak (including a leak of the hypercall file handle;
that's how I noticed this problem), because now the drivers are only
close if and only if the ref-count drops to zero, but this cannot
happen anymore, because the additional refs from the Xen subdrivers
would only be removed if the drivers get closed, but that doesn't
happen because the ref-count cannot drop to zero.
The fix for this problem is simple: remove the
virConnectRef/virUnrefConnect calls from the Xen subdrivers (see
attached patch). Maybe someone could explain why the Xen Inotify and
Xen Store driver do this extra ref-counting, but none of the other Xen
subdrivers. It seems unnecessary to me and can be removed without
problems.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
