On 04/22/2013 11:33 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> >> Quoting Michael Pasternak <[email protected]>: >> >>> 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 <[email protected]> wrote on 04/17/2013 >>>> Sharad Mishra---04/17/2013 04:41:10 >>>> AM---Michael Pasternak <[email protected]> wrote on 04/17/2013 >>>> 03:15:57 AM: > From: Michael Pasternak < >>>> >>>> From: Sharad Mishra/Beaverton/IBM >>>> To: Michael Pasternak <[email protected]>, >>>> Cc: [email protected] >>>> Date: 04/17/2013 04:41 AM >>>> Subject: Re: Adding a new REST API call. >>>> >>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> >>>> Michael Pasternak <[email protected]> wrote on 04/17/2013 03:15:57 AM: >>>> >>>>> From: Michael Pasternak <[email protected]> >>>>> To: Sharad Mishra/Beaverton/IBM@IBMUS, >>>>> Cc: [email protected] >>>>> 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 >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/arch >> >> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
