[libvirt] creating stream

Vasiliy Tolstov v.tolstov at selfip.ru
Wed Apr 5 13:17:25 UTC 2017


2017-04-05 16:09 GMT+03:00 Michal Privoznik <mprivozn at redhat.com>:
> 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 at selfip.ru




More information about the libvir-list mailing list