[sheepdog] [libvirt] [Libvirt][Sheepdog]Sheepdog pool/volume storage driver for libvirt problem

[Eric Blake]

On 01/30/2013 05:59 AM, harryxiyou wrote:
> On Wed, Jan 30, 2013 at 2:49 AM, Eric Blake <eblake at redhat.com> wrote:
>> On 01/29/2013 10:42 AM, harryxiyou wrote:
>>> Hi Sebastian, Morita and other developers,
>>
>> Answering what I can...
> 
> Eric, thanks for your answers, you are awesome ;-)
> And i have some questions about your answers like following.
> 
>>> 3, In func "virStorageBackendSheepdogCreateVol", it composes cmd like this
>>> "virCommandPtr cmd = virCommandNewArgList(COLLIE, "vdi", "create",
>>> vol->name, NULL);"
>>> then send create parameters. When Sheepdog receive these parameters,
>>> how Sheepdog
>>> create this volume? I find Sheepdog create a volume like this.
>>> $ qemu-img create sheepdog:Alice 256G
>>
>> This is using 'collie', not 'qemu-img', to create the volume.  That is,
>> the current sheepdog storage driver is NOT going through qemu, but going
>> directly to sheepdog.
> 
> Yup, this is using 'collie', which is going directly to sheepdog. But
> Morita said
> if QEMU do not support Sheepdog, Libvirt would not support sheepdog. I think
> sheepdog uses collie to create/delete/... volumes but QEMU simulates sheepdog
> block device, which it has to go through QEMU during runtime.
> Do you think so? Or you have any other ideas?

There's two aspects to storage management in libvirt.

1. Offline management - libvirt needs to be able to create pools,
volumes within those pools, and list details about those volumes
(basically, making 'virsh pool-*' and 'virsh vol-*' work for sheepdog);
for qemu:/// URI connections, this is done through the
src/storage/storage_driver.c driver, which in turn delegates to the
appropriate backend_*.c backend.  For sheepdog, this will call directly
into collie.

2. Online management - libvirt needs to be able to tell qemu to start a
domain with a particular protocol, and then use qemu monitor commands to
do further manipulations on that block device.  This involves two pieces
- we have to have a way to record what protocol a <disk> uses in domain
XML (src/conf/domain_conf), and then we have to translate that XML into
the command line arguments that qemu expects (src/qemu/qemu_command).
For sheepdog, this means that we had to add a sheepdog protocol into a
type='network' XML (see
http://libvirt.org/formatdomain.html#elementsDisks for an example of the
XML), and then translate that into an appropriate file=sheepdog:...
command line snippet in src/qemu/qemu_command.c (look for
VIR_DOMAIN_DISK_PROTOCOL_SHEEPDOG).

If you are going to add a new protocol, you need to do both aspects -
teach libvirt how to manage the protocol directly, for offline
management, and teach libvirt how to invoke qemu to use the new protocol
for online usage.  But without at least one online user (qemu), it
doesn't make sense to worry about offline management in libvirt (what
good is allocating a volume if you can't make any guest populate or read
from that volume).  That's why we are telling you to focus on getting
your new protocol accepted into qemu first.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20130130/59f54da6/attachment-0002.sig>