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?
 
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. 

 
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?
 

>
> Nir