Comment 3 for bug 711587

After a bit of testing and researching I was unable to reproduce this bug and determined that this was apparently related to bug #724470, which caused the CC to be unable to communicate to the NC. After this bug was fixed, the issues presented in this bug report were no longer seen.

However, due to the recent changes in PowerNap we need to consider various things:

When running Eucalyptus with SCHEDPOLICY=ROUNDROBIN (default), PowerNap (in each of the NC's with default configuration) should not take any action if the NC's if activity is detected, to prevent PowerNap to entering in a powersave state (or if modified to suspend/poweroff). To prevent this we should either do:

 - Do not start PowerNap by default.
 - Add a ProcessMonitor for /sbin/init so that it never detects inactivity.

If we still want to be able to use PowerNap and save power while inactive it *should* be left configured for "PowerSave" mode and:
 - Add a ProcessMonitor for kvm.

NOTE: This will prevent PowerNap for performing any actions that will take the machine offline or leaving the server in a lower power state when it shouldn't be.

When running Eucalyptus with SCHEDPOLICY=POWERSAVE, we should take even more special considerations. If the action method is to suspend/poweroff, then PowerNap should:

 - Add a ProcessMonitor for /sbin/init

If the action method in this case is PowerSave, then the following should be considered:

 - Add ProcessMonitor for kvm
 - Set ABSENT_SECONDS (powernap) equal or higher to IDLESECONDS (eucalyptus)

NOTE: This considerations will ensure that Eucalyptus takes control of the process of taking machines online/offline rather than leaving PowerNap to do by itself when it probably shouldn't.

Before marking this bug invalid, I'd like someone to post opinions/comments or even better solutions/considerations.