On Sun, Oct 15, 2017 at 8:17 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
>
>
> On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <nsoffer@redhat.com> wrote:
>>
>> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk <mlipchuk@redhat.com> wrote:
>>>
>>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsoffer@redhat.com> wrote:
>>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <ykaul@redhat.com> wrote:
>>> >>
>>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler <ckozleriii@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>> I recently read on this list from a redhat member that export domain
>>> >>> is
>>> >>> either being deprecated or looking at being deprecated
>>> >
>>> >
>>> > We want to deprecate the export domain, but it is not deprecated yet.
>>> >
>>> >>>
>>> >>>
>>> >>> To that end, can you share details? Can you share any
>>> >>> notes/postings/bz's
>>> >>> that document this? I would imagine something like this would be
>>> >>> discussed
>>> >>> in larger audience
>>> >
>>> >
>>> > I agree.
>>> >
>>> >>>
>>> >>>
>>> >>> This seems like a somewhat significant change to make and I am
>>> >>> curious
>>> >>> where this is scheduled? Currently, a lot of my backups rely
>>> >>> explicitly on
>>> >>> an export domain for online snapshots, so I'd like to plan
>>> >>> accordingly
>>> >
>>> >
>>> > Can you describe how you backup your vms using export domain?
>>> > What do you mean by online snapshots?
>>> >
>>> >>
>>> >>
>>> >> We believe that the ability to detach and attach a data domain
>>> >> provides
>>> >> equivalent and even superior functionality to the export domain. Is
>>> >> there
>>> >> anything you'd miss? I don't believe it would be a significant change.
>>> >
>>> >
>>> > Attaching and detaching data domain was not designed for backing up
>>> > vms.
>>> > How would you use it for backup?
>>> >
>>> > How do you ensure that a backup clone of a vm is not started by
>>> > mistake,
>>> > changing the backup contents?
>>>
>>> That is a good question.
>>> We recently introduced a new feature called "backup storage domain"
>>> which you can mark the storage domain as backup storage domain.
>>> That can guarantee that no VMs will run with disks/leases reside on
>>> the storage domain.
>>
>>
>> How older systems will handle the backup domain, when they do not
>> know about backup domains?

What do you mean?
backup storage domain is a DB configuration used in the engine, it
does not depend on VDSM or has any indication of backup in its
metadata.

>>
>>>
>>> The feature should already exist in oVirt 4.2 (despite a bug that
>>> should be handled with this patch https://gerrit.ovirt.org/#/c/81290/)
>>> You can find more information on this here:
>>>
>>> https://github.com/shubham0d/ovirt-site/blob/41dcb0f1791d90d1ae0ac43cd34a399cfedf54d8/source/develop/release-management/features/storage/backup-storage-domain.html.md
>>>
>>> Basically the OVF that is being saved in the export domain should be
>>> similar to the same one that is being saved in the OVF_STORE disk in
>>> the storage domain.
>>
>>
>> There is no guarantee that the OVF_STORE will contain the vm xml after
>> the domain is detached.
>
>
> 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.
> Y.
>

Why detach and not when moving the storage domain to maintenance?

We do have this mechanism today when moving a storage domain to
maintenance although IINM the operation does not fail if the OVF
update fails, but that can be easily fixed.

>>
>>>
>>> If the user manages replication on that storage domain it can be
>>> re-used for backup purposes by importing it to a setup.
>>> Actually it is much more efficient to use a data storage domain than
>>> to use the copy operation to/from the export storage domain.
>>
>>
>> For backup you have to do:
>>
>> 1. take snapshot
>> 2. attach the backup domain to the system
>> 3. clone the vm to the backup domain
>> 4. manually force update the OVF_STORE
>>
>> For restore you have to do:
>>
>> 1. attach the backup domain to the system
>> 2. clone the vm from the backup domain to the data domain
>>
>> How backup domain is more efficient?

The scenario you described it is the same as using the export storage
domain, but using backup storage domain is more flexible and easier to
use than the export storage domain.

Another scenario might be that the user will decide that a storage
domain should be backed up, and instead of using copy and clone
operations as you mentioned, the user can set the storage domain as
backup, replicate the storage domain, and once the copy of the storage
domain is finished the user can change the storage domain back to
regular data storage domain.
That way there is no need to maintain any clone and copy operations.

>>
>>>
>>>
>>> >
>>> > Nir
>
>