<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk <<a href="mailto:mlipchuk@redhat.com" target="_blank">mlipchuk@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>> wrote:<br>
> On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>> wrote:<br>
>><br>
>> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler <<a href="mailto:ckozleriii@gmail.com" target="_blank">ckozleriii@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> I recently read on this list from a redhat member that export domain is<br>
>>> either being deprecated or looking at being deprecated<br>
><br>
><br>
> We want to deprecate the export domain, but it is not deprecated yet.<br>
><br>
>>><br>
>>><br>
>>> To that end, can you share details? Can you share any notes/postings/bz's<br>
>>> that document this? I would imagine something like this would be discussed<br>
>>> in larger audience<br>
><br>
><br>
> I agree.<br>
><br>
>>><br>
>>><br>
>>> This seems like a somewhat significant change to make and I am curious<br>
>>> where this is scheduled? Currently, a lot of my backups rely explicitly on<br>
>>> an export domain for online snapshots, so I'd like to plan accordingly<br>
><br>
><br>
> Can you describe how you backup your vms using export domain?<br>
> What do you mean by online snapshots?<br>
><br>
>><br>
>><br>
>> We believe that the ability to detach and attach a data domain provides<br>
>> equivalent and even superior functionality to the export domain. Is there<br>
>> anything you'd miss? I don't believe it would be a significant change.<br>
><br>
><br>
> Attaching and detaching data domain was not designed for backing up vms.<br>
> How would you use it for backup?<br>
><br>
> How do you ensure that a backup clone of a vm is not started by mistake,<br>
> changing the backup contents?<br>
<br>
That is a good question.<br>
We recently introduced a new feature called "backup storage domain"<br>
which you can mark the storage domain as backup storage domain.<br>
That can guarantee that no VMs will run with disks/leases reside on<br>
the storage domain.<br></blockquote><div><br></div></div></div><div>How older systems will handle the backup domain, when they do not</div><div>know about backup domains?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The feature should already exist in oVirt 4.2 (despite a bug that<br>
should be handled with this patch <a href="https://gerrit.ovirt.org/#/c/81290/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>81290/</a>)<br>
You can find more information on this here:<br>
<a href="https://github.com/shubham0d/ovirt-site/blob/41dcb0f1791d90d1ae0ac43cd34a399cfedf54d8/source/develop/release-management/features/storage/backup-storage-domain.html.md" rel="noreferrer" target="_blank">https://github.com/shubham0d/<wbr>ovirt-site/blob/<wbr>41dcb0f1791d90d1ae0ac43cd34a39<wbr>9cfedf54d8/source/develop/<wbr>release-management/features/<wbr>storage/backup-storage-domain.<wbr>html.md</a><br>
<br>
Basically the OVF that is being saved in the export domain should be<br>
similar to the same one that is being saved in the OVF_STORE disk in<br>
the storage domain.<br></blockquote><div> </div></span><div>There is no guarantee that the OVF_STORE will contain the vm xml after</div><div>the domain is detached.</div></div></div></blockquote><div><br></div><div>I believe we need to ensure that before detach, OVF store update succeeds and fail to detach otherwise. We may wish to have a 'force detach' to detach even if OVF store update fails for some reason.</div><div>Y. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the user manages replication on that storage domain it can be<br>
re-used for backup purposes by importing it to a setup.<br>
Actually it is much more efficient to use a data storage domain than<br>
to use the copy operation to/from the export storage domain.<br></blockquote><div><br></div></span><div>For backup you have to do:</div><div><br></div><div>1. take snapshot</div><div>2. attach the backup domain to the system</div><div>3. clone the vm to the backup domain</div><div>4. manually force update the OVF_STORE</div><div><br></div><div>For restore you have to do:</div><div><br></div><div>1. attach the backup domain to the system</div><div>2. clone the vm from the backup domain to the data domain</div><div><br></div><div>How backup domain is more efficient?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> Nir<br>
</blockquote></div></div>
</blockquote></div><br></div></div>