[libvirt] Google Summer of Code 2013 ideas wiki open

Osier Yang jyang at redhat.com
Mon Apr 15 09:13:53 UTC 2013


On 15/04/13 16:34, Michal Privoznik wrote:
> On 15.04.2013 04:43, harryxiyou wrote:
>> On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
>>> On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange
>>> <berrange at redhat.com> wrote:
>>>> On Fri, Apr 12, 2013 at 08:34:18AM +0200, Michal Privoznik wrote:
>>>>> On 10.04.2013 15:13, harryxiyou wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I've also got some ideas like following for GSOC 2013.
>>>>>>
>>>>>> Storage driver jobs.
>>>>>>
>>>>>> Currently, there is no Libvirt storage API to rename storage volume,
>>>>>> storage pool, snapshot, etc. There is also no Libvirt API to move
>>>>>> volume from one pool to another using libvirt API. Possibly those
>>>>>> pools could have different backend (lvm, dir, ...). So i wanna finish
>>>>>> these jobs for Libvirt during GSOC 2013. See following in details.
>>>>>>
>>>>>>
>>>>>> 1, Rename storage volume. I will develop ' virsh vol-rename xxx'
>>>>>> option for virsh tool.
>>>>>>
>>>>>> 2, Rename storage pool. I will develop 'virsh pool-rename xxx'
>>>>>> option for virsh tool.
>>>>>>
>>>>>> 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx'
>>>>>> option for virsh tool.
>>>>> I am not sure we want *rename virsh commands. Not only for storage, but
>>>>> in general. And even if we do want these, they don't require a new API.
>>>>> They can be implemented with simple vir*GetXML(); vir*Define();
>>>>> vir*Undefine();
>>>> Actually I disagree - I think you want explicit APIs for renames, so that
>>>> it can be done atomically / with minimal risk of failure halfway.
>>>>
>>>>>> 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx'
>>>>>> option for virsh tool.
>>>>> This one makes more sense, however I am worried about difficulty a bit.
>>>>> A GSoC project should take 3 months for a student to complete. This is
>>>>> something that even unexperienced user can accomplish in less than a month.
>>>> Isn't all the libvirt functionality for this already existing? it it
>>>> is basically just  virStorageVolCreateFrom(...original vol) and then
>>>> delete the original volume.
>>> Michal said earlier that virsh vol-move seemed too small a task.
>>>
>>> Do you think that these 4 tasks together merit a 12-week project?
>>>
>> Let me give a summary about my ideas for Libvirt of GSOC 2013.
>>
>> Libvirt storage jobs.
>>
>> This project includes renaming storage volume(storage pool, snapshot,etc),
>> moving volume from one pool to another, the capability support for storage
>> driver (like virsh capabilities for the hypervisor drivers, e.g. what pool types
>> it supports, what volume types each pool type supports, even may what
>> operations/APIs the pool type support, ...etc).
>>
>> If these ones(or portions of them) are deserved to do, we should add them
>> to our wiki of GSOC 2013. Students will submit their applications for these
>> ideas at April 22nd. Could anyone please review these ideas(or portions
>> of them)? Thanks very much in advance.
>>
> Makes sense. However, I would drop renaming limitation just for volumes.
> At least not specifically say in description it's just a 'volume
> renaming'. This as advantage that we are more flexible and if student is
> doing good, he/she can introduce renaming to other libvirt objects as
> well. If he/she doesn't have so much time, doing renaming just for
> volumes is fine.
>
> Just a side note, I am still not huge fan of introducing a special API
> for this renaming. Doing it in virsh makes sense, however introducing a
> new API seems like overkill to me. I mean, if mgmt application has 2
> threads fighting over one domain, it has to already have a mutual
> exclusion procedure. If there are no such threads, then we are safe per se.
>
> But if we are ever going to have a rename API, it's gonna be hard time
> for everyone. We would have to move files (e.g. associated snapshots,
> monitor socket, logs, etc) and what if we fail somewhere in the middle
> of the process. We would have to perform a rollback.

Only supports inactive objects is a good start, supporting active
objects means a lot of work to do (object name is refered in various
places),  hard to implement, even may not deserved to do. It doesn't
hurt to destroy the object first if he wants to rename it.

And I guess for most of the cases, it has to be destroyed first to let the
new name take effect. E.g. For a domain, the qemu process has to
be restarted to use the new name.

Osier




More information about the libvir-list mailing list