On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer <nsof...@redhat.com> wrote:
> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk <mlipc...@redhat.com> wrote: > >> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsof...@redhat.com> wrote: >> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul <yk...@redhat.com> wrote: >> >> >> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler <ckozler...@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 >> >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users