[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] support sheepdog volumes



At Fri, 19 Nov 2010 14:56:35 -0800,
Josh Durgin wrote:
> 
> On 11/18/2010 04:42 PM, MORITA Kazutaka wrote:
> > On 2010/11/18 19:46, Daniel P. Berrange wrote:
> >> On Wed, Nov 17, 2010 at 06:19:58PM +0900, MORITA Kazutaka wrote:
> >>> Sheepdog is a distributed storage system for QEMU. It provides highly
> >>> available block level storage volumes to VMs like Amazon EBS.  This
> >>> patch adds support for Sheepdog; we can create VMs with sheepdog
> >>> volumes, and attach sheepdog volumes to running machines via the
> >>> attach-device command.
> >>>
> >>> Sheepdog volumes can be declared like this:
> >>>
> >>>      <disk type='sheepdog' device='disk'>
> >>>        <driver name='qemu' type='raw' />
> >>>        <source vdi='volume_name' host='hostname' port='7000'/>
> >>>        <target dev='vda' bus='virtio' />
> >>>      </disk>
> >>>
> >>> 'host' and 'port' in the source element are optional.  If they are not
> >>> specified, sheepdog clients use the default value (localhost:7000).
> >>
> >> I'm not too familiar with sheepdog implementation, but I understand
> >> that each block device is stored across multiple hosts, but you're
> >> only listing one hostname here.  In the proposal for supporting RBD/
> >> CEPH in libvirt/QEMU, there's tan option to give multiple hostnames.
> >> Is the need to give multiple hostnames going to be something that
> >> is also relevant for Sheepdog, or does it cope with this in an
> >> entirely different way ?
> >
> > We use the hostname as like a gateway to access sheepdog volumes.
> > Though we could extend it to multiple hostnames to achieve high
> > availability, how to use these parameters as qemu arguments needs to
> > be discussed.
> 
> For RBD, the monitor hostnames can be set through the environment. It
> looks like this is easy to add to the libvirt QEMU driver. Would
> environment variables work for sheepdog as well?

No, but it looks much better to use environment variables for
extending a sheepdog gateway to multiple servers.

> 
> >>
> >> As mentioned in the RBD thread[1], I'm wondering whether we should aim
> >> for separate 'types' for each network block device or try to merge
> >> them into one common syntax like
> >>
> >>       <disk type="network" device="disk">
> >>         <driver name="qemu" type="raw" />
> >>         <source protocol='rbd|sheepdog|nbd' name="...some image identifier...">
> >>           <host name="mon1.example.org" port="6000">
> >>           <host name="mon2.example.org" port="6000">
> >>           <host name="mon3.example.org" port="6000">
> >>         </source>
> >>         <target dev="vda" bus="virtio" />
> >>       </disk>
> >
> > Are monitor addresses necessary in the above syntax for RBD?  I guess
> > the monitor addresses are parameters to create a rbd image, but not
> > ones to use a rbd image.  If so, we can make the syntax a bit simpler like
> 
> The monitors serve as gateways for RBD. All need to be specified
> so that RBD can still access the cluster if some monitors go down.

Sorry for confusion.  If so, the first syntax Daniel suggested looks
good for our storage volumes.


Thanks,

Kazutaka


> 
> >       <disk type="network" device="disk">
> >         <driver name="qemu" type="raw" />
> >         <source protocol='rbd|sheepdog|nbd' name="..." host="hostname" port="6000" />
> >         <target dev="vda" bus="virtio" />
> >       </disk>
> >
> >
> > Thannks,
> >
> > Kazutaka
> 
> Thanks,
> Josh
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo vger kernel org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]