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

On 01/29/2013 10:42 AM, harryxiyou wrote: Answering what I can... Not quite - this is forking and executing an actual command, where the argv[] of that command was built up by the earlier virCommand* calls on that cmd object. There is no intermediate path through libvirtd during virCommandRun. It sounds like you are not quite familiar with the libvirt flow of execution. When you type a 'virsh' command line, virsh calls an API from libvirt.so. For qemu integration, the client side uses the remote driver, where the code in src/libvirt.c ends up calling the driver in src/remote/remote_driver.c, and the API ends up bundling the arguments as an RPC call, which gets sent to the existing libvirtd process. On the libvirtd daemon side, the RPC call is received and unbundled, and fed back into a call into libvirt.so, but this time the driver in src/qemu/qemu_driver.c handles the callback, and for storage operations forwards the call onto src/storage/storage_driver.c. So, the virCommandRun() you are asking about is already being run in the context of libvirtd, and is just forking out to an external program. 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. The code in src/storage is primarily for offline image manipulation, when no qemu is running and the storage volume is not in use. For online manipulation, actions like resize must go through the virDomainBlockResize(), which is handled in src/qemu/qemu_driver.c as a call into the qemu QMP monitor command for online resizing. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org