2017-04-05 16:09 GMT+03:00 Michal Privoznik <mprivozn@xxxxxxxxxx>: > On 04/05/2017 12:35 AM, Vasiliy Tolstov wrote: >> Hi. I know that libvirt devs does not like devs that used internal rpc >> of libvirt... > > Not entirely true. We like all devs, but we just discourage people to > use our RPC as it's internal. It doesn't offer the full set of features > provided by libvirt APIs: for instance some drivers (e.g. ESX) don't use > it and use curl instead to communicate with remote hypervisor. The > second reason is that we might change the RPC suddenly without prior > notice and thus your application would just stop working. > I know that, but also i know that libvirt does not break compatibility with older clients =). So this is not big problem. >> I need to create stream to use with upload/download and >> as i see it does not created via rpc call, can you suggest me what >> files i need to check to understand how virStreamNew works and how to >> read write works internally? >> Thanks! >> > > The libvirt streams are a bit kind of magic. Esp. on RPC level. > Basically, when client and server wants to transfer some data over a > stream, both of them call virStreamNew() which creates a local object > which so far is not tied to the other stream in any way. The point where > these two streams start to be connected is the public API that involves > the stream, for instance virStorageVolDownload(). > > The streams can be viewed as an UNIX socket or some other type of > socket. virStreamSend() corresponds to write() and virStreamRecv() then > corresponds to read(). So if one side sends some data to the stream, the > other side can receive the data. > > On the code level, there's again a driver that implements the methods as > there are several implementations available. Firstly, there's network > implementation in our RPC code (this is responsible for transferring > stream data to the other side), then there's local implementation for > working with files (virFDStream), and finally ESX has its own > implementation (it uses curl for fetching/uploading data onto ESX > hypervisor). > > I'm currently working on sparse streams (so that files transferred > through our streams stay sparse), and let me tell you - the code is > pretty complicated. > > http://libvirt.org/internals/rpc.html > > Michal Thanks, now i'm interesting in rpc level with upload and download features of stream. So i try to find rpc message that sended to libvirt daemon to create stream and what messages sended from client to server to indicate on which stream it belongs. And big thanks for sparse streams, they will be very useful. -- Vasiliy Tolstov, e-mail: v.tolstov@xxxxxxxxx -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list