[ovirt-users] deprecating export domain?
Yaniv Lavi (Dary)
ylavi at redhat.com
Sun Oct 15 12:32:12 UTC 2017
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
ylavi at 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 <Pax at 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 <sdubey504 at gmail.com>
> *Date: *Monday, 2 October 2017 at 19:10
> *To: *Pavel Gashev <Pax at acronis.com>
> *Cc: *Maor Lipchuk <mlipchuk at redhat.com>, "users at ovirt.org" <
> users at 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" <Pax at 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 <sdubey504 at gmail.com>
> *Date: *Monday, 2 October 2017 at 15:55
> *To: *Charles Kozler <ckozleriii at gmail.com>
> *Cc: *Pavel Gashev <Pax at acronis.com>, users <users at ovirt.org>, Maor
> Lipchuk <mlipchuk at 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 <ckozleriii at 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 <Pax at 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-bounces at ovirt.org on behalf of Maor Lipchuk"
> <users-bounces at ovirt.org on behalf of mlipchuk at redhat.com> wrote:
>
> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer <nsoffer at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171015/b9aef3e4/attachment.html>
More information about the Users
mailing list