On Mon, Apr 15, 2013 at 10:34:01AM +0200, Michal Privoznik wrote: > On 15.04.2013 04:43, harryxiyou wrote: > > On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > >> On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange > >> <berrange@xxxxxxxxxx> 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. There rationale for a rename API isn't thread safety > 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. Sure, that's what it means to provide an atomic operation. You should not assume that dumpxml + define is more reliable though. For the QEMU/LXC drivers where XML is the canonical configuration, it may be reliable, but for VMWare / VirtualBox, the dumpxml + define pair will *loose* information for any native config declarations that libvirt does not understand. Their native APIs also already provide a rename capability, thus a libvirt rename API is unambiguously safer for those hypervisors. It is also much better from an access control POV, because the 'define' API is a highly privileged operation, whereas 'rename' is fairly low privilege. It is desirable to be able to give someone 'rename' permissions, without giving them 'define' permissions. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list