[ovirt-devel] OVF_STORE volumes are not updated

[Christopher Pereira]

Yes.

On 14-10-2015 8:48, Allon Mureinik wrote:
> This is what we discussed on BZ#1268842, right?
>
> On Mon, Oct 5, 2015 at 11:35 AM, Christopher Pereira 
> <kripper at imatronix.cl <mailto:kripper at imatronix.cl>> wrote:
>
>     Hi,
>
>     I noticed that OVF_STORE volumes are not generated periodically as
>     expected [1].
>     It seems like the OVF_STORE volumes are only generated when the
>     Storage Domain is detached from Engine, which is not feasible if
>     we want to keep the VMs running.
>
>     1) Is there any way to force the OVF_STORE volume creation without
>     detaching the Storage Domain?
>
>     This would be very usefull for disaster recovery, since Storage
>     Domains can be backed up and VM can be reimported.
>     But if the OVF_STORE volumes are not updated, critical information
>     like the ID of the VM active snapshot will get lost.
>     If the VM is restored with a previous snapshot (not the last one),
>     all information written after the last snapshot known by the
>     OVF_STORE will get lost.
>
>     2) On the other hand, the only way I know to re-read the OVF_STORE
>     content with the VM information contained in a Storage Domain, is
>     by detaching and re-attaching it.
>     I wonder if there is also any way to re-read the OVF_STORE?
>
>     [1] : This can be verified very easily by changing a running VM
>     properties (change its name or create a snapshot), copying the
>     whole storage domain and importing it into another Engine
>     (POOL_UID and CHECKSUM must be removed from metadata in order to
>     be able to attach to another Datacenter).
>
>     PS: I'm on 3.6 RC. 1.
>     _______________________________________________
>     Devel mailing list
>     Devel at ovirt.org <mailto:Devel at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/devel
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20151014/0cf6aa33/attachment-0001.html>