<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Oct 15, 2017 11:39 PM, "Maor Lipchuk" <<a href="mailto:mlipchuk@redhat.com">mlipchuk@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Sun, Oct 15, 2017 at 8:17 PM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
><br>
><br>
> On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
>><br>
>> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk <<a href="mailto:mlipchuk@redhat.com">mlipchuk@redhat.com</a>> wrote:<br>
>>><br>
>>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
>>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>>> >><br>
>>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler <<a href="mailto:ckozleriii@gmail.com">ckozleriii@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>> Hello,<br>
>>> >>><br>
>>> >>> I recently read on this list from a redhat member that export domain<br>
>>> >>> 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<br>
>>> >>> notes/postings/bz's<br>
>>> >>> that document this? I would imagine something like this would be<br>
>>> >>> 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<br>
>>> >>> curious<br>
>>> >>> where this is scheduled? Currently, a lot of my backups rely<br>
>>> >>> explicitly on<br>
>>> >>> an export domain for online snapshots, so I'd like to plan<br>
>>> >>> 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<br>
>>> >> provides<br>
>>> >> equivalent and even superior functionality to the export domain. Is<br>
>>> >> 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<br>
>>> > 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<br>
>>> > 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>
>><br>
>><br>
>> How older systems will handle the backup domain, when they do not<br>
>> know about backup domains?<br>
<br>
<br>
</div>What do you mean?<br>
backup storage domain is a DB configuration used in the engine, it<br>
does not depend on VDSM or has any indication of backup in its<br>
metadata.<br>
<div class="quoted-text"><br>
>><br>
>>><br>
>>> 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>
>>><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>
>><br>
>><br>
>> There is no guarantee that the OVF_STORE will contain the vm xml after<br>
>> the domain is detached.<br>
><br>
><br>
> I believe we need to ensure that before detach, OVF store update succeeds<br>
> and fail to detach otherwise. We may wish to have a 'force detach' to detach<br>
> even if OVF store update fails for some reason.<br>
> Y.<br>
><br>
<br>
<br>
</div>Why detach and not when moving the storage domain to maintenance?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Correct. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We do have this mechanism today when moving a storage domain to<br>
maintenance although IINM the operation does not fail if the OVF<br>
update fails, but that can be easily fixed.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Indeed. </div><div dir="auto">Y. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
>><br>
>>><br>
>>> 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>
>><br>
>><br>
>> For backup you have to do:<br>
>><br>
>> 1. take snapshot<br>
>> 2. attach the backup domain to the system<br>
>> 3. clone the vm to the backup domain<br>
>> 4. manually force update the OVF_STORE<br>
>><br>
>> For restore you have to do:<br>
>><br>
>> 1. attach the backup domain to the system<br>
>> 2. clone the vm from the backup domain to the data domain<br>
>><br>
>> How backup domain is more efficient?<br>
<br>
<br>
</div>The scenario you described it is the same as using the export storage<br>
domain, but using backup storage domain is more flexible and easier to<br>
use than the export storage domain.<br>
<br>
Another scenario might be that the user will decide that a storage<br>
domain should be backed up, and instead of using copy and clone<br>
operations as you mentioned, the user can set the storage domain as<br>
backup, replicate the storage domain, and once the copy of the storage<br>
domain is finished the user can change the storage domain back to<br>
regular data storage domain.<br>
That way there is no need to maintain any clone and copy operations.<br>
<br>
>><br>
>>><br>
>>><br>
>>> ><br>
>>> > Nir<br>
><br>
><br>
</blockquote></div><br></div></div></div>