Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 25 4月, 2016 3 次提交
    • A
      build: Group files · 7351f7fe
      由 Andrea Bolognani 提交于 
      Define $(PODFILES) and $(MANINFILES) so that adding a new man
page only requires changes in a few, well defined spots.
      7351f7fe
    • A
      build: Standardize on .pod -> .x.in -> .x · 5b479f3b
      由 Andrea Bolognani 提交于 
      After this commit, all man pages are generated using the same two
steps:

  1. Process a source $command.pod file with pod2man(1) to obtain
     a valid man page in $command.$section.in

  2. Process $command.$section.in with sed(1) to obtain the final
     man page in $command.$section
      5b479f3b
    • A
      build: Build man pages in $(builddir) · 90709d8d
      由 Andrea Bolognani 提交于 
      No file should be created inside $(srcdir) during build.
      90709d8d
  3. 21 4月, 2016 5 次提交
  5. 20 4月, 2016 1 次提交
  7. 18 4月, 2016 2 次提交
    • E
      admin: Introduce virAdmServerSetThreadPoolParameters · 93ab4da5
      由 Erik Skultety 提交于 
      Since threadpool increments the current number of threads according to current
load, i.e. how many jobs are waiting in the queue. The count however, is
constrained by max and min limits of workers. The logic of this new API works
like this:
    1) setting the minimum
        a) When the limit is increased, depending on the current number of
           threads, new threads are possibly spawned if the current number of
           threads is less than the new minimum limit
        b) Decreasing the minimum limit has no possible effect on the current
           number of threads
    2) setting the maximum
        a) Icreasing the maximum limit has no immediate effect on the current
           number of threads, it only allows the threadpool to spawn more
           threads when new jobs, that would otherwise end up queued, arrive.
        b) Decreasing the maximum limit may affect the current number of
           threads, if the current number of threads is less than the new
           maximum limit. Since there may be some ongoing time-consuming jobs
           that would effectively block this API from killing any threads.
           Therefore, this API is asynchronous with best-effort execution,
           i.e. the necessary number of workers will be terminated once they
           finish their previous job, unless other workers had already
           terminated, decreasing the limit to the requested value.
    3) setting priority workers
        - both increase and decrease in count of these workers have an
          immediate impact on the current number of workers, new ones will be
          spawned or some of them get terminated respectively.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
      93ab4da5
    • E
      admin: Introduce virAdmServerGethreadPoolParameters · caa16d31
      由 Erik Skultety 提交于 
      New API to retrieve current server workerpool specs. Since it uses typed
parameters, more specs to retrieve can be further included in the pool of
supported ones.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
      caa16d31
  9. 15 4月, 2016 1 次提交
  11. 13 4月, 2016 2 次提交
  13. 31 3月, 2016 1 次提交
  15. 29 3月, 2016 1 次提交
  17. 25 3月, 2016 1 次提交
  19. 24 3月, 2016 2 次提交
  21. 18 3月, 2016 1 次提交
  23. 11 3月, 2016 6 次提交
  25. 08 3月, 2016 1 次提交
    • J
      Introduce job completed event · f2893001
      由 Jiri Denemark 提交于 
      The VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event will be triggered once a job
(such as migration) finishes and it will contain statistics for the job
as one would get by calling virDomainGetJobStats. Thanks to this event
it is now possible to get statistics of a completed migration of a
transient domain on the source host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      f2893001
  27. 03 3月, 2016 1 次提交
  29. 02 3月, 2016 1 次提交
    • J
      Libvirt: Add missing default value for config option max_queued_clients · b3a4b176
      由 Jason J. Herne 提交于 
      Commit 1199edb1 added config option max_queued_clients and documented the
default value as 1000 but never actually set that value. This patch sets the
default value.

This addresses an issue whereby the following error message is reported if too
many migrations are started simultaneously:

error: End of file while reading data: Ncat: Invalid argument.: Input/output error

The problem is that too many ncat processes are spawned on the destination
system. They all attempt to connect to the libvirt socket. Because the
destination libvirtd cannot respond to the connect requests quickly enough we
overrun the socket's pending connections queue.
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      b3a4b176
  31. 01 3月, 2016 1 次提交
  33. 22 2月, 2016 1 次提交
    • M
      adminDaemonListServers: Don't leak @srv_names array · 702713af
      由 Michal Privoznik 提交于 
      When getting a list of servers registered for a daemon, it's
returned as a dynamically allocated array filled in with pointers
to constant strings. Because the array is dynamic, it should be
freed when no longer needed (but not the strings!). Even the
function that creates the array suggests that.

==19446== 48 bytes in 3 blocks are definitely lost in loss record 821 of 1,034
==19446==    at 0x4C2C28E: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19446==    by 0x54BAFC8: virReallocN (viralloc.c:245)
==19446==    by 0x54BB0BE: virExpandN (viralloc.c:294)
==19446==    by 0x54BB391: virInsertElementsN (viralloc.c:436)
==19446==    by 0x164E3D: virNetDaemonGetServerNames (virnetdaemon.c:217)
==19446==    by 0x15616F: adminDaemonListServers (admin_server.c:52)
==19446==    by 0x155B8C: adminDispatchConnectListServers (admin.c:151)
==19446==    by 0x155FD8: adminDispatchConnectListServersHelper (admin_dispatch.h:101)
==19446==    by 0x568E862: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==19446==    by 0x568E3C3: virNetServerProgramDispatch (virnetserverprogram.c:307)
==19446==    by 0x5687B5B: virNetServerProcessMsg (virnetserver.c:135)
==19446==    by 0x5687C1B: virNetServerHandleJob (virnetserver.c:156)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      702713af
  35. 17 2月, 2016 3 次提交
  37. 03 2月, 2016 2 次提交
    • E
      util: Export remoteSerializeTypedParameters internally via util · 8cd1d546
      由 Erik Skultety 提交于 
      Same as for deserializer, this method might get handy for admin one day.
The major reason for this patch is to stay consistent with idea, i.e.
when deserializer can be shared, why not serializer as well. The only
problem to be solved was that the daemon side serializer uses a code
snippet which handles sparse arrays returned by some APIs as well as
removes any string parameters that can't be returned to older clients.
This patch makes of the new virTypedParameterRemote datatype introduced
by one of the pvious patches.
      8cd1d546
    • E
      util: Export remoteDeserializeTypedParameters internally via util · 0472cef6
      由 Erik Skultety 提交于 
      Currently, the deserializer is hardcoded into remote_driver which makes
it impossible for admin to use it. One way to achieve a shared implementation
(besides moving the code to another module) would be pass @ret_params_val as a
void pointer as opposed to the remote_typed_param pointer and add a new extra
argument specifying which of those two protocols is being used and typecast
the pointer at the function entry. An example from remote_protocol:

struct remote_typed_param_value {
        int type;
        union {
                int i;
                u_int ui;
                int64_t l;
                uint64_t ul;
                double d;
                int b;
                remote_nonnull_string s;
        } remote_typed_param_value_u;
};
typedef struct remote_typed_param_value remote_typed_param_value;

struct remote_typed_param {
        remote_nonnull_string field;
        remote_typed_param_value value;
};

That would leave us with a bunch of if-then-elses that needed to be used across
the method. This patch takes the other approach using the new datatype
introduced in one of earlier commits.
      0472cef6
  39. 21 1月, 2016 1 次提交
  41. 11 1月, 2016 1 次提交
  43. 05 1月, 2016 1 次提交
    • L
      docs: update to properly reflect meaning of fields in log filter · 79e78725
      由 Laine Stump 提交于 
      The documentation (and comment in libvirtd.conf) says that the text in
a log filter is compared to the "source file name", and gives the
example of "util/json", but this is not correct (at least not since
commit 2835c1e7, possibly earlier). It is instead compared to the
string given in the VIR_LOG_INIT() macro invocation at the top of each
source file, which is always "similar to but not the same as" the
source file name (in the example above, the proper name is
"util.json", while the file name is "util/virjson.c"). This patch
corrects the misstatement in both the documentation and in
libvirtd.conf.
      79e78725
  45. 21 12月, 2015 1 次提交
    • E
      Revert "admin: Rename virAdmConnect to virAdmDaemon" · 3245e178
      由 Erik Skultety 提交于 
      Commmit df8192aa introduced admin related rename and some minor
(caused by automated approach, aka sed) and some more severe isues along with
it. First reason to revert is the inconsistency with libvirt library.
Although we deal with the daemon directly rather than with a specific
hypervisor, we still do have a connection. That being said, contributors might
get under the impression that AdmDaemonNew would spawn/start a new daemon
(since it's admin API, why not...), or AdmDaemonClose would do the exact
opposite or they might expect DaemonIsAlive report overall status of the daemon
which definitely isn't the case.
The second reason to revert this patch is renaming virt-admin client. The
client tool does not necessarily have to reflect the names of the API's it's
using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
where noone can be certain of what the latter function really does. The former
is quite expressive about some connection magic it performs, but the latter does
not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
left untouched.
      3245e178