- 09 1月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
A migration is in "setup" state after it was "inactive" and before it becomes "active". Let's reflect this in our migration status enum. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 1月, 2016 6 次提交
-
-
由 Pavel Hrdina 提交于
This patch partially reverts previous commit 91a00424 and moves the post parse function to xenParseSxpr. This update is required because xen driver calls xenParseSxpr directly. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Martin Kletzander 提交于
It was added by mistake before the 'If' by commit 71408079. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Jiri Denemark 提交于
My commit 674afcb0 moved computing the default listen address from qemuMigrationPrepareAny to qemuMigrationPrepareIncoming. However, I didn't notice listenAddress was later passed to qemuMigrationStartNBDServer. Thus, it would be called with the original value of listenAddress (NULL). Let's add the updated listen address to qemuProcessIncomingDef and use it when starting NBD servers. Reported-by: NMichael Chapman <mike@very.puzzling.org> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
Most of the changes to the list of active and inactive PCI devices happen in virHostdev, where they are properly logged. virPCIDeviceDetach() and virPCIDeviceReattach(), however, change the inactive list as well, so they should be logging similar messages.
-
由 Michal Privoznik 提交于
Instead of misusing a const string to hold up runtime allocated data, introduce new variable @hoststr and obey const correctness. ==6879== 15 bytes in 1 blocks are definitely lost in loss record 68 of 1,064 ==6879== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6879== by 0xA7DDF97: vasprintf (in /lib64/libc-2.21.so) ==6879== by 0x552BBC6: virVasprintfInternal (virstring.c:493) ==6879== by 0x552BCDB: virAsprintfInternal (virstring.c:514) ==6879== by 0x54FA44C: virLogHostnameString (virlog.c:468) ==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>
-
由 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>
-
- 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 5 次提交
-
-
由 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>
-
- 05 1月, 2016 10 次提交
-
-
由 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.
-
由 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>
-
由 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>
-
- 25 12月, 2015 2 次提交
-
-
由 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 6 次提交
-
-
由 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>
-
由 Maxim Nestratov 提交于
Implement VIR_DOMAIN_UNDEFINE_MANAGED_SAVE and VIR_DOMAIN_UNDEFINE_SNAPSHOTS_METADATA flags support. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
prlsdkCleanupBridgedNet call should be made strongly after any actual domain deletion accurs. By doing this we avoid any potential problems connected with second undefine call when it is made after first one fails by some reason, and we detect that network is already deleted. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Currently vz driver unregisters domains when undefine is called, which is wrong because it contradicts with expected behavior. All vz domains are persistent, which means that when one is defined a new bundle directory containing meta data is created. Undefining domains in a way we do now leaves those directories undeleted, which prevents subsequent define call for the same domain xml. I.e. the following sequence define->undefine->define doesn't work now. The patch fixes the problem by calling PrlVm_Delete instead of PrlVm_Unreg detaching all disks prior actually doing this to prevent images deletion. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
- 21 12月, 2015 3 次提交
-
-
由 Andrea Bolognani 提交于
Both detach and reattach are complex operations involving several steps, and it can be useful to be able to follow along by reading the log.
-
由 Andrea Bolognani 提交于
Since we don't detach unmanaged devices before attaching them to a domain, we shouldn't reattach them to rollback an error either.
-
由 Andrea Bolognani 提交于
We want to eventually factor out the code dealing with device detaching and reattaching, so that we can share it and make sure it's called eg. when 'virsh nodedev-detach' is used. For that to happen, it's important that the lists of active and inactive PCI devices are updated every time a device changes its state. Instead of passing NULL as the last argument of virPCIDeviceDetach() and virPCIDeviceReattach(), pass the proper list so that it can be updated.
-