libvirt/src/libxl/libxl_domain.h

159 lines
4.9 KiB
C
Raw Normal View History

/*
* libxl_domain.h: libxl domain object private state
*
* Copyright (C) 2011-2014 SUSE LINUX Products GmbH, Nuernberg, Germany.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*/
#pragma once
#include <libxl.h>
#include "domain_conf.h"
#include "libxl_conf.h"
#include "virchrdev.h"
#include "virenum.h"
#define JOB_MASK(job) (job == 0 ? 0 : 1 << (job - 1))
#define DEFAULT_JOB_MASK \
(JOB_MASK(LIBXL_JOB_DESTROY) | \
JOB_MASK(LIBXL_JOB_ABORT))
/* Only 1 job is allowed at any time
* A job includes *all* libxl.so api, even those just querying
* information, not merely actions */
enum libxlDomainJob {
LIBXL_JOB_NONE = 0, /* Always set to 0 for easy if (jobActive) conditions */
LIBXL_JOB_QUERY, /* Doesn't change any state */
LIBXL_JOB_DESTROY, /* Destroys the domain (cannot be masked out) */
LIBXL_JOB_MODIFY, /* May change state */
LIBXL_JOB_LAST
};
VIR_ENUM_DECL(libxlDomainJob);
struct libxlDomainJobObj {
virCond cond; /* Use to coordinate jobs */
enum libxlDomainJob active; /* Currently running job */
int owner; /* Thread which set current job */
unsigned long long started; /* When the job started */
virDomainJobInfoPtr current; /* Statistics for the current job */
};
typedef struct _libxlDomainObjPrivate libxlDomainObjPrivate;
struct _libxlDomainObjPrivate {
virObjectLockable parent;
/* console */
virChrdevs *devs;
libxl_evgen_domain_death *deathW;
/* Flag to indicate the upcoming LIBXL_EVENT_TYPE_DOMAIN_DEATH is caused
* by libvirt and should not be handled separately */
bool ignoreDeathEvent;
virThread *migrationDstReceiveThr;
unsigned short migrationPort;
char *lockState;
libxl: Add lock process indicator to libxlDomainObjPrivate object The libvirt libxl driver has no access to FDs associated with VM disks. The disks are opened by libxl.so and any related FDs are not exposed to applications. The prevents using virtlockd's auto-release feature to release locks when the FD is closed. Acquiring and releasing locks is explicitly handled by the libxl driver. The current logic is structured such that locks are acquired in libxlDomainStart and released in libxlDomainCleanup. This works well except for migration, where the locks must be released on the source host before the domain can be started on the destination host, but the domain cannot be cleaned up until the migration confirmation stage. When libxlDomainCleanup if finally called in the confirm stage, locks are again released resulting in confusing errors from virtlockd and libvirtd virtlockd[8095]: resource busy: Lockspace resource 'xxxxxx' is not locked libvirtd[8050]: resource busy: Lockspace resource 'xxxxxx' is not locked libvirtd[8050]: Unable to release lease on testvm The error is also encountered in some error cases, e.g. when libxlDomainStart fails before acquiring locks and libxlDomainCleanup is still used for cleanup. In lieu of a mechanism to check if a lock has been acquired, this patch takes an easy approach to fixing the unnecessary lock releases by adding an indicator to the libxlDomainPrivate object that can be set when the lock is acquired and cleared when the lock is released. libxlDomainCleanup can then skip releasing the lock in cases where it was previously released or never acquired in the first place. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-19 21:58:19 +00:00
bool lockProcessRunning;
struct libxlDomainJobObj job;
bool hookRun; /* true if there was a hook run over this domain */
};
extern virDomainXMLPrivateDataCallbacks libxlDomainXMLPrivateDataCallbacks;
extern virDomainDefParserConfig libxlDomainDefParserConfig;
extern virXMLNamespace libxlDriverDomainXMLNamespace;
extern const struct libxl_event_hooks ev_hooks;
int
libxlDomainObjPrivateInitCtx(virDomainObj *vm);
int
libxlDomainObjBeginJob(libxlDriverPrivate *driver,
virDomainObj *obj,
enum libxlDomainJob job)
G_GNUC_WARN_UNUSED_RESULT;
void
libxlDomainObjEndJob(libxlDriverPrivate *driver,
virDomainObj *obj);
int
libxlDomainJobUpdateTime(struct libxlDomainJobObj *job)
G_GNUC_WARN_UNUSED_RESULT;
char *
libxlDomainManagedSavePath(libxlDriverPrivate *driver,
virDomainObj *vm);
int
libxlDomainSaveImageOpen(libxlDriverPrivate *driver,
libxlDriverConfig *cfg,
const char *from,
virDomainDef **ret_def,
libxlSavefileHeader *ret_hdr)
ATTRIBUTE_NONNULL(4) ATTRIBUTE_NONNULL(5);
int
libxlDomainDestroyInternal(libxlDriverPrivate *driver,
virDomainObj *vm);
void
libxlDomainCleanup(libxlDriverPrivate *driver,
virDomainObj *vm);
/*
* Note: Xen 4.3 removed the const from the event handler signature.
* Detect which signature to use based on
* LIBXL_HAVE_NONCONST_EVENT_OCCURS_EVENT_ARG.
*/
#ifdef LIBXL_HAVE_NONCONST_EVENT_OCCURS_EVENT_ARG
# define VIR_LIBXL_EVENT_CONST /* empty */
#else
# define VIR_LIBXL_EVENT_CONST const
#endif
void
libxlDomainEventHandler(void *data,
VIR_LIBXL_EVENT_CONST libxl_event *event);
int
libxlDomainAutoCoreDump(libxlDriverPrivate *driver,
virDomainObj *vm);
int
libxlDomainSetVcpuAffinities(libxlDriverPrivate *driver,
virDomainObj *vm);
int
libxlDomainStartNew(libxlDriverPrivate *driver,
virDomainObj *vm,
libxl: support Xen migration stream V2 in save/restore Xen 4.6 introduced a new migration stream commonly referred to as "migration V2". Xen 4.6 and newer always produce this new stream, whereas Xen 4.5 and older always produce the legacy stream. Support for migration stream V2 can be detected at build time with LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not compatible, but a V2 host can accept and convert a legacy stream. Commit e7440656 changed the libxl driver to use the lowest libxl API version possible (version 0x040200) to ensure the driver builds against older Xen releases. The old 4.2 restore API does not support specifying a stream version and assumes a legacy stream, even if the incoming stream is migration V2. Thinking it has been given a legacy stream, libxl will fail to convert an incoming stream that is already V2, which causes the entire restore operation to fail. Xen's libvirt-related OSSTest has been failing since commit e7440656 landed in libvirt.git master. One of the more recent failures can be seen here http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html This patch changes the call to libxl_domain_create_restore() to include the stream version if LIBXL_HAVE_SRM_V2 is defined. The version field of the libxlSavefileHeader struct is also updated to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream version in the header matches the actual stream version produced by Xen. Along with bumping the libxl API requirement to 0x040400, this patch fixes save/restore on a migration V2 Xen host. Oddly, migration has never used the libxlSavefileHeader. It handles passing configuration in the Begin and Prepare phases, and then calls libxl directly to transfer domain state/memory in the Perform phase. A subsequent patch will add stream version handling in the Begin and Prepare phase handshaking, which will fix the migration related OSSTest failures. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-02 18:00:39 +00:00
bool start_paused);
int
libxlDomainStartRestore(libxlDriverPrivate *driver,
virDomainObj *vm,
libxl: support Xen migration stream V2 in save/restore Xen 4.6 introduced a new migration stream commonly referred to as "migration V2". Xen 4.6 and newer always produce this new stream, whereas Xen 4.5 and older always produce the legacy stream. Support for migration stream V2 can be detected at build time with LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not compatible, but a V2 host can accept and convert a legacy stream. Commit e7440656 changed the libxl driver to use the lowest libxl API version possible (version 0x040200) to ensure the driver builds against older Xen releases. The old 4.2 restore API does not support specifying a stream version and assumes a legacy stream, even if the incoming stream is migration V2. Thinking it has been given a legacy stream, libxl will fail to convert an incoming stream that is already V2, which causes the entire restore operation to fail. Xen's libvirt-related OSSTest has been failing since commit e7440656 landed in libvirt.git master. One of the more recent failures can be seen here http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html This patch changes the call to libxl_domain_create_restore() to include the stream version if LIBXL_HAVE_SRM_V2 is defined. The version field of the libxlSavefileHeader struct is also updated to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream version in the header matches the actual stream version produced by Xen. Along with bumping the libxl API requirement to 0x040400, this patch fixes save/restore on a migration V2 Xen host. Oddly, migration has never used the libxlSavefileHeader. It handles passing configuration in the Begin and Prepare phases, and then calls libxl directly to transfer domain state/memory in the Perform phase. A subsequent patch will add stream version handling in the Begin and Prepare phase handshaking, which will fix the migration related OSSTest failures. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-02 18:00:39 +00:00
bool start_paused,
int restore_fd,
uint32_t restore_ver);
bool
libxlDomainDefCheckABIStability(libxlDriverPrivate *driver,
virDomainDef *src,
virDomainDef *dst);