1. 03 5月, 2016 1 次提交
    • E
      rpc: virnetserverclient: Identify clients by an integer ID · 5841d64d
      Erik Skultety 提交于
      Admin API needs a way of addressing specific clients. Unlike servers, which we
      are happy to address by names both because its name reflects its purpose (to
      some extent) and we only have two of them (so far), naming clients doesn't make
      any sense, since a) each client is an anonymous, i.e. not recognized after a
      disconnect followed by a reconnect, b) we can't predict what kind of requests
      it's going to send to daemon, and c) the are loads of them comming and going,
      so the only viable option is to use an ID which is of a reasonably wide data
      type.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      5841d64d
  2. 11 3月, 2016 2 次提交
  3. 10 8月, 2015 1 次提交
    • M
      rpc: Remove keepalive_required option · a8743c39
      Martin Kletzander 提交于
      Since its introduction in 2011 (particularly in commit f4324e32),
      the option doesn't work.  It just effectively disables all incoming
      connections.  That's because the client private data that contain the
      'keepalive_supported' boolean, are initialized to zeroes so the bool is
      false and the only other place where the bool is used is when checking
      whether the client supports keepalive.  Thus, according to the server,
      no client supports keepalive.
      
      Removing this instead of fixing it is better because a) apparently
      nobody ever tried it since 2011 (4 years without one month) and b) we
      cannot know whether the client supports keepalive until we get a ping or
      pong keepalive packet.  And that won't happen until after we dispatched
      the ConnectOpen call.
      
      Another two reasons would be c) the keepalive_required was tracked on
      the server level, but keepalive_supported was in private data of the
      client as well as the check that was made in the remote layer, thus
      making all other instances of virNetServer miss this feature unless they
      all implemented it for themselves and d) we can always add it back in
      case there is a request and a use-case for it.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      a8743c39
  4. 10 7月, 2015 1 次提交
  5. 16 6月, 2015 3 次提交
  6. 11 6月, 2015 1 次提交
  7. 05 6月, 2015 1 次提交
  8. 22 8月, 2014 1 次提交
  9. 05 10月, 2013 1 次提交
    • E
      build: fix build --without-remote · bdc55cc7
      Eric Blake 提交于
      I tried to test ./configure --without-lxc --without-remote.
      First, the build failed with some odd errors, such as an
      inability to build xen, or link failures for virNetTLSInit.
      But when you think about it, once there is no remote code,
      all of libvirtd is useless, any stateful driver that depends
      on libvirtd is also not worth compiling, and any libraries
      used only by RPC code are not needed.  So I patched
      configure.ac to make for some saner defaults when an
      explicit disable is attempted.  Similarly, since we have
      migrated virnetdevbridge into generic code, the workaround
      for Linux kernel stupidity must not depend on stateful
      drivers being in use.
      
      Then there's 'make check' that needs segregation.
      
      Wow - quite a bit of cleanup to make --without-remote useful :)
      
      * configure.ac: Let --without-remote toggle defaults on stateful
      drivers and other libraries.  Pick up Linux kernel workarounds
      even when qemu and lxc are not being compiled.
      * tests/Makefile.am (test_programs): Factor out programs that
      require remote.
      * src/libvirt_private.syms (rpc/virnet*.h): Move...
      * src/libvirt_remote.syms: ...into new file.
      * src/Makefile.am (SYM_FILES): Ship new syms file.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      bdc55cc7