- 21 4月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
The stream serial number is the serial number of the RPC call that initiated a data transfer. And as such can never be negative. Moreover, when looking up internal state for a stream, the serial numbers are compared. But hey, the serial number in message header is unsigned too! Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 4月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
This reverts commit 1e9808d3. We shouldn't advertise libvirtd.socket activation, since currently it means VM/network/... autostart won't work as expected. We tried to find a middle ground by installing the config file without an [Install] section, since systemd won't allow .socket to be enabled without one... or at least it did do that; presently on f24 it allows activating the socket quite happily. This also caused user confusion[1] Just remove the socket file. I've filed a new RFE to track coming up with a solution to the autostart problem[2], we can point users at that if there's more confusion: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1279348 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1326136
-
- 18 4月, 2016 2 次提交
-
-
由 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>
-
由 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>
-
- 15 4月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
Take setlocale/gettext error handling pattern from tools/virsh-* and use it for all standalone binaries via a new shared virGettextInitialize routine. The virsh* pattern differed slightly from other callers. All users now consistently: * Ignore setlocale errors. virsh has done this forever, presumably for good reason. This has been partially responsible for some bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1312688 https://bugzilla.redhat.com/show_bug.cgi?id=1026514 https://bugzilla.redhat.com/show_bug.cgi?id=1016158 * Report the failed function name * Report strerror
-
- 13 4月, 2016 2 次提交
-
-
由 Maxim Nestratov 提交于
Make it possible to build vz driver as a module and don't link it with libvirt.so statically. Remove registering it on client's side as far as we start relying on daemon Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Peter Krempa 提交于
Since we didn't opt to use one single event for device lifecycle for a VM we are missing one last event if the device removal failed. This event will be emitted once we asked to eject the device but for some reason it is not possible.
-
- 31 3月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
I've noticed that these APIs are missing @flags argument. Even though we don't have a use for them, it's our policy that every new API must have @flags. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 29 3月, 2016 1 次提交
-
-
由 Qiaowei Ren 提交于
Add remote support for perf event. Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com> Message-id: 1459171833-26416-3-git-send-email-qiaowei.ren@intel.com
-
- 25 3月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
In 68b726b9 we tried to fix a mem leak. However, it wasn't done quite well. Problem is, virNetDaemonGetServers() may fail in which case virObjectListFreeCount() would be called with -1 objects to free. But the number of elements is taken in unsigned rather than signed integer. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 3月, 2016 2 次提交
-
-
由 Pavel Hrdina 提交于
If caller of adminConnectListServers() pass NULL instead of servers we need to free the list we've received from virNetDaemonGetServers(). Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Cole Robinson 提交于
We were printing the wrong MAX value
-
- 18 3月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
It does not have a suffix ByName because there are no other means of looking up the server and since the name is known, this should be the preferred one. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 3月, 2016 6 次提交
-
-
由 Martin Kletzander 提交于
Since gendisplatch can now generate "modern" *ListAll* functions, let them all be generated. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Since we have the opportunity now, let's save some precious code lines. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
For now it does not matter which ones we return as the code is similarly complex, however it will fit in with other constructs in the future, mainly when we will be able to generate dispatch helpers. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
virAdm is prefix only used on the client side. Or at least for now. On server, though, this corresponds to virNet structures (virAdmConnect is virNetDaemon, virAdmServer should be virNetServer, in the future virAdmClient will be resolved to virNetServerClient, and so on). This will also make future work clearer and easier. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Since servers know their name, there is no need to supply such information twice. Also defeats inconsistencies. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
At first I did not want to do this, but after trying to implement some newer feaures in the admin API I realized we need that to make our lives easier. On the other hand they are not saved redundantly and the virNetServer objects are still kept in a hash table. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 08 3月, 2016 1 次提交
-
-
由 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>
-
- 03 3月, 2016 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
remoteDispatchConnectCloseCallbackRegister introduced in f484310a has problems. It refcounts network client object and in case of NOOP driver operations for registering/unregistering close callback (any driver except for vz) nobody will unref it later. As a result, client connection will not be disposed and driver connection will not be closed. The fix is easy. We don't need to refcount at all. We don't get a dangling pointer because in remoteClientFreeFunc, which is called upon disposing this network client object, we unregister the close callback. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 02 3月, 2016 1 次提交
-
-
由 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>
-
- 01 3月, 2016 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 22 2月, 2016 1 次提交
-
-
由 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>
-
- 17 2月, 2016 3 次提交
-
-
由 Erik Skultety 提交于
This API is merely a convenience API, i.e. when managing clients connected to daemon's servers, we should know (convenience) which server the specific client is connected to. This implies a client-side representation of a server along with a basic API to let the administrating client know what servers are actually available on the daemon. Signed-off-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Erik Skultety 提交于
This change is merely because admin_server would contain all the code from dispatchers and helpers to the actual APIs. Admin should have similar structure to the daemon-side remote driver - dispatchers and helpers in a separate module, APIs in a separate module. Best viewed with -M. Signed-off-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Erik Skultety 提交于
Since the daemon can manage and add (at fresh start) multiple servers, we also should be able to add them from a JSON state file in case of a daemon restart, so post exec restart support for multiple servers is also provided. Patch also updates virnetdaemontest accordingly. Signed-off-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 03 2月, 2016 2 次提交
-
-
由 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.
-
由 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.
-
- 21 1月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
The VIR_DOMAIN_EVENT_ID_MIGRATION_ITERATION event will be triggered whenever VIR_DOMAIN_JOB_MEMORY_ITERATION changes its value, i.e., whenever a new iteration over guest memory pages is started during migration. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 11 1月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Commit b22344f3 mistakenly reordered Default-* lines. Thanks to that I noticed that we are very inconsistent with our init scripts, so I took the liberty of synchronizing them, updating them and making them all look shiny and new. So apart from fixing the LSB requirements, I also fixed the ordering, specified runlevels and fix the link to the reference specification. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 05 1月, 2016 1 次提交
-
-
由 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.
-
- 21 12月, 2015 1 次提交
-
-
由 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.
-
- 08 12月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
When someone does 'systemctl enable libvirtd.service' we should also enable virtlockd.socket/virtlogd.socket, so that they can be auto-activated if libvirtd tries to access the sockets. Without this, people have to manually enable the units themselves via 'systemctl enable virtdlogd.socket'. This also ensures that if distros uses 'systemctl preset' for enabling 'libvirtd.service', then the virtdlogd.socket gets enabled without having to wait for the distro to update their presets file. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 05 12月, 2015 1 次提交
-
-
由 Guido Günther 提交于
In the non-systemd case, without socket activation, we need to proper ordering.
-
- 01 12月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
virAdmConnect was named after virConnect, but after some discussions, most of the APIs called will be working with remote daemon and starting them virAdmDaemon will make more sense. Only possibly controversal name is CloseCallback (de)registration, and connecting to the daemon (which will still be Open/Close), but even this makes sense if one thinks about the daemon being opened and closed, e.g. as file, etc. This way all the APIs working with the daemon will start with virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter and that will better suit with other namings as well (virDomain*, virAdmServer*, etc.). Because in virt-admin, the connection name does not refer to a struct that would have a connect in its name, also adjust 'connname' in clients. And because it is not used anywhere in the vsh code, move it from there into each client. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 30 11月, 2015 1 次提交
-
-
由 Erik Skultety 提交于
Introduce a new API to get libvirt version. It is worth noting, that libvirt-admin and libvirt share the same version number. Unfortunately, our existing API isn't generic enough to be used with virAdmConnectPtr as well. Also this patch wires up this API to the virt-admin client as a generic cmdVersion command.
-
- 26 8月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
When images are on mounted filesystems, there is no guarantee libvirtd will start before they are mounted. Since we want to start after both local and remote filesystems are mounted, we need to add both local-fs and remote-fs as targets that should precede starting libvirtd service. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 20 8月, 2015 1 次提交
-
-
由 Guido Günther 提交于
This makes it consistent with the other FLAGS in this file and reduced clutter in the diff when adding new entries.
-
- 10 8月, 2015 1 次提交
-
-
由 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>
-