12:17 p.m.
On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk
<mlipchuk(a)redhat.com> wrote:
> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <ykaul(a)redhat.com> wrote:
> >>
> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler
<ckozleriii(a)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
>