Backup Restore API integration feature page available.

Tue Apr 23 07:24:56 UTC 2013

On 04/22/2013 11:33 PM, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>>
>> Quoting Michael Pasternak <mpastern at redhat.com>:
>>
>>> Hi Sharad,
>>>
>>> On 04/21/2013 01:42 AM, Sharad Mishra wrote:
>>>> Hi Michael,
>>>>
>>>> Not sure if you had a chance to look at the backup/restore feature
>>>> wiki page. Let me give you some high level idea on what I am trying
>>>> to do.
>>>
>>> thanks for the "high level"
>>>
>>>>
>>>> 1. When a user wants to backup a VM or disk, he/she issues a
>>>> command to backup, which may look like 'backup(VM)' and
>>>> 'backup(disk)'. Internally, this command is broken down
>>>> to taking snapshot, preparing backup disk, making the disk
>>>> available to backup server using qemu-nbd etc.
>>>>
>>>> 2. There will be a similar call to restore VM or disk .
>>>> 'restore(VM)' and 'restore(disk)'.
>>>>
>>>> My question for you is, how do I go about implementing these rest
>>>> apis? I need to create an RSDL, what else? Any good patches that
>>>> show how to add a new call will help.
>>>
>>> here how it goes
>>>
>>> backup
>>> ======
>>>
>>> in general we expose such capabilities in api via action, for instance
>>> you can take a look on disk.activate() at [1],
>>>
>>> in your case this should be divided to actions on two resources vm/disk.,
>>> i.e
>>>
>>> /api/vms/xxx/backup
> 
> verb name should not be 'backup' as we're not performing any backup operation, only making the disk available to an external app that can use it for whatever purpose it requires.
> 
>>>
>>> /api/vms/xxx/disks/yyy/backup
>>>
>>> /api/disks/xxx/backup
>>>
>>>
>>
>> Thanks for the explanation Michael.
>>
>>> q1: the last one is a disk resources that may be not attached to any
>>> vm, or on opposite
>>> to be attached in 1:N relation, active/not-active etc., how do you
>>> plan to expose 'backup'
>>> here (feature-wise)?
>>
>> I don't think there is anything special to be done to expose backups
>> of above mentioned devices. An unattached/1-N/active/not-active should
>> all be treated the same for backup purposes. The backup will display
>> the disk ID, alias, VMs attached to (if any) etc. for the backedup disk.
> 
> Problem is that a disk attached to multiple machines (i.e. shareable disk) does not support snapshots today so you cannot backup it up while there is a running VM to which it is attached.  I'd just skip such disks in V1 (same as direct LUNs).

exactly, that's was my point, so let's summarize that in v1, we will have only backup
for the vm or vm-disk.

> 
>>
>>>
>>> [1] http://gerrit.ovirt.org/#/c/3601/
>>>
>>> restore
>>> =======
>>>
>>> q1: iiuc there will be > 1 backup to restore from (am i right?) if
>>> so, you should be
>>> exposing sub-collection of backups to restore from, and we need to
>>> model this resource accordingly?
>>
>> Is there any value in keeping multiple backups? I am leaning  towards
>> just keeping the latest backup and once a newer backup is available
>> for the VM/disk, replacing the older one.
> 
> Backup app will have many 'backups' or rather many points in time from which to restore but engine has no visibility to this.
> The 'backup' is exposed via a direct lun so attaching it to a VM is simple.
> The current gap with this is that we do not support snapshots of direct luns today so we need to find a way of running the VM from this volume while copying the data to a permanent location (rather than iSCSI exposed by the backup server).
> 
>>
>> Thanks
>> Sharad
>>
>>>
>>>>
>>>>
>>>> Thanks
>>>> Sharad Mishra
>>>> Open Virtualization
>>>> Linux Technology Center
>>>> IBM
>>>>
>>>> Inactive hide details for Sharad Mishra---04/17/2013 04:41:10
>>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
>>>> Sharad Mishra---04/17/2013 04:41:10
>>>> AM---Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013
>>>> 03:15:57 AM: > From: Michael Pasternak <
>>>>
>>>> From: Sharad Mishra/Beaverton/IBM
>>>> To: Michael Pasternak <mpastern at redhat.com>,
>>>> Cc: amureini at redhat.com
>>>> Date: 04/17/2013 04:41 AM
>>>> Subject: Re: Adding a new REST API call.
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Michael Pasternak <mpastern at redhat.com> wrote on 04/17/2013 03:15:57 AM:
>>>>
>>>>> From: Michael Pasternak <mpastern at redhat.com>
>>>>> To: Sharad Mishra/Beaverton/IBM at IBMUS,
>>>>> Cc: amureini at redhat.com
>>>>> Date: 04/17/13 03:14 AM
>>>>> Subject: Re: Adding a new REST API call.
>>>>>
>>>>> On 04/16/2013 11:14 PM, Sharad Mishra wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> I am adding a new feature to support backup and restore using ISV
>>>>> packages in ovirt. As part of that work, I will be adding few new
>>>>> APIs. I am not very familiar with REST
>>>>>> API, can you point me to an example REST API patch that adds a new API
>>>>>> ?
>>>>>
>>>>> can you give me some background for this feature?
>>>>
>>>> The feature page is
>>>> http://www.ovirt.org/Features/Backup-Restore_API_Integration
>>>>
>>>> Thanks
>>>> Sharad
>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Sharad Mishra
>>>>>> Open Virtualization
>>>>>> Linux Technology Center
>>>>>> IBM
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Michael Pasternak
>>>>> RedHat, ENG-Virtualization R&D
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
>>
>>

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D