This is now fixed for the next release. The snapshot will be reused, the
only potential problem is that reusing the same volume with old images
from a previous installation, may lead to inconsistent copies. This is an
anomalous situation, and reusing the snapshot is probably faster and safer.
Hi Fabian,
In OpenNebula 4.10 if the VM is in UNKNOWN it should go directly to boot
(bypassing CLEANUP and PROLOG) , provided you are using shared storage...
Cheers
Ruben
On Fri Dec 12 2014 at 4:16:11 AM Fabian Zimmermann dev@gmail.com
wrote:
Hi,
I just setup our fencing system and
Totally, tm-ceph should work in this case... The issue for this:
http://dev.opennebula.org/issues/3446
THANKS your feedback!!!
Ruben
On Fri Dec 12 2014 at 1:15:38 PM Fabian Zimmermann dev@gmail.com
wrote:
Hi,
Am 12.12.14 13:04, schrieb Ruben S. Montero:
If you have shared storage,
Hi Ruben,
Am 12.12.14 11:20, schrieb Ruben S. Montero:
In OpenNebula 4.10 if the VM is in UNKNOWN it should go directly to boot
(bypassing CLEANUP and PROLOG) , provided you are using shared storage...
we are using 4.10.1 and it looks like CLEANUP is executed isn't it?
--
Wed Dec 10 16:38:45
Hi Fabian,
If you have shared storage, you can simply issue onevm resched (I think the
hook can do that with the -m option).
If there is no shared storage then you have to go through the
delete-recreate step, that will fail for the host as it is down. The host
should be cleaned up manually
On Fri, 12 Dec 2014 04:15:34 -0800, Fabian Zimmermann dev@gmail.com
wrote:
Hi,
Ah! Thanks I just misread the oned.conf
Nevertheless, I used -r and assumed it would re-create the VM, but
this failed if you use (ceph) shared storage, because clone will abort
if previous cleanup failed, so
Hi,
I just setup our fencing system and everything is working so far, but if
I use the HOST-ERROR-Hook to deleterecreate the VMs this will fail.
The CLEANUP is tried on the broken host - of course it will fail - and
the followed CLONE will fail, because of already existing snapshots/disks.
I
