- 13 6月, 2012 11 次提交
-
-
由 Jiri Denemark 提交于
The previous commit removed the only usage of ``all'' parameter in virKeepAliveStopInternal, which was actually the only reason for having virKeepAliveStopInternal. This effectively reverts most of commit 6446a9e2.
-
由 Jiri Denemark 提交于
When a libvirt API is called from the main event loop (which seems to be common in event-based glib apps), the client IO loop would properly handle keepalive requests sent by a server but will not actually send them because the main event loop is blocked with the API. This patch gets rid of response timer and the thread which is processing keepalive requests is also responsible for queueing responses for delivery.
-
由 Jiri Denemark 提交于
This makes it possible to create and queue new calls while we are running IO loop.
-
由 Jiri Denemark 提交于
Add virKeepAliveTimeout and virKeepAliveTrigger APIs that can be used to set poll timeouts and trigger keepalive timer. virKeepAliveTrigger checks if it is called to early and does nothing in that case.
-
由 Jiri Denemark 提交于
The code that needs to be run every keepalive interval of inactivity was only called from a timer and thus from the main event loop. We will need to call the code directly from another place.
-
由 Jiri Denemark 提交于
As we never drop non-blocking calls, the return value that used to indicate a call was dropped is no longer needed.
-
由 Jiri Denemark 提交于
As non-blocking calls are no longer dropped, we don't really need to care that much about their fate and wait for the thread with the buck to process them. If another thread has the buck, we can just push a non-blocking call to the queue and be done with it.
-
由 Jiri Denemark 提交于
So far, we were dropping non-blocking calls whenever sending them would block. In case a client is sending lots of stream calls (which are not supposed to generate any reply), the assumption that having other calls in a queue is sufficient to get a reply from the server doesn't work. I tried to fix this in b1e374a7 but failed and reverted that commit. With this patch, non-blocking calls are never dropped (unless the connection is being closed) and will always be sent.
-
由 Jiri Denemark 提交于
Normally, when every call has a thread associated with it, the thread may get the buck and be in charge of sending all calls until its own call is done. When we introduced non-blocking calls, we had to add special handling of new non-blocking calls. This patch uses event loop to send data if there is no thread to get the buck so that any non-blocking calls left in the queue are properly sent without having to handle them specially. It also avoids adding even more cruft to client IO loop in the following patches. With this change in, non-blocking calls may see unpredictable delays in delivery when the client has no event loop registered. However, the only non-blocking calls we have are keepalives and we already require event loop for them, which makes this a non-issue until someone introduces new non-blocking calls.
-
由 Jiri Denemark 提交于
When analyzing our debug log, I'm always confused about what each of the pointers mean. Let's be explicit.
-
由 Eric Blake 提交于
'make dist' was depending on *protocol-structs files, which are stored in git but in turn depended on generated files. We still want to ship the protocol-structs files, but by renaming the tests to something not matching a file name, we separate 'make check' (which depends on the generated file) from 'make dist' (which only depends on the git files). After all, the tarball should never depend on a generated file not stored in git. I found one more case of a git file depending on a generated file, in a bogus virkeycode.c listing; but at least this one had no associated rules so it never broke 'make dist'. Reported by Wen Congyang. Latent bug has been present since commit 62dee6fa, but only recently exposed by commit 7bff56a0. * src/Makefile.am ($(srcdir)/util/virkeycode.c): Drop useless dependency. (BUILT_SOURCES): ...and build virkeymaps.h sooner. (PROTOCOL_STRUCTS): Rather than depend on the struct file... (check-local): ...convert things into a phony target of... (check-protocol): ...a new check. ($(srcdir)/remote_protocol-struct): Rename to isolate the distributed file from the conditional test. (PDWTAGS): Deal with rename. Swap to compare 'expected actual'.
-
- 12 6月, 2012 8 次提交
-
-
由 Guido Günther 提交于
so we can update file system quota
-
由 Guido Günther 提交于
with persist=false the domain config file will not be updated.
-
由 Guido Günther 提交于
for containers matching virDomainDiskIndexByName.
-
由 Michal Privoznik 提交于
Currently, if qemuProcessStart fail at some point, e.g. because domain being started wants a PCI/USB device already assigned to a different domain, we jump to cleanup label where qemuProcessStop is performed. This unconditionally calls virSecurityManagerRestoreAllLabel which is wrong because the other domain is still using those devices. However, once we successfully label all devices/paths in qemuProcessStart() from that point on, we have to perform a rollback on failure - that is - we have to virSecurityManagerRestoreAllLabel.
-
由 Michal Privoznik 提交于
Currently, we are passing only one boolean (migrated) so there is no real profit in this. But it creates starting position for next patch.
-
由 Eric Blake 提交于
The two APIs are rather trivial; based on bits and pieces of other existing APIs. It leaves the door open for future extension to qemu to report snapshots without metadata based on reading qcow2 internal snapshot names. * src/qemu/qemu_driver.c (qemuDomainSnapshotIsCurrent) (qemuDomainSnapshotHasMetadata): New functions.
-
由 Eric Blake 提交于
Pretty straightforward. * src/remote/remote_protocol.x (remote_domain_snapshot_is_current_args) (remote_domain_snapshot_is_current_ret) (remote_domain_snapshot_has_metadata_args) (remote_domain_snapshot_has_metadata_ret): New structs. (REMOTE_PROC_DOMAIN_SNAPSHOT_IS_CURRENT) (REMOTE_PROC_DOMAIN_SNAPSHOT_HAS_METADATA): New RPC calls. * src/remote/remote_driver.c (remote_driver): Call them. * src/remote_protocol-structs: Regenerate.
-
由 Eric Blake 提交于
Right now, starting from just a virDomainSnapshotPtr, and wanting to know if it is the current snapshot for its respective domain, you have to use virDomainSnapshotGetDomain(), then virDomainSnapshotCurrent(), then compare the two names returned by virDomainSnapshotGetName(). It is a bit easier if we can directly query this information from the snapshot itself. Right now, it is possible to filter a snapshot listing based on whether snapshots have metadata that would prevent domain deletion, but the only way to learn if an individual snapshot has metadata is to see if that snapshot appears in the list returned by a listing. Additionally, I hope to expand the qemu driver in a future patch to use qemu-img to reconstruct snapshot XML corresponding to internal qcow2 snapshot names not otherwise tracked by libvirt (in part, so that libvirt can guarantee that new snapshots are not created with a name that would silently corrupt the existing portion of the qcow2 file); if I ever get that in, then it would no longer be an all-or-none decision on whether snapshots have metadata, and becomes all the more important to be able to directly determine that information from a particular snapshot. Other query functions (such as virDomainIsActive) do not have a flags argument, but since virDomainHasCurrentSnapshot takes a flags argument, I figured it was safer to provide a flags argument here as well. * include/libvirt/libvirt.h.in (virDomainSnapshotIsCurrent) (virDomainSnapshotHasMetadata): New declarations. * src/libvirt.c (virDomainSnapshotIsCurrent) (virDomainSnapshotHasMetadata): New functions. * src/libvirt_public.syms (LIBVIRT_0.9.13): Export them. * src/driver.h (virDrvDomainSnapshotIsCurrent) (virDrvDomainSnapshotHasMetadata): New driver callbacks.
-
- 11 6月, 2012 5 次提交
-
-
由 Eric Blake 提交于
Right now, the only way to get at the contents of a virBuffer is to destroy it. But there are cases in my upcoming patches where peeking at the contents makes life easier. I suppose this does open up the potential for bad code to dereference a stale pointer, by disregarding the docs that the return value is invalid on the next virBuf operation, but such is life. * src/util/buf.h (virBufferCurrentContent): New declaration. * src/util/buf.c (virBufferCurrentContent): Implement it. * src/libvirt_private.syms (buf.h): Export it. * tests/virbuftest.c (testBufAutoIndent): Test it.
-
由 Michal Privoznik 提交于
My latest patch for RPC rework (a2c304f6) introduced a memory leak. virNetMessageEncodeHeader() is calling VIR_ALLOC_N(msg->buffer, ...) despite fact, that msg->buffer isn't VIR_FREE()'d on all paths calling the function. Therefore, rather than injecting free statement switch to VIR_REALLOC_N().
-
由 Gao feng 提交于
we forgot to free fslist,just add VIR_FREE(fslist). Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
由 Gao feng 提交于
when do remount,the source and target should be the same values specified in the initial mount() call. So change fs->dst to src. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
由 Gao feng 提交于
There is no code use the variable "src" in lxcContainerMountBasicFS. so delete it and VIR_FREE. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
- 09 6月, 2012 2 次提交
-
-
由 Guido Günther 提交于
otherwise migration fails for e.g. network filesystems like sheepdog with: error: Invalid relative path 'virt-name': Invalid argument while we should fail with: Migration may lead to data corruption if disks use cache != none References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676328 https://www.redhat.com/archives/libvirt-users/2012-May/msg00088.html
-
由 Eric Blake 提交于
virDomainSnapshotPtr has a refcount member, but no one was able to use it. Furthermore, all of our other vir*Ptr objects have a *Ref method to match their *Free method. Thankfully, this is client-side only, so we can use this new function regardless of how old the server side is! (I have future patches to virsh that want to use it.) * include/libvirt/libvirt.h.in (virDomainSnapshotRef): Declare. * src/libvirt.c (virDomainSnapshotRef): Implement it. * src/libvirt_public.syms (LIBVIRT_0.9.13): Export it.
-
- 08 6月, 2012 3 次提交
-
-
由 Jiri Denemark 提交于
When libvirtd forks off a new child, the child then calls virLogReset(), which ends up closing file descriptors used as log outputs. However, we recently started logging closed file descriptors, which means we need to lock logging mutex which was already locked by virLogReset(). We don't really want to log anything when we are in the process of closing log outputs.
-
-
由 Li Zhang 提交于
For pseries guest, spapr-vlan and spapr-vty is based on spapr-vio address. According to model of network device, the address type should be assigned automatically. For serial device, serial pty device is recognized as spapr-vty device, which is also on spapr-vio. So this patch is to correct the address type of spapr-vlan and spapr-vty, and build correct command line of spapr-vty. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com> Reviewed-by: Michael Ellerman<michaele@au1.ibm.com>
-
- 07 6月, 2012 3 次提交
-
-
由 Eric Blake 提交于
There is a theoretical problem of an extreme bug where we can get into deadlock due to command handshaking. Thanks to a pair of pipes, we have a situation where the parent thinks the child reported an error and is waiting for a message from the child to explain the error; but at the same time the child thinks it reported success and is waiting for the parent to acknowledge the success; so both processes are now blocked. Thankfully, I don't think this deadlock is possible without at least one other bug in the code, but I did see exactly that sort of situation prior to commit da831afc - I saw a backtrace where a double close bug in the parent caused the parent to read from the wrong fd and assume the child failed, even though the child really sent success. This potential deadlock is not quite like commit 858c2476 (a deadlock due to multiple readers on one pipe preventing a write from completing), although the solution is similar - always close unused pipe fds before blocking, rather than after. * src/util/command.c (virCommandHandshakeWait): Close unused fds sooner.
-
由 Martin Kletzander 提交于
When libvirtd is started and there is an unusable/not-connectable leftover from earlier started machine, it's more reasonable to say that the machine "crashed" if we know it was started with "-no-shutdown". This patch fixes that and also changes the other result (when machine was started without "-no-shutdown") to "unknown", because the previous "failed" reason means (according to include/libvirt/libvirt.h.in:174), that the machine failed to start.
-
由 Eric Blake 提交于
Commit 7bff56a0 worked in an incremental build, but fails for a fresh clone; apparently, if make sees both an actual file spelling and an inference rule, only the exact spelling is used. CCLD libvirt_driver_test.la CC libvirt_driver_remote_la-remote_driver.lo remote/remote_driver.c:4707:34: fatal error: remote_client_bodies.h: No such file or directory compilation terminated. BUILT_SOURCES to the rescue, instead of trying to mess with .lo dependencies directly. * src/Makefile.am (REMOTE_DRIVER_PREREQS, %remote_driver.lo): Drop... (BUILT_SOURCES): ...and add here instead.
-
- 06 6月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Commit 1c275e9a accidentally dropped the storage driver from libvirtd, because it depended on a C preprocessor macro that was not defined. Furthermore, if you do './configure --without-storage-dir --with-storage-disk' or any other combination where you explicitly build a subset of storage backends excluding the dir backend, then the build is broken. Based on analysis by Osier Yang. * configure.ac (WITH_STORAGE): Define top-level conditional. * src/Makefile.am (mod_LTLIBRARIES): Build driver even when storage_dir is disabled. * daemon/libvirtd.c: Pick up storage driver for any backend, not just dir. * daemon/Makefile.am (libvirtd_LDADD): Likewise.
-
- 05 6月, 2012 7 次提交
-
-
由 Michal Privoznik 提交于
Since we are allocating RPC buffer dynamically, we can increase limits for max. size of RPC message and RPC string. This is needed to cover some corner cases where libvirt is run on such huge machines that their capabilities XML is 4 times bigger than our current limit. This leaves users with inability to even connect.
-
由 Michal Privoznik 提交于
Currently, we are allocating buffer for RPC messages statically. This is not such pain when RPC limits are small. However, if we want ever to increase those limits, we need to allocate buffer dynamically, based on RPC message len (= the first 4 bytes). Therefore we will decrease our mem usage in most cases and still be flexible enough in corner cases.
-
由 Eric Blake 提交于
We had a distributed file (remote_protocol.h, which in turn was a prereq to remote_driver.c) depending on a generated file (libvirt_probes.h), which is a no-no for a VPATH build from a read-only source tree (no wonder 'make distcheck' tests precisely that situation): File `libvirt_driver_remote.la' does not exist. File `libvirt_driver_remote_la-remote_driver.lo' does not exist. Prerequisite `libvirt_probes.h' is newer than target `../../src/remote/remote_protocol.h'. Must remake target `../../src/remote/remote_protocol.h'. Invoking recipe from Makefile:7464 to update target `../../src/remote/remote_protocol.h'. make[3]: Entering directory `/home/remote/eblake/libvirt-tmp2/build/libvirt-0.9.12/_build/src' GEN ../../src/remote/remote_protocol.h cannot create ../../src/remote/remote_protocol.h: Permission denied at ../../src/rpc/genprotocol.pl line 31. make[3]: *** [../../src/remote/remote_protocol.h] Error 13 Rather than making distributed .c files depend on generated files, we really want to ensure that compilation into .lo files is not attempted until the generated files are present, done by this patch. Since there were two different sets of conditionally generated files that both feed the .lo file, I had to introduce a new variable REMOTE_DRIVER_PREREQS to keep automake happy. After that fix, the next issue was that make treats './foo' and 'foo' differently in determining whether an implicit %foo rule is applicable, with the result that locking/qemu-sanlock.conf wasn't properly being built at the right times. Also, the output for using the .aug test files was a bit verbose. After fixing the src directory, the next error is related to the docs directory, where the tarball is missing a stamp file and thus tries to regenerate files that are already present: GEN ../../docs/apibuild.py.stamp Traceback (most recent call last): File "../../docs/apibuild.py", line 2511, in <module> rebuild("libvirt") File "../../docs/apibuild.py", line 2495, in rebuild builder.serialize() File "../../docs/apibuild.py", line 2424, in serialize output = open(filename, "w") IOError: [Errno 13] Permission denied: '../../docs/libvirt-api.xml' make[5]: *** [../../docs/apibuild.py.stamp] Error 1 and fixing that exposed another case of a distributed file (generated html) depending on a built file (libvirt.h), but only when doing an in-tree build, because of a file glob. * src/Makefile.am ($(srcdir)/remote/remote_driver.c): Change... (libvirt_driver_remote_la-remote_driver.lo): ...to the real dependency. ($(builddir)/locking/%-sanlock.conf): Drop $(builddir), so that rule gets run in time for test_libvirt_sanlock.aug. (test_libvir*.aug): Cater to silent build. (conf_DATA): Don't ship qemu-sanlock.conf in the tarball, since it is trivial to regenerate. * docs/Makefile.am (EXTRA_DIST): Ship our stamp file. ($(APIBUILD_STAMP)): Don't depend on generated file.
-
由 Beat Jörg 提交于
I came across a bug that the command line generated for passthrough of the host parallel port /dev/parport0 by libvirt for QEMU is incorrect. It currently produces: -chardev tty,id=charparallel0,path=/dev/parport0 -device isa-parallel,chardev=charparallel0,id=parallel0 The first parameter is "tty". It sould be "parport". If I launch qemu with -chardev parport,... it works as expected. I have already filled a bug report ( https://bugzilla.redhat.com/show_bug.cgi?id=823879 ), the topic was already on the list some months ago: https://www.redhat.com/archives/libvirt-users/2011-September/msg00095.htmlSigned-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Noticed during the previous commit. * src/util/command.c: Fix some spacing and break long lines.
-
由 Eric Blake 提交于
It is possible to deadlock libvirt by having a domain with XML longer than PIPE_BUF, and by writing a hook script that closes stdin early. This is because libvirt was keeping a copy of the child's stdin read fd open, which means the write fd in the parent will never see EPIPE (remember, libvirt should always be run with SIGPIPE ignored, so we should never get a SIGPIPE signal). Since there is no error, libvirt blocks waiting for a write to complete, even though the only reader is also libvirt. The solution is to ensure that only the child can act as a reader before the parent does any writes; and then dealing with the fallout of dealing with EPIPE. Thankfully, this is not a security hole - since the only way to trigger the deadlock is to install a custom hook script, anyone that already has privileges to install a hook script already has privileges to do any number of other equally disruptive things to libvirt; it would only be a security hole if an unprivileged user could install a hook script to DoS a privileged user. * src/util/command.c (virCommandRun): Close parent's copy of child read fd earlier. (virCommandProcessIO): Don't let EPIPE be fatal; the child may be done parsing input. * tests/commandhelper.c (main): Set up a SIGPIPE situation. * tests/commandtest.c (test20): Trigger it. * tests/commanddata/test20.log: New file.
-
由 Laine Stump 提交于
Although src/util/viratomic.h has been added to the repo, up until now it hasn't been used. Stefan Berger is using it in his proposed dhcp snooping patches, and an rpm build with those patches failed due to viratomic.h not being packed up with the rest of the sources.
-