[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1638#comment-1638 ] ASF GitHub Bot commented on CLOUDSTACK-10246: - DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix Host HA and VM HA issues URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171785409 ## File path: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java ## @@ -2587,7 +2589,13 @@ public boolean postStateTransitionEvent(final StateMachine2.Transition VM HA issues > > > Key: CLOUDSTACK-10246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: My setup is CentOS 7 Management server with 3 CentOS 7 > KVM HVs, NFS as primary and secondary storages. >Reporter: Nux >Priority: Major > > VM HA fails to kick in when one of the hypervisors goes down. > It even fails to restart the system VMs which remain down along with the > instances until the affected HV comes back online. > When I crash or power off the HV the system marks it in the hosts list as > "Alert" or "Disconnected" respectively. It should get changed to "Down" after > that, but this never happens. > > I have tried various combinations of setups (Adv, Basic), none succeeded. > > My instances use HA enabled offerings. > Management server DEBUG logs here: > [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt] > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383336#comment-16383336
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix
Host HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171784055
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Review comment:
👍 good improvement, but though it is only (a comment and) a log statement,
this entails an interface of the system. the ecosystem may query logs for the
text and no longer find the hostId thus not being able to take mitigating
actions any more. I'd rather see a less destructive change like 'hostId + " ("
+ hostShortDesc + ") "'
We may get away with it but it does require extensive testing by the whole
community :/.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> VM HA issues
>
>
> Key: CLOUDSTACK-10246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
> Environment: My setup is CentOS 7 Management server with 3 CentOS 7
> KVM HVs, NFS as primary and secondary storages.
>Reporter: Nux
>Priority: Major
>
> VM HA fails to kick in when one of the hypervisors goes down.
> It even fails to restart the system VMs which remain down along with the
> instances until the affected HV comes back online.
> When I crash or power off the HV the system marks it in the hosts list as
> "Alert" or "Disconnected" respectively. It should get changed to "Down" after
> that, but this never happens.
>
> I have tried various combinations of setups (Adv, Basic), none succeeded.
>
> My instances use HA enabled offerings.
> Management server DEBUG logs here:
> [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt]
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383332#comment-16383332
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix
Host HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171784702
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Status determinedState = investigate(attache);
// if state cannot be determined do nothing and bail out
if (determinedState == null) {
if ((System.currentTimeMillis() >> 10) -
host.getLastPinged() > AlertWait.value()) {
-s_logger.warn("Agent " + hostId + " state cannot be
determined for more than " + AlertWait + "(" + AlertWait.value() + ") seconds,
will go to Alert state");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined for more than " + AlertWait + "(" + AlertWait.value() + ")
seconds, will go to Alert state");
determinedState = Status.Alert;
} else {
-s_logger.warn("Agent " + hostId + " state cannot be
determined, do nothing");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined, doing nothing");
return false;
}
}
final Status currentStatus = host.getStatus();
-s_logger.info("The agent from host " + hostId + " state
determined is " + determinedState);
+s_logger.info("Status for " + hostShortDesc + " was " +
currentStatus + ". Investigation determined the current state is " +
determinedState);
-if (determinedState == Status.Down) {
-final String message = "Host is down: " + host.getId() +
"-" + host.getName() + ". Starting HA on the VMs";
-s_logger.error(message);
-if (host.getType() != Host.Type.SecondaryStorage &&
host.getType() != Host.Type.ConsoleProxy) {
-
_alertMgr.sendAlert(AlertManager.AlertType.ALERT_TYPE_HOST,
host.getDataCenterId(), host.getPodId(), "Host down, " + host.getId(), message);
-}
-event = Status.Event.HostDown;
-} else if (determinedState == Status.Up) {
-/* Got ping response from host, bring it back */
-s_logger.info("Agent is determined to be up and running");
+if (determinedState == Status.Up) {
+// Got ping response from host, bring it back
+s_logger.info(hostShortDesc + " is up again");
agentStatusTransitTo(host, Status.Event.Ping, _nodeId);
-return false;
} else if (determinedState == Status.Disconnected) {
-s_logger.warn("Agent is disconnected but t
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383335#comment-16383335
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix
Host HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171784246
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Status determinedState = investigate(attache);
// if state cannot be determined do nothing and bail out
if (determinedState == null) {
if ((System.currentTimeMillis() >> 10) -
host.getLastPinged() > AlertWait.value()) {
-s_logger.warn("Agent " + hostId + " state cannot be
determined for more than " + AlertWait + "(" + AlertWait.value() + ") seconds,
will go to Alert state");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined for more than " + AlertWait + "(" + AlertWait.value() + ")
seconds, will go to Alert state");
determinedState = Status.Alert;
} else {
-s_logger.warn("Agent " + hostId + " state cannot be
determined, do nothing");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined, doing nothing");
return false;
}
}
final Status currentStatus = host.getStatus();
-s_logger.info("The agent from host " + hostId + " state
determined is " + determinedState);
+s_logger.info("Status for " + hostShortDesc + " was " +
currentStatus + ". Investigation determined the current state is " +
determinedState);
-if (determinedState == Status.Down) {
-final String message = "Host is down: " + host.getId() +
"-" + host.getName() + ". Starting HA on the VMs";
-s_logger.error(message);
-if (host.getType() != Host.Type.SecondaryStorage &&
host.getType() != Host.Type.ConsoleProxy) {
-
_alertMgr.sendAlert(AlertManager.AlertType.ALERT_TYPE_HOST,
host.getDataCenterId(), host.getPodId(), "Host down, " + host.getId(), message);
-}
-event = Status.Event.HostDown;
-} else if (determinedState == Status.Up) {
-/* Got ping response from host, bring it back */
-s_logger.info("Agent is determined to be up and running");
+if (determinedState == Status.Up) {
+// Got ping response from host, bring it back
+s_logger.info(hostShortDesc + " is up again");
agentStatusTransitTo(host, Status.Event.Ping, _nodeId);
-return false;
} else if (determinedState == Status.Disconnected) {
-s_logger.warn("Agent is disconnected but t
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383331#comment-16383331
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix
Host HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171784133
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Status determinedState = investigate(attache);
// if state cannot be determined do nothing and bail out
if (determinedState == null) {
if ((System.currentTimeMillis() >> 10) -
host.getLastPinged() > AlertWait.value()) {
-s_logger.warn("Agent " + hostId + " state cannot be
determined for more than " + AlertWait + "(" + AlertWait.value() + ") seconds,
will go to Alert state");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined for more than " + AlertWait + "(" + AlertWait.value() + ")
seconds, will go to Alert state");
Review comment:
for warn message the above is even more true
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> VM HA issues
>
>
> Key: CLOUDSTACK-10246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
> Environment: My setup is CentOS 7 Management server with 3 CentOS 7
> KVM HVs, NFS as primary and secondary storages.
>Reporter: Nux
>Priority: Major
>
> VM HA fails to kick in when one of the hypervisors goes down.
> It even fails to restart the system VMs which remain down along with the
> instances until the affected HV comes back online.
> When I crash or power off the HV the system marks it in the hosts list as
> "Alert" or "Disconnected" respectively. It should get changed to "Down" after
> that, but this never happens.
>
> I have tried various combinations of setups (Adv, Basic), none succeeded.
>
> My instances use HA enabled offerings.
> Management server DEBUG logs here:
> [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt]
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383334#comment-16383334 ] ASF GitHub Bot commented on CLOUDSTACK-10246: - DaanHoogland commented on a change in pull request #2474: CLOUDSTACK-10246 Fix Host HA and VM HA issues URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171785154 ## File path: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java ## @@ -340,6 +340,7 @@ private ScheduledExecutorService _executor; private ScheduledExecutorService _checkExecutor; private ScheduledExecutorService _networkStatsUpdateExecutor; +private ExecutorService _routerOobStartExecutor; Review comment: we are trying to get rid of these _'s . no need to adhere to this old convention. In fact you may want to rename the others as well (in a separate commit for review ease) (this is not a request for change, just a suggestion) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > VM HA issues > > > Key: CLOUDSTACK-10246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: My setup is CentOS 7 Management server with 3 CentOS 7 > KVM HVs, NFS as primary and secondary storages. >Reporter: Nux >Priority: Major > > VM HA fails to kick in when one of the hypervisors goes down. > It even fails to restart the system VMs which remain down along with the > instances until the affected HV comes back online. > When I crash or power off the HV the system marks it in the hosts list as > "Alert" or "Disconnected" respectively. It should get changed to "Down" after > that, but this never happens. > > I have tried various combinations of setups (Adv, Basic), none succeeded. > > My instances use HA enabled offerings. > Management server DEBUG logs here: > [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt] > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383357#comment-16383357
]
ASF GitHub Bot commented on CLOUDSTACK-10309:
-
DaanHoogland commented on a change in pull request #2473: CLOUDSTACK-10309 Add
option on if to VM HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#discussion_r171790758
##
File path: engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -359,6 +359,9 @@ public void setHostAllocators(final List
hostAllocators) {
Integer.class, "vm.job.report.interval", "60",
"Interval to send application level pings to make sure the
connection is still working", false);
+static final ConfigKey HaVmRestartHostUp = new
ConfigKey("Advanced", Boolean.class, "ha.vm.restart.hostup", "true",
Review comment:
I would expect to see the new ConfigKey be added to the return of
getConfigKeys()
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> VMs with HA enabled, power back on if shutdown from guest OS
>
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the
> VM just powers itself back on. Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't
> pay for VMs when they are shutoff. It is not intuitive for end-users to
> understand why they can't shutdown VMs from within the guest OS. Especially
> when they all come from (non-cloudstack) VMware and Hyper-V environments
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option
> "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then
> it won't power it back on. The logic is that since the host is online, it
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current
> functionality), it works like always, and even in-guest shutdowns of VMs
> causes CloudStack to power back on the VM.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383358#comment-16383358
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
Slair1 commented on a change in pull request #2474: CLOUDSTACK-10246 Fix Host
HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171790992
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Review comment:
@DaanHoogland good thought, I didn’t think about that. However, the
hostShortDesc does include the hostId as part of it. So maybe it’s ok?
final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> VM HA issues
>
>
> Key: CLOUDSTACK-10246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.11.0.0
> Environment: My setup is CentOS 7 Management server with 3 CentOS 7
> KVM HVs, NFS as primary and secondary storages.
>Reporter: Nux
>Priority: Major
>
> VM HA fails to kick in when one of the hypervisors goes down.
> It even fails to restart the system VMs which remain down along with the
> instances until the affected HV comes back online.
> When I crash or power off the HV the system marks it in the hosts list as
> "Alert" or "Disconnected" respectively. It should get changed to "Down" after
> that, but this never happens.
>
> I have tried various combinations of setups (Adv, Basic), none succeeded.
>
> My instances use HA enabled offerings.
> Management server DEBUG logs here:
> [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt]
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383364#comment-16383364
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
Slair1 commented on a change in pull request #2474: CLOUDSTACK-10246 Fix Host
HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171791683
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Status determinedState = investigate(attache);
// if state cannot be determined do nothing and bail out
if (determinedState == null) {
if ((System.currentTimeMillis() >> 10) -
host.getLastPinged() > AlertWait.value()) {
-s_logger.warn("Agent " + hostId + " state cannot be
determined for more than " + AlertWait + "(" + AlertWait.value() + ") seconds,
will go to Alert state");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined for more than " + AlertWait + "(" + AlertWait.value() + ")
seconds, will go to Alert state");
determinedState = Status.Alert;
} else {
-s_logger.warn("Agent " + hostId + " state cannot be
determined, do nothing");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined, doing nothing");
return false;
}
}
final Status currentStatus = host.getStatus();
-s_logger.info("The agent from host " + hostId + " state
determined is " + determinedState);
+s_logger.info("Status for " + hostShortDesc + " was " +
currentStatus + ". Investigation determined the current state is " +
determinedState);
-if (determinedState == Status.Down) {
-final String message = "Host is down: " + host.getId() +
"-" + host.getName() + ". Starting HA on the VMs";
-s_logger.error(message);
-if (host.getType() != Host.Type.SecondaryStorage &&
host.getType() != Host.Type.ConsoleProxy) {
-
_alertMgr.sendAlert(AlertManager.AlertType.ALERT_TYPE_HOST,
host.getDataCenterId(), host.getPodId(), "Host down, " + host.getId(), message);
-}
-event = Status.Event.HostDown;
-} else if (determinedState == Status.Up) {
-/* Got ping response from host, bring it back */
-s_logger.info("Agent is determined to be up and running");
+if (determinedState == Status.Up) {
+// Got ping response from host, bring it back
+s_logger.info(hostShortDesc + " is up again");
agentStatusTransitTo(host, Status.Event.Ping, _nodeId);
-return false;
} else if (determinedState == Status.Disconnected) {
-s_logger.warn("Agent is disconnected but the hos
[jira] [Commented] (CLOUDSTACK-10246) VM HA issues
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383366#comment-16383366
]
ASF GitHub Bot commented on CLOUDSTACK-10246:
-
Slair1 commented on a change in pull request #2474: CLOUDSTACK-10246 Fix Host
HA and VM HA issues
URL: https://github.com/apache/cloudstack/pull/2474#discussion_r171791837
##
File path:
engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -843,72 +846,103 @@ protected boolean
handleDisconnectWithInvestigation(final AgentAttache attache,
s_logger.debug("Caught exception while getting agent's next
status", ne);
}
+// For log and alert purposes later
+final DataCenterVO dcVO = _dcDao.findById(host.getDataCenterId());
+final HostPodVO podVO = _podDao.findById(host.getPodId());
+final String hostDesc = "[name: " + host.getName() + " (id:" +
host.getId() + "), availability zone: " + dcVO.getName() + ", pod: " +
podVO.getName() + "]";
+final String hostShortDesc = "Host " + host.getName() + " (id:" +
host.getId() + ")";
+
+final ResourceState resourceState = host.getResourceState();
+if (resourceState == ResourceState.Disabled || resourceState ==
ResourceState.Maintenance || resourceState == ResourceState.ErrorInMaintenance)
{
+// If we are in this resourceState, no need to investigate or
do anything. AgentMonitor will handle when in these resourceStates
+s_logger.info(hostShortDesc + " has disconnected with event "
+ event + ", but is in Resource State of " + resourceState + ", so doing
nothing");
+return true;
+}
+
if (nextStatus == Status.Alert) {
-/* OK, we are going to the bad status, let's see what happened
*/
-s_logger.info("Investigating why host " + hostId + " has
disconnected with event " + event);
+/* Our next Agent transition state is Alert
+ * Let's see if the host down or why we had this event
+ */
+s_logger.info("Investigating why host " + hostShortDesc + "
has disconnected with event " + event);
Status determinedState = investigate(attache);
// if state cannot be determined do nothing and bail out
if (determinedState == null) {
if ((System.currentTimeMillis() >> 10) -
host.getLastPinged() > AlertWait.value()) {
-s_logger.warn("Agent " + hostId + " state cannot be
determined for more than " + AlertWait + "(" + AlertWait.value() + ") seconds,
will go to Alert state");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined for more than " + AlertWait + "(" + AlertWait.value() + ")
seconds, will go to Alert state");
determinedState = Status.Alert;
} else {
-s_logger.warn("Agent " + hostId + " state cannot be
determined, do nothing");
+s_logger.warn("State for " + hostShortDesc + " could
not be determined, doing nothing");
return false;
}
}
final Status currentStatus = host.getStatus();
-s_logger.info("The agent from host " + hostId + " state
determined is " + determinedState);
+s_logger.info("Status for " + hostShortDesc + " was " +
currentStatus + ". Investigation determined the current state is " +
determinedState);
-if (determinedState == Status.Down) {
-final String message = "Host is down: " + host.getId() +
"-" + host.getName() + ". Starting HA on the VMs";
-s_logger.error(message);
-if (host.getType() != Host.Type.SecondaryStorage &&
host.getType() != Host.Type.ConsoleProxy) {
-
_alertMgr.sendAlert(AlertManager.AlertType.ALERT_TYPE_HOST,
host.getDataCenterId(), host.getPodId(), "Host down, " + host.getId(), message);
-}
-event = Status.Event.HostDown;
-} else if (determinedState == Status.Up) {
-/* Got ping response from host, bring it back */
-s_logger.info("Agent is determined to be up and running");
+if (determinedState == Status.Up) {
+// Got ping response from host, bring it back
+s_logger.info(hostShortDesc + " is up again");
agentStatusTransitTo(host, Status.Event.Ping, _nodeId);
-return false;
} else if (determinedState == Status.Disconnected) {
-s_logger.warn("Agent is disconnected but the hos
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383368#comment-16383368
]
ASF GitHub Bot commented on CLOUDSTACK-10309:
-
Slair1 commented on a change in pull request #2473: CLOUDSTACK-10309 Add option
on if to VM HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#discussion_r171792251
##
File path: engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -359,6 +359,9 @@ public void setHostAllocators(final List
hostAllocators) {
Integer.class, "vm.job.report.interval", "60",
"Interval to send application level pings to make sure the
connection is still working", false);
+static final ConfigKey HaVmRestartHostUp = new
ConfigKey("Advanced", Boolean.class, "ha.vm.restart.hostup", "true",
Review comment:
Agreed, not sure how that got missed here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> VMs with HA enabled, power back on if shutdown from guest OS
>
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the
> VM just powers itself back on. Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't
> pay for VMs when they are shutoff. It is not intuitive for end-users to
> understand why they can't shutdown VMs from within the guest OS. Especially
> when they all come from (non-cloudstack) VMware and Hyper-V environments
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option
> "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then
> it won't power it back on. The logic is that since the host is online, it
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current
> functionality), it works like always, and even in-guest shutdowns of VMs
> causes CloudStack to power back on the VM.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10257) Create template/volume does not allow to specify HVM requirement
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383472#comment-16383472
]
ASF GitHub Bot commented on CLOUDSTACK-10257:
-
rafaelweingartner closed pull request #2437: [CLOUDSTACK-10257]Create
template/volume does not allow to specify HVM requirements
URL: https://github.com/apache/cloudstack/pull/2437
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/ui/scripts/sharedFunctions.js b/ui/scripts/sharedFunctions.js
index 606fed45d27..923ab76b5bf 100644
--- a/ui/scripts/sharedFunctions.js
+++ b/ui/scripts/sharedFunctions.js
@@ -2622,3 +2622,186 @@ $.validator.addMethod("allzonesonly", function(value,
element){
},
"All Zones cannot be combined with any other zone");
+
+cloudStack.createTemplateMethod = function (isSnapshot){
+ return {
+label: 'label.create.template',
+messages: {
+confirm: function(args) {
+return 'message.create.template';
+},
+notification: function(args) {
+return 'label.create.template';
+}
+},
+createForm: {
+title: 'label.create.template',
+preFilter: cloudStack.preFilter.createTemplate,
+desc: '',
+preFilter: function(args) {
+if (args.context.volumes[0].hypervisor == "XenServer") {
+if (isAdmin()) {
+
args.$form.find('.form-item[rel=xenserverToolsVersion61plus]').css('display',
'inline-block');
+}
+}
+},
+fields: {
+name: {
+label: 'label.name',
+validation: {
+required: true
+}
+},
+displayText: {
+label: 'label.description',
+validation: {
+required: true
+}
+},
+xenserverToolsVersion61plus: {
+label: 'label.xenserver.tools.version.61.plus',
+isBoolean: true,
+isChecked: function (args) {
+var b = false;
+var vmObj;
+$.ajax({
+url: createURL("listVirtualMachines"),
+data: {
+id: args.context.volumes[0].virtualmachineid
+},
+async: false,
+success: function(json) {
+vmObj =
json.listvirtualmachinesresponse.virtualmachine[0];
+}
+});
+if (vmObj == undefined) { //e.g. VM has failed over
+if (isAdmin()) {
+$.ajax({
+url: createURL('listConfigurations'),
+data: {
+name: 'xenserver.pvdriver.version'
+},
+async: false,
+success: function (json) {
+if
(json.listconfigurationsresponse.configuration != null &&
json.listconfigurationsresponse.configuration[0].value == 'xenserver61') {
+b = true;
+}
+}
+});
+}
+} else {
+ if ('details' in vmObj &&
'hypervisortoolsversion' in vmObj.details) {
+ if (vmObj.details.hypervisortoolsversion ==
'xenserver61')
+ b = true;
+ else
+ b = false;
+ }
+}
+return b;
+},
+isHidden: true
+},
+osTypeId: {
+label: 'label.os.type',
+select: function(args) {
+$.ajax({
+url: createURL("listOsTypes"),
+dataType: "json",
+async: true,
+success: function(json) {
+var ostypes = json.listostypesresponse.ostype;
+
[jira] [Commented] (CLOUDSTACK-10257) Create template/volume does not allow to specify HVM requirement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383473#comment-16383473 ] ASF subversion and git services commented on CLOUDSTACK-10257: -- Commit 2037dc9eb3979cbefc0a1c7f8b927c8d8b53ac26 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=2037dc9 ] [CLOUDSTACK-10257]Create template/volume does not allow to specify HVM requirement (#2437) > Create template/volume does not allow to specify HVM requirement > > > Key: CLOUDSTACK-10257 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10257 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > Even when creating a template from a snapshot of a ROOT volume, which has a > PV operating system, ACS created the template with flag HVM=1, which may > cause problems to deploy the aforementioned template in environments that do > not have hosts that support HVM. When creating templates from Snapshots or > volumes an option to specify if the template that is going to be created > needs HVM or not should be presented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10257) Create template/volume does not allow to specify HVM requirement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10257. - Resolution: Fixed Fix Version/s: 4.12 > Create template/volume does not allow to specify HVM requirement > > > Key: CLOUDSTACK-10257 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10257 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > Fix For: 4.12 > > > Even when creating a template from a snapshot of a ROOT volume, which has a > PV operating system, ACS created the template with flag HVM=1, which may > cause problems to deploy the aforementioned template in environments that do > not have hosts that support HVM. When creating templates from Snapshots or > volumes an option to specify if the template that is going to be created > needs HVM or not should be presented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
Rafael Weingärtner created CLOUDSTACK-10314: --- Summary: Add Text-Field to each ACL Rule Key: CLOUDSTACK-10314 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rafael Weingärtner Assignee: Rafael Weingärtner It might be interesting to have a text field (e.g. CHAR-256) added to each ACL rule, which allows to enter a "reason" for each FW Rule created. This is valuable for customer documentation, as well as best practice for an evidence towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383493#comment-16383493 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - rafaelweingartner commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-369898631 That is a good question. For me, it is always best to start solving a bug/issue/new feature by unit tests because they cost less to run than these integration/smoke tests (this is what I have been doing so far). However, this requires a level of commitment (code has to be designed to be unit tested). Regarding revisiting tests, I would check them every-time they fail. Otherwise, there is too much for too few hands. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383518#comment-16383518 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - DaanHoogland commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-369904033 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383520#comment-16383520 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-369904227 @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383669#comment-16383669
]
ASF GitHub Bot commented on CLOUDSTACK-10268:
-
khos2ow commented on a change in pull request #2433: CLOUDSTACK-10268: Fix and
enhance package script
URL: https://github.com/apache/cloudstack/pull/2433#discussion_r171869086
##
File path: utils/src/main/java/com/cloud/maint/Version.java
##
@@ -19,59 +19,82 @@
package com.cloud.maint;
+import java.util.regex.Pattern;
+
+import org.apache.commons.lang.StringUtils;
+
public class Version {
/**
* Compares two version strings and see which one is higher version.
- * @param ver1
- * @param ver2
- * @return positive if ver1 is higher. negative if ver1 is lower; zero if
the same.
+ *
+ * @param version1
+ * @param version2
+ *
+ * @return positive if version1 is higher. negative if version2 is lower;
zero if the same.
Review comment:
sure.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains
> SNAPSHOT
> ** in the final artifacts (jar) name
> ** in the final package (rpm, deb) name
> ** in `/etc/cloudstack-release` file of SystemVMs
> ** in the Management Server > About dialog
> * if there's a "branding" string in the POM version (e.g.
> `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final
> generated pacakge name such as following:
> ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
> ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
> * branding string can be overriden with newly added `-b, --brand` flag
> * handle the new format version for VR version
> * fix long opts (they were broken)
> * tolerate and show a warning message for unrecognized flags
> * usage help reformat
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383668#comment-16383668
]
ASF GitHub Bot commented on CLOUDSTACK-10268:
-
khos2ow commented on a change in pull request #2433: CLOUDSTACK-10268: Fix and
enhance package script
URL: https://github.com/apache/cloudstack/pull/2433#discussion_r171869059
##
File path: utils/src/main/java/com/cloud/maint/Version.java
##
@@ -19,59 +19,82 @@
package com.cloud.maint;
+import java.util.regex.Pattern;
+
+import org.apache.commons.lang.StringUtils;
+
public class Version {
/**
* Compares two version strings and see which one is higher version.
- * @param ver1
- * @param ver2
- * @return positive if ver1 is higher. negative if ver1 is lower; zero if
the same.
+ *
+ * @param version1
+ * @param version2
+ *
+ * @return positive if version1 is higher. negative if version2 is lower;
zero if the same.
Review comment:
Nice finding!
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains
> SNAPSHOT
> ** in the final artifacts (jar) name
> ** in the final package (rpm, deb) name
> ** in `/etc/cloudstack-release` file of SystemVMs
> ** in the Management Server > About dialog
> * if there's a "branding" string in the POM version (e.g.
> `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final
> generated pacakge name such as following:
> ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
> ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
> * branding string can be overriden with newly added `-b, --brand` flag
> * handle the new format version for VR version
> * fix long opts (they were broken)
> * tolerate and show a warning message for unrecognized flags
> * usage help reformat
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383706#comment-16383706
]
ASF GitHub Bot commented on CLOUDSTACK-10268:
-
khos2ow commented on a change in pull request #2433: CLOUDSTACK-10268: Fix and
enhance package script
URL: https://github.com/apache/cloudstack/pull/2433#discussion_r171880742
##
File path: utils/src/main/java/com/cloud/maint/Version.java
##
@@ -19,59 +19,82 @@
package com.cloud.maint;
+import java.util.regex.Pattern;
+
+import org.apache.commons.lang.StringUtils;
+
public class Version {
/**
* Compares two version strings and see which one is higher version.
- * @param ver1
- * @param ver2
- * @return positive if ver1 is higher. negative if ver1 is lower; zero if
the same.
+ *
+ * @param version1
+ * @param version2
+ *
+ * @return positive if version1 is higher. negative if version2 is lower;
zero if the same.
Review comment:
done.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix and enhance package script
> --
>
> Key: CLOUDSTACK-10268
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Packaging
>Reporter: Khosrow Moossavi
>Priority: Minor
> Fix For: 4.12.0.0
>
>
> * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains
> SNAPSHOT
> ** in the final artifacts (jar) name
> ** in the final package (rpm, deb) name
> ** in `/etc/cloudstack-release` file of SystemVMs
> ** in the Management Server > About dialog
> * if there's a "branding" string in the POM version (e.g.
> `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final
> generated pacakge name such as following:
> ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64`
> ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb`
> * branding string can be overriden with newly added `-b, --brand` flag
> * handle the new format version for VR version
> * fix long opts (they were broken)
> * tolerate and show a warning message for unrecognized flags
> * usage help reformat
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383759#comment-16383759 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-369966282 @rhtyd @rafaelweingartner my goal in this PR was to be able to support - custom branding in POM version or provide it on the fly on CLI - concept of timestamp for SNAPSHOT versions (i.e. development cycles) in final artifacts (rpm, deb, systemvm-templates) and to achieve this I ended up modifying some files - `Version.java` for instance to correctly handle `x.y.z.a-brand-[SNAPSHOT|timestamp]` - for MS to detect if VR needs to be upgraded - shown in `/etc/cloudstack-release` - `setnextversion.sh` to add `--no-commit` flag to change the version on the fly (from SNAPSHOT to `timestamp`, if specified) in packaging script to have consistency between deb, rpm versions and ACS version itself (which is read from final jar package version) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383941#comment-16383941 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-369966282 @rhtyd @rafaelweingartner my goal in this PR was to be able to support - custom branding in POM version or provide it on the fly on CLI - concept of timestamp for SNAPSHOT versions (i.e. development cycles) in final artifacts (rpm, deb, systemvm-templates) and to achieve this I ended up modifying some files - `Version.java` to correctly handle `x.y.z.a-brand-[SNAPSHOT|timestamp]` - for MS to detect if VR needs to be upgraded - shown in `/etc/cloudstack-release` - `setnextversion.sh` to add `--no-commit` flag to change the version on the fly (from SNAPSHOT to `timestamp`, if specified) in packaging script to have consistency between deb, rpm versions and ACS version itself (which is read from final jar package version) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383943#comment-16383943 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-369966282 @rhtyd @rafaelweingartner my goal in this PR was to be able to support - custom branding in POM version or provide it on the fly on CLI - concept of timestamp for SNAPSHOT versions (i.e. development cycles) in final artifacts (rpm, deb, systemvm-templates) and to achieve this I ended up modifying some files - `Version.java` and `build.sh` to correctly handle `x.y.z.a-brand-[SNAPSHOT|timestamp]` - for MS to detect if VR needs to be upgraded - shown in `/etc/cloudstack-release` - `setnextversion.sh` to add `--no-commit` flag to change the version on the fly (from SNAPSHOT to `timestamp`, if specified) in packaging script to have consistency between deb, rpm versions and ACS version itself (which is read from final jar package version) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384123#comment-16384123 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-370045365 Trillian test result (tid-2303) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29005 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2425-t2303-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_primary_storage.py Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 60 look OK, 7 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_add_primary_storage_disabled_host | `Error` | 1.06 | test_primary_storage.py test_01_primary_storage_nfs | `Error` | 0.17 | test_primary_storage.py ContextSuite context=TestStorageTags>:setup | `Error` | 0.29 | test_primary_storage.py test_04_rvpc_privategw_static_routes | `Failure` | 346.33 | test_privategw_acl.py test_02_list_snapshots_with_removed_data_store | `Error` | 1.26 | test_snapshots.py test_08_migrate_vm | `Error` | 125.28 | test_vm_life_cycle.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 289.85 | test_vpc_redundant.py test_01_cancel_host_maintenace_with_no_migration_jobs | `Failure` | 0.19 | test_host_maintenance.py test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 3.50 | test_host_maintenance.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 3.14 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384148#comment-16384148 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - rafaelweingartner commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-370051762 Now the failures increased... :) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Shevchenko closed CLOUDSTACK-10295. -- Resolution: Fixed > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384454#comment-16384454
]
ASF GitHub Bot commented on CLOUDSTACK-10310:
-
bwsw commented on a change in pull request #2472: CLOUDSTACK-10310 Fix KVM
reboot on storage issue
URL: https://github.com/apache/cloudstack/pull/2472#discussion_r172004532
##
File path:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAMonitor.java
##
@@ -115,22 +115,33 @@ protected void runInContext() {
}
String result = null;
-for (int i = 0; i < 5; i++) {
+// Try 3 times, but sleep in between tries to ensure it
isn't a short lived transient error
+for (int i = 1; i <= 4; i++) {
Script cmd = new Script(s_heartBeatPath,
_heartBeatUpdateTimeout, s_logger);
cmd.add("-i", primaryStoragePool._poolIp);
cmd.add("-p", primaryStoragePool._poolMountSourcePath);
cmd.add("-m", primaryStoragePool._mountDestPath);
cmd.add("-h", _hostIP);
result = cmd.execute();
if (result != null) {
-s_logger.warn("write heartbeat failed: " + result
+ ", retry: " + i);
+s_logger.warn("write heartbeat failed: " + result
+ ", retry: " + i + " of 4");
Review comment:
I disabled that behaviour in our 4.3 completely.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> KVM hosts reboot if there is a short transient storage error
>
>
> Key: CLOUDSTACK-10310
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.9.0, 4.10.0.0
>Reporter: Sean Lair
>Priority: Major
>
> If the KVM heartbeat file can't be written to, the host is rebooted, and thus
> taking down all VMs running on it. The code does try 5x times before the
> reboot, but the there is not a delay between the retires, so they are 5
> simultaneous retries, which doesn't help. Standard SAN storage HA operations
> or quick network blip could cause this reboot to occur.
> Some discussions on the dev mailing list revealed that some people are just
> commenting out the reboot line in their version of the CloudStack source.
> A better option (and a new PR is being issued) would be have it sleep between
> tries so it isn't 5x almost simultaneous tries. Plus, instead of rebooting,
> the cloudstack-agent could just be stopped on the host instead. This will
> cause alerts to be issued and if the host is disconnected long-enough,
> depending on the HA code in use, VM HA could handle the host failure.
> The built-in reboot of the host seemed drastic
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
