On 01/30/2013 05:59 AM, harryxiyou wrote: > On Wed, Jan 30, 2013 at 2:49 AM, Eric Blake <eblake@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list