HI Richard, Thanks for the quick reply. The Python program that works, that I mentioned earlier, uses subprocess to issue/run "guestfish" commands below in that order. /libguestfs/run guestfish --listen -a <https storage-SAS-URL> -- ro then the Python code exported $PID to the environment. I believe so that the same $PID could be used for the subsequent guestfish calls. /libguestfs/run guestfish --remote -- -version /libguestfs/run guestfish --remote launch Since it is running in the subprocess of "run.sh" shell, I couldn't see the libguestfs debug output. Maybe there is a way, I just don't know. Then I manually typed similar guestfish commands in Linux bash shell, like guestfish --listen -a <https storage-SAS-URL> -- ro <this returned a $PID> guestfish --remote=<$PID> -- -version guestfish --remote=<$PID> launch this sequence of guestfish commands failed at "launch" cmd. regarding params passed to add_drive call in libguestfs, the debug trace from running the guestfish cmds above looks like this: libguestfs: trace: add_drive "/<container>/abcd" "protocol:https" "server:tcp:<account>.blob.core.windows.net" which is something I already tried, not any more insights.

I really could not tell the difference between these two set of guestfish commands. (1) do you see any substance difference between doing things in these two sets of commands? ones issued in Python program and ones issued in Bash shell manually? (2) if I can add a local VM disk image to libguestfs and list its files, can I safely say that I have libguestfs installed or set up correctly on my machine? meaning I should be able to do "network" based disk image calls/add "network" based disk image? correct, in theory? At this point, I cannot 100% trust my local linguestfs setup since I don't know much about libguestfs. (3) BTW, I see error message in manual run in Bash shell above. does this tell us anything? Could not access KVM kernel module: No such file or directory qemu-system-x86_64: failed to initialize KVM: No such file or directory qemu-system-x86_64: Back to tcg accelerator I see the same KVM error when I ran "libguestfs-test-tool" Is KVM kernel absolutely needed? or is this just an option to try and does libguestfs fall back to other Linux kernel to build supermin appliance BTW, the working Python program was developed by others whom we have no contact now. So far I don't see anything special about Python. It is a just a shell program to issue libguestfs commands and wire up our own processing logic on top of libguestfs. Regarding using "nbdkit", it looks like it is another service I need to run on my box. The goal of my project is to reduce the hops and improve the performance. Also the code I develop will be a web service that takes many real time requests. with nbdkit, does it mean that I need to create a instance of nbdkit on the fly for every request that my service receives? will nbdkit option work well when I have multiple concurrent libguestfs calls going through nbdkit in multiple threads/processes?