Please open RFE requests for your suggestions.
thanks, YANIV LAVI SENIOR TECHNICAL PRODUCT MANAGER Red Hat Israel Ltd. <https://www.redhat.com/> 34 Jerusalem Road, Building A, 1st floor Ra'anana, Israel 4350109 yl...@redhat.com T: +972-9-7692306/8272306 F: +972-9-7692223 IM: ylavi <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> On Tue, Oct 3, 2017 at 6:38 PM, Pavel Gashev <p...@acronis.com> wrote: > Shubham, > > > > I hope you’re going to keep the Export feature at least as “Clone to > another storage domain”. In the real life, the copy-in/copy-out is required > for backups. Moving disks between Data SD and Backup SD is not a way to > backup or restore. It’s often required to keep VM runnable during backing > up, and it’s often required to keep a backup during restoring. Typical > backup storage is not designed for running VMs directly. SSDs are not cheap > enough for storing backups, and there are HDDs especially designed for > storing cold data [1]. Thus, the disaster recovery scenario is a great > feature, but it can’t be a recommended way to recover. > > > > And I hope you are going to show VMs on backup storages in a separate list > (“Backups” instead of “Virtual Machines”). > > > > [1] http://www.seagate.com/enterprise-storage/hard-disk- > drives/archive-hdd/ > > > > I hope this helps. > > > > *From: *shubham dubey <sdubey...@gmail.com> > *Date: *Monday, 2 October 2017 at 19:10 > *To: *Pavel Gashev <p...@acronis.com> > *Cc: *Maor Lipchuk <mlipc...@redhat.com>, "users@ovirt.org" < > users@ovirt.org> > > *Subject: *Re: [ovirt-users] deprecating export domain? > > > > Yes, I just gave an example case. If you want to use vms with a backup, > then you can just copy that vm or disk into another domain and make it as > backup domain as you do it in export domain. > > In simple language, main aim of creating backup domain is just to use all > the features available in export domain without creating a dedicated export > domain. > > Hope you understand now:) > > > > > > > > On 2 Oct 2017 8:55 pm, "Pavel Gashev" <p...@acronis.com> wrote: > > Shubham, > > > > I don’t really understand the process you described. If I need to backup > the whole datacenter, you say I have to turn off all VMs, and make them > non-runnable. It doesn’t look like a backing up. It looks like an > archiving. But what if I need to keep my VMs running? > > > > > > *From: *shubham dubey <sdubey...@gmail.com> > *Date: *Monday, 2 October 2017 at 15:55 > *To: *Charles Kozler <ckozler...@gmail.com> > *Cc: *Pavel Gashev <p...@acronis.com>, users <users@ovirt.org>, Maor > Lipchuk <mlipc...@redhat.com> > *Subject: *Re: [ovirt-users] deprecating export domain? > > > > Hi, > > The backup storage domain is quite like export storage domain but with > easy usability. > > Since you can change any data domain into backup domain any time, you not > need to create a dedicated > > export storage domain for backup or disaster recovery purpose. Altough its > working is same as export sd. > > The process of backup can be as simple as this: > > 1) turn off all the vms in your storage domain > > 2) select backup flag to convert that into backup domain. > > Once the domain is used for backup, you cannot make any changes to its > vms, disk etc as mentioned by maor. > > And yes, you can convert export sd to data domain using cli script but it > is not required anymore. > > If in future export storage domain get deprecated, you not need to be > worry about that much since you can convert all your > > export sd into data domain anytime and start using backup feature instead. > > Regards, > > Shubham > > > > > > On Mon, Oct 2, 2017 at 6:04 PM, Charles Kozler <ckozler...@gmail.com> > wrote: > > Thank you for clearing this up for me everyone. My concern that something > like the export domain wasnt going to exist and it was just going to be > deprecated with no alternative. Glad to hear all the news of the SD > > > > On Mon, Oct 2, 2017 at 8:31 AM, Pavel Gashev <p...@acronis.com> wrote: > > Maor, > > Could you please clarify, what would be the process of making backup of a > running VM to an existing backup storage domain? > > I’m asking because it looks like the process is going to be quite the same: > 1. Clone VM from a snapshot > 2. Move the cloned VM to a backup storage domain > > An ability of choosing destination storage for cloned VMs would increase > backup efficiency. On the other hand, an ability of exporting VM from a > snapshot would increase the efficiency in the same way even without > creating new entity. > > Indeed, Backup SDs would increase efficiency of disaster recovery. But the > same would be achieved by converting Export SDs to Data SDs using a small > CLI utility. > > > On 01/10/2017, 15:32, "users-boun...@ovirt.org on behalf of Maor Lipchuk" > <users-boun...@ovirt.org on behalf of mlipc...@redhat.com> wrote: > > On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsof...@redhat.com> wrote: > > > > 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. > 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. > 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. > > > > > Nir > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users