Eric, Well, in case where several servers may start the same virtual machines after a reboot for exemple. http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887.html I've seen this hook here : http://www.wogri.at/en/linux/ceph-libvirt-locking/ But it's a hook... Yes, I may try to write a patch. My coding skills are surely not as good as yours but I 'd be glad to make a try :) -----Message d'origine----- De : Eric Blake [mailto:eblake@redhat.com] Envoyé : jeudi 7 novembre 2013 16:40 À : NEVEU Stephane; libvirt-users@redhat.com Objet : Re: [libvirt-users] RBD images locking On 11/07/2013 07:56 AM, NEVEU Stephane wrote:> Hi, > > One short question : Is there any chance to see locks on rbd/images in the next release ?What exactly are you looking for? Are you willing to contribute the patches? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 11/07/2013 09:04 AM, NEVEU Stephane wrote:> Eric,[please don't top-post on technical lists]> > Well, in case where several servers may start the same virtual machines after a reboot for exemple. > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887.htmlIsn't the existing virtlockd support already sufficient for this? If not, what is preventing the virtlock framework from interacting with rbd disks? http://libvirt.org/locking.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Hello, On Thu, Nov 7, 2013 at 8:04 PM, NEVEU Stephane <stephane.neveu@thalesgroup.com> wrote:> Eric, > > Well, in case where several servers may start the same virtual machines after a reboot for exemple. > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887.html > > I've seen this hook here : http://www.wogri.at/en/linux/ceph-libvirt-locking/ > But it's a hook... > Yes, I may try to write a patch. My coding skills are surely not as good as yours but I 'd be glad to make a try :)That`s an orchestrator issue and should be fixed using orchestrator capabilities IMO.> > > -----Message d'origine----- > De : Eric Blake [mailto:eblake@redhat.com] > Envoyé : jeudi 7 novembre 2013 16:40 > À : NEVEU Stephane; libvirt-users@redhat.com > Objet : Re: [libvirt-users] RBD images locking > > On 11/07/2013 07:56 AM, NEVEU Stephane wrote: >> Hi, >> >> One short question : Is there any chance to see locks on rbd/images in the next release ? > > What exactly are you looking for? Are you willing to contribute the patches? > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > > _______________________________________________ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users
De : Eric Blake [mailto:eblake@redhat.com] Envoyé : jeudi 7 novembre 2013 17:09 À : NEVEU Stephane; libvirt-users@redhat.com Objet : Re: [libvirt-users] RBD images locking On 11/07/2013 09:04 AM, NEVEU Stephane wrote:> Eric,[please don't top-post on technical lists] Sorry !> > Well, in case where several servers may start the same virtual machines after a reboot for exemple. > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887 > .htmlIsn't the existing virtlockd support already sufficient for this? If not, what is preventing the virtlock framework from interacting with rbd disks? Ok, I'll take a look. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Nov 07, 2013 at 09:08:58AM -0700, Eric Blake wrote:> On 11/07/2013 09:04 AM, NEVEU Stephane wrote: > > Eric, > > [please don't top-post on technical lists] > > > > > Well, in case where several servers may start the same virtual machines after a reboot for exemple. > > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-August/003887.html > > Isn't the existing virtlockd support already sufficient for this? If > not, what is preventing the virtlock framework from interacting with rbd > disks?Nothing really. The current impl only deals with disks with type=file or type=block, ignoring type=network. We could extend it to cope with the latter though - either using a URI to uniquely identify the network storage, or better yet using some unique volume ID if available. 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 :|