We have the sheduled actions, as you know this feature triggers actions on an specific date. We could extend these actions to be triggered on states (i.e. triggered by the scheduler). This, compared with hooks (you can program actions on given states), allow you to set the actions per VM. Also users could access this feature, and no modification of oned.conf is requires.<div><br></div><div>Does it make sense? </div><div><br></div><div>Cheers<br><br><div class="gmail_quote">On Tue Oct 14 2014 at 5:20:35 PM Stefan Kooman <<a href="mailto:stefan@bit.nl">stefan@bit.nl</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Ruben S. Montero (<a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a>):<br>
> Hi<br>
><br>
> These two are on our radar and probably scheduled for the next release. I<br>
> totally agree that we need to simplify the provision process even more.<br>
><br>
> About feature 1.<br>
><br>
> We have two issues:<br>
><br>
> [1] Clone a running VM. <a href="http://dev.opennebula.org/issues/2637" target="_blank">http://dev.opennebula.org/<u></u>issues/2637</a><br>
> [2] Clone a template . <a href="http://dev.opennebula.org/issues/2051" target="_blank">http://dev.opennebula.org/<u></u>issues/2051</a><br>
><br>
> Last one includes images (pretty much the procedure outlined by Anandharaj<br>
> under "New VM request") and I think this will cover exactly your request.<br>
><br>
> About feature 2.<br>
><br>
> We want to add the ability to update any part of a template for VM, most of<br>
> it can be done if the VM is running (eg. attach a new disk or nic). Others<br>
> like memory can be resized when the VM is powered off. You would not need<br>
> to update and recreate the template.<br>
><br>
> [3] <a href="http://dev.opennebula.org/issues/2065" target="_blank">http://dev.opennebula.org/<u></u>issues/2065</a><br>
<br>
It would be nice if some actions could be "suspended" until the desired<br>
state has been reached. This would give you the possibility to perform<br>
for example resize actions (change (v)CPU, RAM, etc.) and have them<br>
be applied later, after the VM changes state: running -> poweroff -><br>
running. Similar to the "Some changes may require a guest shutdown to<br>
take effect." message of "virt-manager". You can then schedule a<br>
power cycle to have the VM resized when convenient (midnight for<br>
example). Sure you could script this as (one)admin but for an end user<br>
this is more convenient.<br>
<br>
Gr. Stefan<br>
<br>
--<br>
| BIT BV  <a href="http://www.bit.nl/" target="_blank">http://www.bit.nl/</a>        Kamer van Koophandel 09090351<br>
| GPG: 0xD14839C6                   +31 318 648 688 / <a href="mailto:info@bit.nl" target="_blank">info@bit.nl</a><br>
</blockquote></div></div>