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(a)vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html