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.
virsh didn't call virInitialize(), which (among other things)
initializes virLastErr thread local variable. As a result of that, virsh
could just segfault in virEventRegisterDefaultImpl() since that is the
first call that touches (resets) virLastErr.
I have no idea what lucky coincidence made this bug visible but I was
able to reproduce it in 100% cases but only in one specific environment
which included building in sandbox.
Mingw execve() has a broken signature. Disable this
function until gnulib fixes the signature, since we
don't really need this on Win32 anyway.
* src/util/command.c: Disable virCommandExec on Win32
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
By running the doTunnelSendAll code in a separate thread, the
main thread can do qemuMigrationWaitForCompletion as with
normal migration. This in turn ensures that job signals work
correctly and that progress monitoring can be done
* src/qemu/qemu_migration.c: Run tunnelled migration in
separate thread
Cancelling the QEMU migration may cause QEMU to flush pending
data on the migration socket. This may in turn block QEMU if
nothing reads from the other end of the socket. Closing the
socket before cancelling QEMU migration avoids this possible
deadlock.
* src/qemu/qemu_migration.c: Close sockets before cancelling
migration on failure
The 'nbytes' variable was not re-initialized to the
buffer size on each iteration of the tunnelled migration
loop. While saferead() will ensure a full read, except
on EOF, it is clearer to use the real buffer size
* src/qemu/qemu_migration.c: Always read full buffer of data
The qemuMigrationWaitForCompletion method contains a loop which
repeatedly queries QEMU to check migration progress, and also
processes job signals (pause, setspeed, setbandwidth, cancel).
The tunnelled migration loop does not currently support this
functionality, but should. Refactor the code to allow it to
be used with tunnelled migration.
Implement the v3 migration protocol, which has two extra
steps, 'begin' on the source host and 'confirm' on the
source host. All other methods also gain both input and
output cookies to allow bi-directional data passing at
all stages.
The QEMU peer2peer migration method gains another impl
to provide the v3 migration. This finally allows migration
cookies to work with tunnelled migration, which is required
for Spice seamless migration & the lock manager transfer
* src/qemu/qemu_driver.c: Wire up migrate v3 APIs
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Add
begin & confirm methods, and peer2peer impl of v3
Merge the doNonTunnelMigrate2 and doTunnelMigrate2 methods
into one doPeer2PeerMigrate2 method, since they are substantially
the same. With the introduction of v3 migration, this will be
even more important, to avoid massive code duplication.
* src/qemu/qemu_migration.c: Merge tunnel & non-tunnel migration
The v2 migration protocol was accidentally missing out the
finish step, when prepare succeeded, but returned an invalid
URI
* src/libvirt.c: Teardown VM if prepare returns invalid URI
To facilitate the introduction of the v3 migration protocol,
the doTunnelMigrate method is refactored into two pieces. One
piece is intended to mirror the flow of virDomainMigrateVersion2,
while the other is the helper for setting up sockets and processing
the data.
Previously socket setup would be done before the 'prepare' step,
so errors could be dealt with immediately, avoiding need to shut
off the destination QEMU. In the new split, socket setup is done
after the 'prepare' step. This is not a serious problem, since
the control flow already requires calling 'finish' to tear down
the destination QEMU upon several errors.
* src/qemu/qemu_migration.c:
Use the graphics information from the QEMU migration cookie to
issue a 'client_migrate_info' monitor command to QEMU. This causes
the SPICE client to automatically reconnect to the target host
when migration completes
* src/qemu/qemu_migration.c: Set data for SPICE client relocation
before starting migration on src
* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h,
src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add
new qemuMonitorGraphicsRelocate() command
Extend the QEMU migration cookie structure to allow information
about the destination host graphics setup to be passed by to
the source host. This will enable seamless migration of any
connected graphics clients
* src/qemu/qemu_migration.c: Add graphics info to migration
cookies
* daemon/libvirtd.c: Always initialize gnutls to enable
x509 cert parsing in QEMU
The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs to do a few things:
- Pass hostname/uuid to allow strict protection against localhost
migration attempts
- Pass SPICE/VNC server port from the target back to the source to
allow seamless relocation of client sessions
- Pass lock driver state from source to destination
This patch introduces the basic glue for handling cookies
but only includes the host/guest UUID & name.
* src/libvirt_private.syms: Export virXMLParseStrHelper
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Parsing
and formatting of migration cookies
* src/qemu/qemu_driver.c: Pass in cookie parameters where possible
* src/remote/remote_protocol.h, src/remote/remote_protocol.x: Change
cookie max length to 16384 bytes
The qemuMigrationPrepareTunnel method should not unlock the
qemu driver, since that is the caller's job.
* src/qemu/qemu_migration.c: Fix qemuMigrationPrepareTunnel
unlocking of QEMU driver
Migration just seems to go from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
It turns out that this protocol still has some flaws that we
need to address. The current sequence is
* Src: DumpXML
- Generate XML to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Kill off VM if successful, resume if failed
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if unsuccessful
The problems with this are:
- Since the first step is a generic 'DumpXML' call, we can't
add in other migration specific data. eg, we can't include
any VM lease data from lock manager plugins
- Since the first step is a generic 'DumpXML' call, we can't
emit any 'migration begin' event on the source, or have
any hook that runs right at the start of the process
- Since there is no final step on the source, if the Finish
method fails to receive all migration data & has to kill
the VM, then there's no way to resume the original VM
on the source
This patch attempts to introduce a version 3 that uses the
improved 5 step sequence
* Src: Begin
- Generate XML to pass to dst
- Generate optional cookie to pass to dst
* Dst: Prepare
- Get ready to accept incoming VM
- Generate optional cookie to pass to src
* Src: Perform
- Start migration and wait for send completion
- Generate optional cookie to pass to dst
* Dst: Finish
- Wait for recv completion and check status
- Kill off VM if failed, resume if success
- Generate optional cookie to pass to src
* Src: Confirm
- Kill off VM if success, resume if failed
The API is designed to allow both input and output cookies
in all methods where applicable. This lets us pass around
arbitrary extra driver specific data between src & dst during
migration. Combined with the extra 'Begin' method this lets
us pass lease information from source to dst at the start of
migration
Moving the killing of the source VM out of Perform and
into Confirm, means we can now recover if the dst host
can't successfully Finish receiving migration data.
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/
Only in drivers which use virDomainObj, drivers that query hypervisor
for domain status need to be updated separately in case their hypervisor
supports this functionality.
The reason is also saved into domain state XML so if a domain is not
running (i.e., no state XML exists) the reason will be lost by libvirtd
restart. I think this is an acceptable limitation.
This has been present since the introduction of phypAttachDevice
in commit 444fd07a.
* src/phyp/phyp_driver.c (phypAttachDevice): Don't dereference
NULL.
virFDStreamClose used a mutex after it was freed, and failed
to destroy that mutex on its last use.
* src/fdstream.c (virFDStreamFree): Inline into sole caller...
(virFDStreamClose): ...to avoid use-after-free and leak.
Reported by Matthias Bolte.
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.
One functionality change here is that we no longer force enable the event
timeout for every queued event, only enable it for the first event after
the queue has been flushed. This is how other drivers have already done it,
and I haven't encountered problems in practice.
v3:
Adjust for new virDomainEventStateNew argument
The same code for queueing, flushing, and deregistering events exists
in multiple drivers, which will soon use these common functions.
v2:
Adjust libvirt_private.syms
isDispatching bool fixes
NONNULL tagging
v3:
Add requireTimer parameter to virDomainEventStateNew
This structure will be used to unify lots of duplicated event handling code
across the state drivers.
v2:
Check for state == NULL in StateFree
Add NONNULL tagging
Use bool for isDispatching
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Use capabilities to allow a driver to register a default <init> if none
is specified in the XML. Openvz was already open-coding this to be /sbin/init
LXC currently falls over if no init is specified, so an explicit error is
an improvement IMO.
(Side note: I don't think we can set a default value for LXC. If we use
/sbin/init but the user doesn't specify a separate root FS for their guest,
the container will rerun the host's init which can be traumatic :). For
virt-install I'm thinking of defaulting to /sbin/init if a root FS has
been specified, otherwise require the user to manually specify <init>)
This is needed if we want to transfer a temporary file. If the
transfer is done with iohelper, we might run into a race condition,
where we unlink() file before iohelper is executed.
* src/fdstream.c, src/fdstream.h,
src/util/iohelper.c: Add new option
* src/lxc/lxc_driver.c, src/qemu/qemu_driver.c,
src/storage/storage_driver.c, src/uml/uml_driver.c,
src/xen/xen_driver.c: Expand existing function calls
Add public API for taking screenshots of current domain console.
* include/libvirt/libvirt.h.in: add virDomainScreenshot
* src/libvirt_public.syms: Export new symbol
The public API and RPC over-the-wire format have no flags argument,
so neither should the internal callback API. This simplifies the
RPC generator.
* src/driver.h (virDrvNWFilterDefineXML): Drop argument that does
not match public API.
* src/nwfilter/nwfilter_driver.c (nwfilterDefine): Likewise.
* src/libvirt.c (virNWFilterDefineXML): Likewise.
* daemon/remote_generator.pl: Drop special case.
We were 31/73 on whether to translate; since less than 50% translated
and since VIR_INFO is less than VIR_WARN which also doesn't translate,
this makes sense.
* cfg.mk (sc_prohibit_gettext_markup): Add VIR_INFO, since it
falls between WARN and DEBUG.
* daemon/libvirtd.c (qemudDispatchSignalEvent, remoteCheckAccess)
(qemudDispatchServer): Adjust offenders.
* daemon/remote.c (remoteDispatchAuthPolkit): Likewise.
* src/network/bridge_driver.c (networkReloadIptablesRules)
(networkStartNetworkDaemon, networkShutdownNetworkDaemon)
(networkCreate, networkDefine, networkUndefine): Likewise.
* src/qemu/qemu_driver.c (qemudDomainDefine)
(qemudDomainUndefine): Likewise.
* src/storage/storage_driver.c (storagePoolCreate)
(storagePoolDefine, storagePoolUndefine, storagePoolStart)
(storagePoolDestroy, storagePoolDelete, storageVolumeCreateXML)
(storageVolumeCreateXMLFrom, storageVolumeDelete): Likewise.
* src/util/bridge.c (brProbeVnetHdr): Likewise.
* po/POTFILES.in: Drop src/util/bridge.c.
This one's tricker than the VIR_DEBUG0() removal, but the end
result is still C99 compliant, and reasonable with enough comments.
* src/libvirt.c (VIR_ARG10, VIR_HAS_COMMA)
(VIR_DOMAIN_DEBUG_EXPAND, VIR_DOMAIN_DEBUG_PASTE): New macros.
(VIR_DOMAIN_DEBUG): Rewrite to handle one argument, moving
multi-argument guts to...
(VIR_DOMAIN_DEBUG_1): New macro.
(VIR_DOMAIN_DEBUG0): Rename to VIR_DOMAIN_DEBUG_0.
Use of ',##__VA_ARGS__' is a gcc extension not guaranteed by
C99; thankfully, we can avoid it by lumping the format argument
into the var-args set.
* src/util/logging.h (VIR_DEBUG_INT, VIR_INFO_INT, VIR_WARN_INT)
(VIR_ERROR_INT, VIR_DEBUG, VIR_INFO, VIR_WARN, VIR_ERROR): Stick
to C99 var-arg macro syntax.
* examples/domain-events/events-c/event-test.c (VIR_DEBUG):
Simplify.
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>
If we plow on after udev_device_get_syspath fails, we will hit a NULL
dereference. Clang found one due to strdup later in udevSetParent,
but in fact we hit a NULL dereference sooner because of the use of
STREQ within virNodeDeviceFindBySysfsPath.
* src/conf/node_device_conf.h (virNodeDeviceFindBySysfsPath): Mark
path argument non-null.
* src/node_device/node_device_udev.c (udevSetParent): Avoid null
dereference.
No syntactic effect; this merely silences some clang warnings.
* src/libxl/libxl_driver.c (libxlDomainSetVcpusFlags): Drop
redundant ret=0 statement.
* src/qemu/qemu_monitor_text.c (qemuMonitorTextDriveDel):
Likewise.
Introduce a virProcessKill function that can be safely called
even when the job mutex is held. This allows virDomainDestroy
to kill any VM even if it is asleep in a monitor job. The PID
will die and the thread asleep on the monitor will then wake
up releasing the job mutex.
* src/qemu/qemu_driver.c: Kill process before using qemuProcessStop
to ensure job is released
* src/qemu/qemu_process.c: Add virProcessKill for killing off
QEMU processes
Version 2.0.0 or yajl changed API. It is fairly trivial for us to
cope with both APIs in libvirt, so adapt.
* configure.ac: Probe for yajl2 API
* src/util/json.c: Conditional support for yajl2 API
libxl accepts hpet configuration in its domain info struct. Parse the
domain definition's <clock> element in order to set the value.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Apologies from Eric Blake, for mistakenly committing the broken
intermediate version.
libxl accepts hpet configuration in its domain info struct. Parse the
domain definition's <clock> element in order to set the value.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Recent versions of Xen disable the virtual HPET by default. This is
usually more precise because tick policies are not implemented for
the HPET in Xen. However, there may be several reasons to control
the HPET manually: 1) to test the emulation; 2) because distros may
provide the knob while leaving the default to "enabled" for compatibility
reasons.
This patch provides support for the hpet item in both sexpr and xm
formats, and translates it to a <timer> element.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Allow the CA certificate to come from the user's home directory or from
the global location independently of the client certificate/key pair.
Mostly for the case when each user on a system has their own cert/key
pair but the system as a whole shares the same CA.
Signed-off-by: Doug Goldstein <cardoe@gentoo.org>
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.
Actually execs the argv/env we've generated, replacing the current process.
Kind of has a limited usage, but allows us to use virCommand in LXC
driver to launch the 'init' process