Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
/*
|
|
|
|
|
* virnodesuspend.c: Support for suspending a node (host machine)
|
|
|
|
|
*
|
2014-04-14 08:50:42 +00:00
|
|
|
* Copyright (C) 2014 Red Hat, Inc.
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
* Copyright (C) 2011 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
|
|
|
|
|
*
|
|
|
|
|
* 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
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#include "virnodesuspend.h"
|
|
|
|
|
|
2014-04-11 07:20:48 +00:00
|
|
|
#include "virsystemd.h"
|
2012-12-12 16:27:01 +00:00
|
|
|
#include "vircommand.h"
|
2012-12-13 15:49:48 +00:00
|
|
|
#include "virthread.h"
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
#include "datatypes.h"
|
|
|
|
|
|
2012-12-12 18:06:53 +00:00
|
|
|
#include "viralloc.h"
|
2019-08-13 15:21:53 +00:00
|
|
|
#include "virfile.h"
|
2012-12-12 17:59:27 +00:00
|
|
|
#include "virlog.h"
|
2012-12-13 18:21:53 +00:00
|
|
|
#include "virerror.h"
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_NONE
|
|
|
|
|
|
2014-02-28 12:16:17 +00:00
|
|
|
VIR_LOG_INIT("util.nodesuspend");
|
|
|
|
|
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
#define SUSPEND_DELAY 10 /* in seconds */
|
|
|
|
|
|
|
|
|
|
/* Give sufficient time for performing the suspend operation on the host */
|
|
|
|
|
#define MIN_TIME_REQ_FOR_SUSPEND 60 /* in seconds */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Bitmask to hold the Power Management features supported by the host,
|
|
|
|
|
* such as Suspend-to-RAM, Suspend-to-Disk, Hybrid-Suspend etc.
|
|
|
|
|
*/
|
2011-11-29 15:20:03 +00:00
|
|
|
static unsigned int nodeSuspendTargetMask;
|
|
|
|
|
static bool nodeSuspendTargetMaskInit;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
2014-03-25 14:54:44 +00:00
|
|
|
static virMutex virNodeSuspendMutex = VIR_MUTEX_INITIALIZER;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
static bool aboutToSuspend;
|
|
|
|
|
|
|
|
|
|
static void virNodeSuspendLock(void)
|
|
|
|
|
{
|
|
|
|
|
virMutexLock(&virNodeSuspendMutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void virNodeSuspendUnlock(void)
|
|
|
|
|
{
|
|
|
|
|
virMutexUnlock(&virNodeSuspendMutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* virNodeSuspendSetNodeWakeup:
|
|
|
|
|
* @alarmTime: time in seconds from now, at which the RTC alarm has to be set.
|
|
|
|
|
*
|
|
|
|
|
* Set up the RTC alarm to the specified time.
|
|
|
|
|
* Return 0 on success, -1 on failure.
|
|
|
|
|
*/
|
|
|
|
|
static int virNodeSuspendSetNodeWakeup(unsigned long long alarmTime)
|
|
|
|
|
{
|
2021-12-13 18:51:42 +00:00
|
|
|
g_autoptr(virCommand) setAlarmCmd = NULL;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
2012-07-25 05:52:49 +00:00
|
|
|
if (alarmTime < MIN_TIME_REQ_FOR_SUSPEND) {
|
2017-02-07 12:53:45 +00:00
|
|
|
virReportError(VIR_ERR_INVALID_ARG,
|
|
|
|
|
_("Suspend duration is too short, must be at least %u seconds"),
|
|
|
|
|
MIN_TIME_REQ_FOR_SUSPEND);
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
setAlarmCmd = virCommandNewArgList("rtcwake", "-m", "no", "-s", NULL);
|
|
|
|
|
virCommandAddArgFormat(setAlarmCmd, "%lld", alarmTime);
|
|
|
|
|
|
2021-12-13 18:51:42 +00:00
|
|
|
return virCommandRun(setAlarmCmd, NULL);
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2017-03-07 09:44:06 +00:00
|
|
|
* virNodeSuspendHelper:
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
* @cmdString: pointer to the command string this thread has to execute.
|
|
|
|
|
*
|
|
|
|
|
* Actually perform the suspend operation by invoking the command.
|
|
|
|
|
* Give a short delay before executing the command so as to give a chance
|
2017-03-07 09:44:06 +00:00
|
|
|
* to virNodeSuspend() to return the status to the caller.
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
* If we don't give this delay, that function will not be able to return
|
|
|
|
|
* the status, since the suspend operation would have begun and hence no
|
|
|
|
|
* data can be sent through the connection to the caller. However, with
|
|
|
|
|
* this delay added, the status return is best-effort only.
|
|
|
|
|
*/
|
2017-03-07 09:44:06 +00:00
|
|
|
static void virNodeSuspendHelper(void *cmdString)
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
{
|
2021-12-13 18:52:28 +00:00
|
|
|
g_autoptr(virCommand) suspendCmd = virCommandNew((const char *)cmdString);
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
/*
|
2017-03-07 09:44:06 +00:00
|
|
|
* Delay for sometime so that the function virNodeSuspend()
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
* can return the status to the caller.
|
|
|
|
|
*/
|
|
|
|
|
sleep(SUSPEND_DELAY);
|
|
|
|
|
if (virCommandRun(suspendCmd, NULL) < 0)
|
|
|
|
|
VIR_WARN("Failed to suspend the host");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now that we have resumed from suspend or the suspend failed,
|
|
|
|
|
* reset 'aboutToSuspend' flag.
|
|
|
|
|
*/
|
|
|
|
|
virNodeSuspendLock();
|
|
|
|
|
aboutToSuspend = false;
|
|
|
|
|
virNodeSuspendUnlock();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2017-03-07 09:44:06 +00:00
|
|
|
* virNodeSuspend:
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
* @conn: pointer to the hypervisor connection
|
|
|
|
|
* @target: the state to which the host must be suspended to -
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_MEM (Suspend-to-RAM),
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_DISK (Suspend-to-Disk),
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_HYBRID (Hybrid-Suspend)
|
|
|
|
|
* @duration: the time duration in seconds, for which the host must be
|
|
|
|
|
* suspended
|
|
|
|
|
* @flags: any flag values that might need to be passed; currently unused.
|
|
|
|
|
*
|
|
|
|
|
* Suspend the node (host machine) for the given duration of time in the
|
|
|
|
|
* specified state (such as Mem, Disk or Hybrid-Suspend). Attempt to resume
|
|
|
|
|
* the node after the time duration is complete.
|
|
|
|
|
*
|
|
|
|
|
* First, an RTC alarm is set appropriately to wake up the node from its
|
|
|
|
|
* sleep state. Then the actual node suspend operation is carried out
|
|
|
|
|
* asynchronously in another thread, after a short time delay so as to
|
|
|
|
|
* give enough time for this function to return status to its caller
|
|
|
|
|
* through the connection. However this returning of status is best-effort
|
|
|
|
|
* only, and should generally happen due to the short delay but might be
|
|
|
|
|
* missed if the machine suspends first.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 in case the node is going to be suspended after a short delay,
|
|
|
|
|
* -1 if suspending the node is not supported, or if a previous suspend
|
|
|
|
|
* operation is still in progress.
|
|
|
|
|
*/
|
2017-03-07 09:44:06 +00:00
|
|
|
int virNodeSuspend(unsigned int target,
|
|
|
|
|
unsigned long long duration,
|
|
|
|
|
unsigned int flags)
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
{
|
|
|
|
|
static virThread thread;
|
2011-11-29 15:22:53 +00:00
|
|
|
const char *cmdString = NULL;
|
2011-11-29 15:20:03 +00:00
|
|
|
int ret = -1;
|
|
|
|
|
unsigned int supported;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
virCheckFlags(0, -1);
|
|
|
|
|
|
2011-11-29 15:20:03 +00:00
|
|
|
if (virNodeSuspendGetTargetMask(&supported) < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
/*
|
|
|
|
|
* Ensure that we are the only ones trying to suspend.
|
|
|
|
|
* Fail if somebody has already initiated a suspend.
|
|
|
|
|
*/
|
|
|
|
|
virNodeSuspendLock();
|
|
|
|
|
|
|
|
|
|
if (aboutToSuspend) {
|
|
|
|
|
/* A suspend operation is already in progress */
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_OPERATION_INVALID, "%s",
|
|
|
|
|
_("Suspend operation already in progress"));
|
2011-11-29 15:20:03 +00:00
|
|
|
goto cleanup;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check if the host supports the requested suspend target */
|
|
|
|
|
switch (target) {
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_MEM:
|
2011-11-29 15:22:53 +00:00
|
|
|
if (!(supported & (1 << VIR_NODE_SUSPEND_TARGET_MEM))) {
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s", _("Suspend-to-RAM"));
|
2011-11-29 15:22:53 +00:00
|
|
|
goto cleanup;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
2011-11-29 15:22:53 +00:00
|
|
|
cmdString = "pm-suspend";
|
|
|
|
|
break;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_DISK:
|
2011-11-29 15:22:53 +00:00
|
|
|
if (!(supported & (1 << VIR_NODE_SUSPEND_TARGET_DISK))) {
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s", _("Suspend-to-Disk"));
|
2011-11-29 15:22:53 +00:00
|
|
|
goto cleanup;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
2011-11-29 15:22:53 +00:00
|
|
|
cmdString = "pm-hibernate";
|
|
|
|
|
break;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_HYBRID:
|
2011-11-29 15:22:53 +00:00
|
|
|
if (!(supported & (1 << VIR_NODE_SUSPEND_TARGET_HYBRID))) {
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s", _("Hybrid-Suspend"));
|
2011-11-29 15:22:53 +00:00
|
|
|
goto cleanup;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
2011-11-29 15:22:53 +00:00
|
|
|
cmdString = "pm-suspend-hybrid";
|
|
|
|
|
break;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
|
|
|
|
|
default:
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_INVALID_ARG, "%s", _("Invalid suspend target"));
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
goto cleanup;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Just set the RTC alarm. Don't suspend yet. */
|
|
|
|
|
if (virNodeSuspendSetNodeWakeup(duration) < 0)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
|
2020-02-14 11:20:10 +00:00
|
|
|
if (virThreadCreateFull(&thread, false,
|
|
|
|
|
virNodeSuspendHelper,
|
|
|
|
|
"node-suspend",
|
|
|
|
|
false,
|
|
|
|
|
(void *)cmdString) < 0) {
|
2012-07-18 10:26:24 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
|
|
|
|
|
_("Failed to create thread to suspend the host"));
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
goto cleanup;
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-29 15:31:19 +00:00
|
|
|
aboutToSuspend = true;
|
2011-11-29 15:20:03 +00:00
|
|
|
ret = 0;
|
2014-03-25 06:53:22 +00:00
|
|
|
cleanup:
|
2011-11-29 15:20:03 +00:00
|
|
|
virNodeSuspendUnlock();
|
|
|
|
|
return ret;
|
Implement the core API to suspend/resume the host
Add the core functions that implement the functionality of the API.
Suspend is done by using an asynchronous mechanism so that we can return
the status to the caller before the host gets suspended. This asynchronous
operation is achieved by suspending the host in a separate thread of
execution. However, returning the status to the caller is only best-effort,
but not guaranteed.
To resume the host, an RTC alarm is set up (based on how long we want to
suspend) before suspending the host. When this alarm fires, the host
gets woken up.
Suspend-to-RAM operation on a host running Linux can take upto more than 20
seconds, depending on the load of the system. (Freezing of tasks, an operation
preceding any suspend operation, is given up after a 20 second timeout).
And Suspend-to-Disk can take even more time, considering the time required
for compaction, creating the memory image and writing it to disk etc.
So, we do not allow the user to specify a suspend duration of less than 60
seconds, to be on the safer side, since we don't want to prematurely declare
failure when we only had to wait for some more time.
2011-11-29 09:07:38 +00:00
|
|
|
}
|
2011-11-29 14:42:58 +00:00
|
|
|
|
2014-04-11 07:20:48 +00:00
|
|
|
#ifdef WITH_PM_UTILS
|
2011-11-29 14:42:58 +00:00
|
|
|
static int
|
2014-04-11 07:20:48 +00:00
|
|
|
virNodeSuspendSupportsTargetPMUtils(unsigned int target, bool *supported)
|
2011-11-29 14:42:58 +00:00
|
|
|
{
|
2019-10-15 12:47:50 +00:00
|
|
|
g_autoptr(virCommand) cmd = NULL;
|
2019-10-15 13:16:31 +00:00
|
|
|
g_autofree char *binary = NULL;
|
2011-11-29 14:42:58 +00:00
|
|
|
int status;
|
|
|
|
|
|
|
|
|
|
*supported = false;
|
|
|
|
|
|
2019-08-13 15:21:53 +00:00
|
|
|
binary = virFindFileInPath("pm-is-supported");
|
|
|
|
|
if (!binary)
|
|
|
|
|
return -2;
|
|
|
|
|
|
2011-11-29 14:42:58 +00:00
|
|
|
switch (target) {
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_MEM:
|
2019-08-13 15:18:37 +00:00
|
|
|
cmd = virCommandNewArgList(binary, "--suspend", NULL);
|
2011-11-29 14:42:58 +00:00
|
|
|
break;
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_DISK:
|
2019-08-13 15:18:37 +00:00
|
|
|
cmd = virCommandNewArgList(binary, "--hibernate", NULL);
|
2011-11-29 14:42:58 +00:00
|
|
|
break;
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_HYBRID:
|
2019-08-13 15:18:37 +00:00
|
|
|
cmd = virCommandNewArgList(binary, "--suspend-hybrid", NULL);
|
2011-11-29 14:42:58 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
2019-08-13 15:16:26 +00:00
|
|
|
return -1;
|
2011-11-29 14:42:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (virCommandRun(cmd, &status) < 0)
|
2019-08-13 15:16:26 +00:00
|
|
|
return -1;
|
2011-11-29 14:42:58 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check return code of command == 0 for success
|
|
|
|
|
* (i.e., the PM capability is supported)
|
|
|
|
|
*/
|
|
|
|
|
*supported = (status == 0);
|
|
|
|
|
|
2019-08-13 15:16:26 +00:00
|
|
|
return 0;
|
2011-11-29 14:42:58 +00:00
|
|
|
}
|
2014-04-14 08:50:42 +00:00
|
|
|
#else /* ! WITH_PM_UTILS */
|
|
|
|
|
static int
|
2019-10-14 12:45:33 +00:00
|
|
|
virNodeSuspendSupportsTargetPMUtils(unsigned int target G_GNUC_UNUSED,
|
|
|
|
|
bool *supported G_GNUC_UNUSED)
|
2014-04-14 08:50:42 +00:00
|
|
|
{
|
|
|
|
|
return -2;
|
|
|
|
|
}
|
|
|
|
|
#endif /* ! WITH_PM_UTILS */
|
2014-04-11 07:20:48 +00:00
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
virNodeSuspendSupportsTargetSystemd(unsigned int target, bool *supported)
|
|
|
|
|
{
|
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
|
|
*supported = false;
|
|
|
|
|
|
|
|
|
|
switch (target) {
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_MEM:
|
|
|
|
|
ret = virSystemdCanSuspend(supported);
|
|
|
|
|
break;
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_DISK:
|
|
|
|
|
ret = virSystemdCanHibernate(supported);
|
|
|
|
|
break;
|
|
|
|
|
case VIR_NODE_SUSPEND_TARGET_HYBRID:
|
|
|
|
|
ret = virSystemdCanHybridSleep(supported);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* virNodeSuspendSupportsTarget:
|
|
|
|
|
* @target: The power management target to check whether it is supported
|
|
|
|
|
* by the host. Values could be:
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_MEM
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_DISK
|
|
|
|
|
* VIR_NODE_SUSPEND_TARGET_HYBRID
|
|
|
|
|
* @supported: set to true if supported, false otherwise
|
|
|
|
|
*
|
|
|
|
|
* Run the script 'pm-is-supported' (from the pm-utils package)
|
|
|
|
|
* to find out if @target is supported by the host.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 if the query was successful, -1 on failure.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
virNodeSuspendSupportsTarget(unsigned int target, bool *supported)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
ret = virNodeSuspendSupportsTargetSystemd(target, supported);
|
2014-04-14 08:50:42 +00:00
|
|
|
|
|
|
|
|
/* If just unavailable, try other options */
|
|
|
|
|
if (ret == -2)
|
2014-04-11 07:20:48 +00:00
|
|
|
ret = virNodeSuspendSupportsTargetPMUtils(target, supported);
|
2014-04-14 08:50:42 +00:00
|
|
|
|
2019-05-23 15:55:22 +00:00
|
|
|
/* If still unavailable, then report unsupported */
|
2014-04-14 08:50:42 +00:00
|
|
|
if (ret == -2) {
|
2019-05-23 15:55:22 +00:00
|
|
|
*supported = false;
|
|
|
|
|
ret = 0;
|
2014-04-14 08:50:42 +00:00
|
|
|
}
|
2014-04-11 07:20:48 +00:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2011-11-29 14:42:58 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* virNodeSuspendGetTargetMask:
|
|
|
|
|
*
|
|
|
|
|
* Get the Power Management Capabilities that the host system supports,
|
|
|
|
|
* such as Suspend-to-RAM (S3), Suspend-to-Disk (S4) and Hybrid-Suspend
|
|
|
|
|
* (a combination of S3 and S4).
|
|
|
|
|
*
|
|
|
|
|
* @bitmask: Pointer to the bitmask which will be set appropriately to
|
|
|
|
|
* indicate all the supported host power management targets.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 if the query was successful, -1 on failure.
|
|
|
|
|
*/
|
|
|
|
|
int
|
|
|
|
|
virNodeSuspendGetTargetMask(unsigned int *bitmask)
|
|
|
|
|
{
|
2011-11-29 15:20:03 +00:00
|
|
|
int ret = -1;
|
2011-11-29 14:42:58 +00:00
|
|
|
|
|
|
|
|
*bitmask = 0;
|
|
|
|
|
|
2011-11-29 15:20:03 +00:00
|
|
|
virNodeSuspendLock();
|
|
|
|
|
/* Get the power management capabilities supported by the host */
|
|
|
|
|
if (!nodeSuspendTargetMaskInit) {
|
|
|
|
|
bool supported;
|
|
|
|
|
nodeSuspendTargetMask = 0;
|
|
|
|
|
|
|
|
|
|
/* Check support for Suspend-to-RAM (S3) */
|
|
|
|
|
if (virNodeSuspendSupportsTarget(VIR_NODE_SUSPEND_TARGET_MEM, &supported) < 0)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
if (supported)
|
|
|
|
|
nodeSuspendTargetMask |= (1 << VIR_NODE_SUSPEND_TARGET_MEM);
|
|
|
|
|
|
|
|
|
|
/* Check support for Suspend-to-Disk (S4) */
|
|
|
|
|
if (virNodeSuspendSupportsTarget(VIR_NODE_SUSPEND_TARGET_DISK, &supported) < 0)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
if (supported)
|
|
|
|
|
nodeSuspendTargetMask |= (1 << VIR_NODE_SUSPEND_TARGET_DISK);
|
|
|
|
|
|
|
|
|
|
/* Check support for Hybrid-Suspend */
|
|
|
|
|
if (virNodeSuspendSupportsTarget(VIR_NODE_SUSPEND_TARGET_HYBRID, &supported) < 0)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
if (supported)
|
|
|
|
|
nodeSuspendTargetMask |= (1 << VIR_NODE_SUSPEND_TARGET_HYBRID);
|
|
|
|
|
|
|
|
|
|
nodeSuspendTargetMaskInit = true;
|
|
|
|
|
}
|
2011-11-29 14:50:04 +00:00
|
|
|
|
2011-11-29 15:20:03 +00:00
|
|
|
*bitmask = nodeSuspendTargetMask;
|
|
|
|
|
ret = 0;
|
2014-03-25 06:53:22 +00:00
|
|
|
cleanup:
|
2011-11-29 15:20:03 +00:00
|
|
|
virNodeSuspendUnlock();
|
|
|
|
|
return ret;
|
2011-11-29 14:42:58 +00:00
|
|
|
}
|
