[ovirt-users] deprecating export domain?

[Yaniv Kaul]

On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <nsoffer at redhat.com> wrote:

> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk <mlipchuk at redhat.com> wrote:
>
>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <ykaul at redhat.com> wrote:
>> >>
>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler <ckozleriii at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171015/8063e847/attachment.html>