Re: [libvirt] creating stream

2017-04-21 17:34 GMT+03:00 Michal Privoznik : > So the extra "byte" (in fact 4 bytes) are at 0x0084-0x0087. So this is how > strings are encoded. There are basically two types of strings when it comes > to XDR. The first one is nonnull_string, which are encoded

Re: [libvirt] creating stream

On 04/21/2017 01:36 PM, Vasiliy Tolstov wrote: 2017-04-21 14:14 GMT+03:00 Michal Privoznik : That's how strings are encoded in RPC. the first four bytes say how long the string is followed by N bytes (padded to 4 bytes boundary) of the actual string. I know, I'm use

Re: [libvirt] creating stream

2017-04-21 14:14 GMT+03:00 Michal Privoznik : > That's how strings are encoded in RPC. the first four bytes say how long the > string is followed by N bytes (padded to 4 bytes boundary) of the actual > string. I know, I'm use https://godoc.org/github.com/davecgh/go-xdr/xdr2

Re: [libvirt] creating stream

On 04/21/2017 12:12 PM, Vasiliy Tolstov wrote: 2017-04-20 21:14 GMT+03:00 Vasiliy Tolstov : I found , so i can decode all typed params to map[string]interface{} thanks! I'm try to add support for DomainOpenConsole and don't understand underline payload:

Re: [libvirt] creating stream

2017-04-20 21:14 GMT+03:00 Vasiliy Tolstov : > I found , so i can decode all typed params to map[string]interface{} thanks! I'm try to add support for DomainOpenConsole and don't understand underline payload: https://gist.github.com/vtolstov/f8a0f80de82100440b1c0e824436be5a

Re: [libvirt] creating stream

2017-04-20 20:55 GMT+03:00 Vasiliy Tolstov : > Thanks, but i don't understand, firstly xdr data contains number of > params (params_len) or length of params (it size) ? I found , so i can decode all typed params to map[string]interface{} thanks! -- Vasiliy Tolstov, e-mail:

Re: [libvirt] creating stream

2017-04-20 17:16 GMT+03:00 Michal Privoznik : > You can see for yourself - just fire up wireshark with libvirt dissector > installed and issue the API. > in my fedora 25 i don't tshark -Ylibvirt does not provide typed params.. > Also, you may look at remote_typed_param_value

Re: [libvirt] creating stream

On 04/20/2017 03:55 PM, Vasiliy Tolstov wrote: 2017-04-06 14:59 GMT+03:00 Michal Privoznik : That is not going to be enough. The RPC protocol is spread among other files too. You really should not hook into our RPC protocol. My question is still unanswered though - why do

Re: [libvirt] creating stream

2017-04-05 22:11 GMT+03:00 Vasiliy Tolstov : > I think in case of internal rpc i need to monitor each libvirt release > and check git diff or src/remote/remote_protocol.x I think about api breaking and create generator for rpm messages using remote_protocol.x data. So i

Re: [libvirt] creating stream

2017-04-06 15:18 GMT+03:00 Daniel P. Berrange : > Sure you're free to check if you don't believe me. I'm just making suggestion > to save you wasting your time. Ok =) -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com

Re: [libvirt] creating stream

On Thu, Apr 06, 2017 at 03:16:44PM +0300, Vasiliy Tolstov wrote: > 2017-04-06 15:09 GMT+03:00 Daniel P. Berrange : > > Hiding multiple hosts behind the libvirt API doesn't really work for the > > majority of our API objects, as the object model is designed around a > > single

Re: [libvirt] creating stream

2017-04-06 15:09 GMT+03:00 Daniel P. Berrange : > Hiding multiple hosts behind the libvirt API doesn't really work for the > majority of our API objects, as the object model is designed around a > single host concept. You need a different level of API abstraction to >

Re: [libvirt] creating stream

On Thu, Apr 06, 2017 at 03:09:12PM +0300, Vasiliy Tolstov wrote: > 2017-04-06 15:06 GMT+03:00 Vasiliy Tolstov : > >> We already have a fine grained access control system that can be used to > >> restrict feature access... > > > Also i don't think that libvirt access control

Re: [libvirt] creating stream

On Thu, Apr 06, 2017 at 03:06:49PM +0300, Vasiliy Tolstov wrote: > 2017-04-06 15:05 GMT+03:00 Daniel P. Berrange : > > We already have a fine grained access control system that can be used to > > restrict feature access... > > > I know, but i need to proxy - say have one

Re: [libvirt] creating stream

2017-04-06 15:06 GMT+03:00 Vasiliy Tolstov : >> We already have a fine grained access control system that can be used to >> restrict feature access... Also i don't think that libvirt access control have ability to deny access based on function and payload. For example i need

Re: [libvirt] creating stream

2017-04-06 15:05 GMT+03:00 Daniel P. Berrange : > We already have a fine grained access control system that can be used to > restrict feature access... I know, but i need to proxy - say have one endpoint for array of libvirt hosts. Not worry this is fun and i think for

Re: [libvirt] creating stream

On Thu, Apr 06, 2017 at 03:01:40PM +0300, Vasiliy Tolstov wrote: > 2017-04-06 14:59 GMT+03:00 Michal Privoznik : > > That is not going to be enough. The RPC protocol is spread among other files > > too. You really should not hook into our RPC protocol. > > > My question is

Re: [libvirt] creating stream

2017-04-06 14:59 GMT+03:00 Michal Privoznik : > That is not going to be enough. The RPC protocol is spread among other files > too. You really should not hook into our RPC protocol. > My question is still > unanswered though - why do you need it anyway? Now only for fun,

Re: [libvirt] creating stream

On 04/05/2017 09:11 PM, Vasiliy Tolstov wrote: 2017-04-05 17:53 GMT+03:00 Andrea Bolognani : That is true as long as you stick with the public API. If you start messing with the internal RPC and a change in libvirt breaks your code, you get to keep both pieces. I think

Re: [libvirt] creating stream

2017-04-06 8:35 GMT+03:00 Michal Privoznik : > Still, you will lack support for some drivers (e.g. ESX, Hyperv, XEN, local > test driver). Why do you want to hook on the RPC anyway? My use case only qemu, so all the simple. Also i think that integration tests covers changes

Re: [libvirt] creating stream

On 04/05/2017 09:11 PM, Vasiliy Tolstov wrote: 2017-04-05 17:53 GMT+03:00 Andrea Bolognani : That is true as long as you stick with the public API. If you start messing with the internal RPC and a change in libvirt breaks your code, you get to keep both pieces. I think

Re: [libvirt] creating stream

2017-04-05 17:53 GMT+03:00 Andrea Bolognani : > That is true as long as you stick with the public API. > > If you start messing with the internal RPC and a change > in libvirt breaks your code, you get to keep both pieces. I think in case of internal rpc i need to monitor

Re: [libvirt] creating stream

On Wed, 2017-04-05 at 16:17 +0300, Vasiliy Tolstov wrote: > I know that, but also i know that libvirt does not break compatibility > with older clients =). That is true as long as you stick with the public API. If you start messing with the internal RPC and a change in libvirt breaks your code,

Re: [libvirt] creating stream

2017-04-05 16:09 GMT+03:00 Michal Privoznik : > 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

Re: [libvirt] creating stream

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

Re: [libvirt] creating stream

2017-04-05 1:35 GMT+03:00 Vasiliy Tolstov : > Hi. I know that libvirt devs does not like devs that used internal rpc > of libvirt... 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

[libvirt] creating stream

Hi. I know that libvirt devs does not like devs that used internal rpc of libvirt... 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