Re: [ovirt-users] deprecating export domain?

2017-10-15 Thread Yaniv Kaul
On Oct 15, 2017 11:39 PM, "Maor Lipchuk"  wrote:

On Sun, Oct 15, 2017 at 8:17 PM, Yaniv Kaul  wrote:
>
>
> On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer  wrote:
>>
>> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk  wrote:
>>>
>>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  wrote:
>>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:
>>> >>
>>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
>>> >> 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?


What do you mean?
backup storage domain is a DB configuration used in the engine, it
does not depend on VDSM or has any indication of backup in its
metadata.

>>
>>>
>>> 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.
>


Why detach and not when moving the storage domain to maintenance?


Correct.

We do have this mechanism today when moving a storage domain to
maintenance although IINM the operation does not fail if the OVF
update fails, but that can be easily fixed.


Indeed.
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?


The scenario you described it is the same as using the export storage
domain, but using backup storage domain is more flexible and easier to
use than the export storage domain.

Another scenario might be that the user will decide that a storage
domain should be backed up, and instead of using copy and clone
operations as you mentioned, the user can set the storage domain as
backup, replicate the storage domain, and once the copy of the storage
domain is finished the user can change the storage domain back to
regular data storage domain.
That way there is no need to maintain any clone and copy operations.

>>
>>>
>>>
>>> >
>>> > Nir
>
>

Re: [ovirt-users] deprecating export domain?

2017-10-15 Thread Maor Lipchuk
On Sun, Oct 15, 2017 at 8:17 PM, Yaniv Kaul  wrote:
>
>
> On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer  wrote:
>>
>> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk  wrote:
>>>
>>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  wrote:
>>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:
>>> >>
>>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
>>> >> 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?


What do you mean?
backup storage domain is a DB configuration used in the engine, it
does not depend on VDSM or has any indication of backup in its
metadata.

>>
>>>
>>> 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.
>


Why detach and not when moving the storage domain to maintenance?
We do have this mechanism today when moving a storage domain to
maintenance although IINM the operation does not fail if the OVF
update fails, but that can be easily fixed.

>>
>>>
>>> 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?


The scenario you described it is the same as using the export storage
domain, but using backup storage domain is more flexible and easier to
use than the export storage domain.

Another scenario might be that the user will decide that a storage
domain should be backed up, and instead of using copy and clone
operations as you mentioned, the user can set the storage domain as
backup, replicate the storage domain, and once the copy of the storage
domain is finished the user can change the storage domain back to
regular data storage domain.
That way there is no need to maintain any clone and copy operations.

>>
>>>
>>>
>>> >
>>> > Nir
>
>
___
Users mailing list
Users@ovirt.org

Re: [ovirt-users] deprecating export domain?

2017-10-15 Thread Yaniv Kaul
On Sun, Oct 15, 2017 at 7:13 PM, Nir Soffer  wrote:

> On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk  wrote:
>
>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  wrote:
>> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:
>> >>
>> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
>> >> 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


Re: [ovirt-users] deprecating export domain?

2017-10-15 Thread Nir Soffer
On Sun, Oct 1, 2017 at 3:32 PM Maor Lipchuk  wrote:

> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  wrote:
> > On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:
> >>
> >> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
> >> 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.


> 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


Re: [ovirt-users] deprecating export domain?

2017-10-15 Thread Yaniv Lavi (Dary)
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.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 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 clone

Re: [ovirt-users] deprecating export domain?

2017-10-03 Thread Pavel Gashev
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<mailto: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<mailto:sdubey...@gmail.com>>
Date: Monday, 2 October 2017 at 15:55
To: Charles Kozler <ckozler...@gmail.com<mailto:ckozler...@gmail.com>>
Cc: Pavel Gashev <p...@acronis.com<mailto:p...@acronis.com>>, users 
<users@ovirt.org<mailto:users@ovirt.org>>, Maor Lipchuk 
<mlipc...@redhat.com<mailto: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<mailto: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<mailto: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<mailto:users-boun...@ovirt.org> 
on behalf of Maor Lipchuk" 
<users-boun...@ovirt.org<mailto:users-boun...@ovirt.org> on behalf of 
mlipc...@redhat.com<mailto:mlipc...@redhat.com>> wrote:

On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer 
<nsof...@redhat.com<mailto: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 no

Re: [ovirt-users] deprecating export domain?

2017-10-02 Thread shubham dubey
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 se

Re: [ovirt-users] deprecating export domain?

2017-10-02 Thread Pavel Gashev
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<mailto: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<mailto: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<mailto:users-boun...@ovirt.org> 
on behalf of Maor Lipchuk" 
<users-boun...@ovirt.org<mailto:users-boun...@ovirt.org> on behalf of 
mlipc...@redhat.com<mailto:mlipc...@redhat.com>> wrote:

On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer 
<nsof...@redhat.com<mailto: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<mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users



___
Users mailing list
Users@ovirt.org<mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] deprecating export domain?

2017-10-02 Thread shubham dubey
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  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  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" 
>> wrote:
>>
>> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer 
>> 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/41dcb0f1791d90d
>> 1ae0ac43cd34a399cfedf54d8/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


Re: [ovirt-users] deprecating export domain?

2017-10-02 Thread Charles Kozler
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  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"
>  wrote:
>
> On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  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


Re: [ovirt-users] deprecating export domain?

2017-10-02 Thread Pavel Gashev
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" 
 wrote:

On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  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


Re: [ovirt-users] deprecating export domain?

2017-10-01 Thread Maor Lipchuk
On Sun, Oct 1, 2017 at 2:50 PM, Nir Soffer  wrote:
> On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:
>>
>> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
>> 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.
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


Re: [ovirt-users] deprecating export domain?

2017-10-01 Thread Nir Soffer
On Sun, Oct 1, 2017 at 9:58 AM Yaniv Kaul  wrote:

> On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
> 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?

Nir
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] deprecating export domain?

2017-10-01 Thread Yaniv Kaul
On Sat, Sep 30, 2017 at 8:41 PM, Charles Kozler 
wrote:

> Hello,
>
> I recently read on this list from a redhat member that export domain is
> either being deprecated or looking at being deprecated
>
> 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
>
> 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
>

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.
Y.


>
> Thanks!
>
> ___
> 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


[ovirt-users] deprecating export domain?

2017-09-30 Thread Charles Kozler
Hello,

I recently read on this list from a redhat member that export domain is
either being deprecated or looking at being deprecated

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

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

Thanks!
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users