- 08 1月, 2016 3 次提交
-
-
由 Michal Privoznik 提交于
Once @hostname is printed into @hoststr we don't need it anymore. ==6879== 5 bytes in 1 blocks are definitely lost in loss record 10 of 1,064 ==6879== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6879== by 0xA7ED599: strdup (in /lib64/libc-2.21.so) ==6879== by 0x552C126: virStrdup (virstring.c:726) ==6879== by 0x553B13E: virGetHostnameImpl (virutil.c:720) ==6879== by 0x553B1BF: virGetHostnameQuiet (virutil.c:741) ==6879== by 0x54FA3FD: virLogHostnameString (virlog.c:462) ==6879== by 0x54FAB0F: virLogVMessage (virlog.c:645) ==6879== by 0x54FA680: virLogMessage (virlog.c:531) ==6879== by 0x54FBBF4: virLogParseOutputs (virlog.c:1130) ==6879== by 0x11CB4F: daemonSetupLogging (libvirtd.c:685) ==6879== by 0x11E137: main (libvirtd.c:1297) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
The *event --loop commands would keep running even though a connection to libvirtd is lost. This doesn't make a lot of sense since clearly we won't get any new events from the closed connection. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virshCatchDisconnect expects ctl, but we were just passing NULL instead. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 1月, 2016 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Martin Kletzander 提交于
If user defines a virtio channel with UNIX socket backend and doesn't care about the path for the socket (e.g. qemu-agent channel), we still generate it into the persistent XML. Moreover when then user renames the domain, due to its persistent socket path saved into the per-domain directory, it will not start. So let's forget about old generated paths and also stop putting them into the persistent definition. https://bugzilla.redhat.com/show_bug.cgi?id=1278068Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
When doing a memory-only snapshot libvirt would still issue the 'transaction' command without any disk. Skip it if it isn't necessary.
-
- 06 1月, 2016 7 次提交
-
-
由 Wido den Hollander 提交于
If no port number was provided for a storage pool libvirt defaults to port 6789; however, librbd/librados already default to 6789 when no port number is provided. In the future Ceph will switch to a new port for the Ceph monitors since port 6789 is already assigned to a different application by IANA. Port 6789 is assigned to SMC-HTTPS and Ceph now has port 3300 assigned as the 'Ceph monitor' port. In this case it is the best solution to not hardcode any port number into libvirt and let librados handle the connection. Only if a user specifies a different port number we pass it down to librados, otherwise we leave it blank. Signed-off-by: NWido den Hollander <wido@widodh.nl> merge
-
由 Wido den Hollander 提交于
It could happen that rbd_list() returns X names, but that while refreshing the pool one of those RBD images is removed from Ceph through a different route then libvirt. We do not need to error out in such case, we can simply ignore the volume and continue. error : volStorageBackendRBDRefreshVolInfo:289 : failed to open the RBD image 'vol-998': No such file or directory It could also be that one or more Placement Groups (PGs) inside Ceph are inactive due to a system failure. If that happens it could be that some RBD images can not be refreshed and a timeout will be raised by librados. error : volStorageBackendRBDRefreshVolInfo:289 : failed to open the RBD image 'vol-893': Connection timed out Ignore the error and continue to refresh the rest of the pool's contents. Signed-off-by: NWido den Hollander <wido@widodh.nl>
-
由 Wido den Hollander 提交于
It could be that we error out while the RBD image has not been opened yet. This would cause us to call rbd_close() on pointer which has not been initialized. Set it to NULL by default and only close if it is not NULL. Signed-off-by: NWido den Hollander <wido@widodh.nl>
-
由 Olaf Hering 提交于
Currently pkg build of master branch fails: [ 300s] + /usr/lib/rpm/brp-boot-scripts [ 300s] E: File `virtlogd' is missing `Required-Start', please add even if empty! [ 300s] W: File `virtlogd' is missing `Required-Stop', please add even if empty! [ 300s] E: File `virtlogd' has empty `Default-Start', please specify default runlevel(s)! [ 300s] ERROR: found one or more broken init or boot scripts, please fix them. [ 300s] For more information about LSB headers please read the manual [ 300s] page of of insserv by executing the command `man 8 insserv'. [ 300s] If you don't understand this, mailto=werner@suse.de [ 300s] error: Bad exit status from /var/tmp/rpm-tmp.44965 (%install) Add the required tags, fix the existing tags. Use soft dependency "Should-Start" because virtlogd may work without network. Signed-off-by: NOlaf Hering <olaf@aepfle.de>
-
由 Michael Chapman 提交于
The virtlogd initscript's lock file should go in /var/lock/subsys/, not (the nonexistent) /var/log/subsys/. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
- 05 1月, 2016 14 次提交
-
-
由 Michal Privoznik 提交于
Just recently, qemu forbade specifying format for sourceless disks (qemu commit 39c4ae941ed992a3bb5). It kind of makes sense. If there's no file to open, why specify its format. Anyway, I have a domain like this: <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hda' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> and obviously I am unable to start it. Therefore, a fix on our side is needed too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit id 'aeb1078a' added a buildPool option and failure path which calls virStoragePoolObjRemove, which unlocks the pool, clears the 'pool' variable, and goto cleanup. However, at cleanup virStoragePoolObjUnlock is called without check if pool is non NULL.
-
由 Ján Tomko 提交于
The refactoring in commit a26669d7 silently ignored the dxml parameter of virDomainMigrateToURI2. https://bugzilla.redhat.com/show_bug.cgi?id=1295405
-
由 Dmitry Mishin 提交于
Commit id '70ffa02f' added the data.file.append option to some VIR_DOMAIN_CHR_TYPE_FILE cases in switch statements allowing the code to "fall through" for the remainder of the cases. This causes angst in code profiling tools, like Coverity since there is no break; followed by more case conditions. Adjust the logic to be more specific within each case. Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>
-
由 Dmitry Mishin 提交于
For completeness, use the VIR_TRISTATE_SWITCH_ABSENT for data.file.append comparisons. Commit ids '70ffa02f' and '53a15aed' just went with the non zero comparison.
-
由 Dmitry Mishin 提交于
Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>
-
由 Ján Tomko 提交于
Allow <name> and <uuid> anywhere under <domain>, not just at the top: error:XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Expecting an element name, got nothing Invalid sequence in interleave Element domain failed to validate content Introduced with the first RelaxNG schema in commit c642103f. https://bugzilla.redhat.com/show_bug.cgi?id=1292131
-
由 Martin Kletzander 提交于
We have few code samples there that are almost unreadable when formatted because they are not indented properly. By indenting them they are formatted as code and hence quite readable. Also adjust descriptions to be comments and add semicolons so that the code sample looks like sample of a working code. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
While reviewing 1b43885d I've noticed a virReportError() followed by a goto endjob; without setting the correct return value. Problem is, if block job is so fast that it's bandwidth does not fit into ulong, an error is reported. However, by that time @ret is already set to 1 which means success. Since the scenario can be hardly considered successful, we should return a value meaning error. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Eric Blake 提交于
Required for the copyright year bump to keep 'make syntax-check' happy, and also pulls in several portability fixes. * .gnulib: Update to latest. * bootstrap: Resync from upstream. * gnulib/local/m4/ssize_t.m4.diff: Regenerate. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 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.
-
由 Laine Stump 提交于
Due to debug logs like this: virPCIGetDeviceAddressFromSysfsLink:2432 : Attempting to resolve device path from device link '/sys/class/net/eth1/device/virtfn6' logStrToLong_ui:2369 : Converted '0000:07:00.7' to unsigned int 0 logStrToLong_ui:2369 : Converted '07:00.7' to unsigned int 7 logStrToLong_ui:2369 : Converted '00.7' to unsigned int 0 logStrToLong_ui:2369 : Converted '7' to unsigned int 7 virPCIGetDeviceAddressFromSysfs:1947 : virPCIDeviceAddress 0000:07:00.7 virPCIGetVirtualFunctions:2554 : Found virtual function 7 printed *once for each SR-IOV Virtual Function* of a Physical Function each time libvirt retrieved the list of VFs (so if the system has 128 VFs, there would be 900 lines of log for each call), the debug logs on any system with a large number of VFs was dominated by "information" that was possibly useful for debugging when the code was being written, but is now useless for debugging of any problem on a running system, and only serves to obscure the real useful information. This overkill has no place in production code, so this patch removes it.
-
由 Laine Stump 提交于
The previous error message just indicated that the desired response couldn't be found, this patch tells what was desired, as well as listing out the entire table that had been in the netlink response, to give some kind of idea why it failed.
-
由 Laine Stump 提交于
I noticed in a log file that we had failed to set a MAC address. The log said which interface we were trying to set, but didn't give the offending MAC address, which could have been useful in determining the source of the problem. This patch modifies all three places in the code that set MAC addresses to report the failed MAC as well as interface.
-
- 04 1月, 2016 4 次提交
-
-
由 Wido den Hollander 提交于
This used to return 'unkown' and that was not correct. A vol-dumpxml now returns: <volume type='network'> <name>image3</name> <key>libvirt/image3</key> <source> </source> <capacity unit='bytes'>10737418240</capacity> <allocation unit='bytes'>10737418240</allocation> <target> <path>libvirt/image3</path> <format type='raw'/> </target> </volume> The RBD driver will now error out if a different format than RAW is provided when creating a volume. Signed-off-by: NWido den Hollander <wido@widodh.nl>
-
由 Michael Chapman 提交于
Valgrind complained: ==28277== 38 bytes in 1 blocks are definitely lost in loss record 298 of 957 ==28277== at 0x4A06A2E: malloc (vg_replace_malloc.c:270) ==28277== by 0x82D7F57: __vasprintf_chk (in /lib64/libc-2.12.so) ==28277== by 0x52EF16A: virVasprintfInternal (stdio2.h:199) ==28277== by 0x52EF25C: virAsprintfInternal (virstring.c:514) ==28277== by 0x52B1FA9: virFileBuildPath (virfile.c:2831) ==28277== by 0x19B1947C: storageDriverAutostart (storage_driver.c:191) ==28277== by 0x19B196A7: storageStateAutoStart (storage_driver.c:307) ==28277== by 0x538527E: virStateInitialize (libvirt.c:793) ==28277== by 0x11D7CF: daemonRunStateInit (libvirtd.c:947) ==28277== by 0x52F4694: virThreadHelper (virthread.c:206) ==28277== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so) ==28277== by 0x82BE93C: clone (in /lib64/libc-2.12.so) Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Valgrind complained: ==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 188 of 996 ==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593) ==18990== by 0x5292E9B: virAllocN (viralloc.c:191) ==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012) ==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413) ==18990== by 0x222228CE: qemuMigrationPrepareAny (qemu_migration.c:3463) ==18990== by 0x22224121: qemuMigrationPrepareDirect (qemu_migration.c:3865) ==18990== by 0x22251C25: qemuDomainMigratePrepare3Params (qemu_driver.c:12414) ==18990== by 0x5389EE0: virDomainMigratePrepare3Params (libvirt-domain.c:5107) ==18990== by 0x1278DB: remoteDispatchDomainMigratePrepare3ParamsHelper (remote.c:5425) ==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) ==18990== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156) ==18990== ==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 189 of 996 ==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593) ==18990== by 0x5292E9B: virAllocN (viralloc.c:191) ==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012) ==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413) ==18990== by 0x222249D2: qemuMigrationRun (qemu_migration.c:4395) ==18990== by 0x22226365: doNativeMigrate (qemu_migration.c:4693) ==18990== by 0x22228E45: qemuMigrationPerform (qemu_migration.c:5553) ==18990== by 0x2225144B: qemuDomainMigratePerform3Params (qemu_driver.c:12621) ==18990== by 0x539F5D8: virDomainMigratePerform3Params (libvirt-domain.c:5206) ==18990== by 0x127305: remoteDispatchDomainMigratePerform3ParamsHelper (remote.c:5557) ==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) If we're replacing the NBD data, it's simplest to free the old object (including the disk list) and allocate a new one. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Valgrind complained: ==23975== Conditional jump or move depends on uninitialised value(s) ==23975== at 0x22255FA6: qemuDomainGetBlockJobInfo (qemu_driver.c:16538) ==23975== by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685) ==23975== by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834) ==23975== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==23975== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) ==23975== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156) ==23975== by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145) ==23975== by 0x52F4668: virThreadHelper (virthread.c:206) ==23975== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so) ==23975== by 0x82BE93C: clone (in /lib64/libc-2.12.so) ==23975== ==23975== Conditional jump or move depends on uninitialised value(s) ==23975== at 0x22255FB4: qemuDomainGetBlockJobInfo (qemu_driver.c:16542) ==23975== by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685) ==23975== by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834) ==23975== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437) ==23975== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135) ==23975== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156) ==23975== by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145) ==23975== by 0x52F4668: virThreadHelper (virthread.c:206) ==23975== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so) ==23975== by 0x82BE93C: clone (in /lib64/libc-2.12.so) If no matching block job is found, qemuMonitorGetBlockJobInfo returns 0 and we should not write anything to the caller-supplied virDomainBlockJobInfo pointer. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
- 29 12月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
While 'perl test-wrap-argv.pl' is not too long, './test-wrap-argv.pl' is shorter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 25 12月, 2015 4 次提交
-
-
由 Michal Privoznik 提交于
So, after bec787ee we are building virt-login-shell independent of LXC driver. This is nice, but the binary is enabled by default which makes no sense on mingw. In fact, it triggers some compilation errors there: CC virt_login_shell-virt-login-shell.o ../../tools/virt-login-shell.c: In function 'main': ../../tools/virt-login-shell.c:289:15: error: implicit declaration of function 'sysconf' [-Werror=implicit-function-declaration] openmax = sysconf(_SC_OPEN_MAX); ^ ../../tools/virt-login-shell.c:289:5: error: nested extern declaration of 'sysconf' [-Werror=nested-externs] openmax = sysconf(_SC_OPEN_MAX); ^ ../../tools/virt-login-shell.c:289:23: error: '_SC_OPEN_MAX' undeclared (first use in this function) openmax = sysconf(_SC_OPEN_MAX); ^ ../../tools/virt-login-shell.c:289:23: note: each undeclared identifier is reported only once for each function it appears in cc1: all warnings being treated as errors While we could workaround sysconf(_SC_OPEN_MAX) issue, the binary itself makes no sense on systems where no LXC can be spawned. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is no functional change, but I find it disturbing that something_LDADD contains PIE_LDFLAGS while something_LDFLAGS doesn't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The manpage for sysconf() suggest including unistd.h as the function is declared there. Even though we are not hitting any compile issues currently, let's include the correct header file instead of relying on some hidden include chain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So you have a libvirt volume that you want to wipe out. But lets say that the volume is actually a file stored on a journaled filesystem. Overwriting it with zeroes or a pattern does not mean that corresponding physical location on the disk is overwritten too, due to journaling. It's the same story with network based volumes, copy-on-write filesystems, and so on. Since there is no way that an userland application can write onto specific areas on disk, all that we can do is document the fact. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 12月, 2015 4 次提交
-
-
由 Maxim Nestratov 提交于
In case of prlsdkLoadDomains fails, vzOpenDefault should clear connection privateData pointer every time its memory is actually freed. Also it is not necessary to call vzConnectClose if a call to vzOpenDefault fails, because they both make cleanup of connection privateData. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Dmitry Mishin 提交于
By default, QEMU truncates serial file on open. Sometimes, it could be weird - for example, when we are trying to investigate some event, which occured several restarts ago. This patch adds an ability to preserve previous content. Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>
-
由 Dmitry Mishin 提交于
Currently, there is no possibility for user to specify desired behaviour of output to file - truncate or append. This patch adds an ability to explicitly specify that user wants to preserve file's content on reopen. Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>
-
由 Dmitry Mishin 提交于
Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>
-