- 20 1月, 2016 7 次提交
-
-
由 Ján Tomko 提交于
The comment is relevant to the ADD action, not DEL.
-
由 Ján Tomko 提交于
Introduce a function for printing the leases on the 'init' operation.
-
由 Ján Tomko 提交于
Introduce virLeaseReadCustomLeaseFile which will populate the new leases array with all the leases, except for expired ones and the ones matching 'ip_to_delete'. This removes five variables from main().
-
由 Ján Tomko 提交于
We either use the value from the environment variable, or learn it from the existing lease file. In the second case, the pointer would be pointing into the JSON object of the first lease with a DUID, owned by leases_array, then leases_array_new. Always allocate the string instead, making obvious who should free the string.
-
由 Ján Tomko 提交于
If dnsmasq specified DNSMASQ_IAID (so we're dealing with an IPv6 lease) but no DNSMASQ_MAC, we skip creation of the new lease object. Also skip adding it to the leases array. https://bugzilla.redhat.com/show_bug.cgi?id=1202350
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1265694 In order to be able to process disk storage pool's using a multipath device to handle the partitions, libvirt_parthelper will need a way to not automatically add a partition separator "p" to the generated device name for each partition found. This is designed to mimic the multipath features known as 'user_friendly_names' and custom 'alias' name. If the part_separator attribute is set to "no", then generation of the multipath partition name will not include the "p" partition separator unless the source device path name ends with a number. The generated partition names that get passed back to libvirt are processed in order to find the device mapper multipath (dm-#) path device. For example, device path "/dev/mapper/mpatha" would create partitions "/dev/mapper/mpatha1", "/dev/mapper/mpatha2", etc. instead of "/dev/mapper/mpathap1", "/dev/mapper/mpathap2", etc. If the device path ends with a number "/dev/mapper/mpatha1", then the algorithm to generate names "/dev/mapper/mpatha1p1", "/dev/mapper/mpatha1p2", etc. would be utilized. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add a new storage pool source device attribute 'part_separator=[yes|no]' in order to allow a 'disk' storage pool using a device mapper multipath device to not add the "p" partition separator to the generated device name when libvirt_parthelper is run. This will allow libvirt to find device mapper multipath devices which were configured in /etc/multipath.conf to use 'user_friendly_names' or custom 'alias' names for the LUN.
-
- 19 1月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
Since we pass dummy variables @fdout and @fdoutlen into virNetClientProgramCall() we make it alloc @fdout array (even though it's an array of 0 elements since vitlogd can hardly pass us some FDs at this stage). Nevertheless, it's an allocation not followed by free(): ==29385== 0 bytes in 60 blocks are definitely lost in loss record 2 of 1,009 ==29385== at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29385== by 0x54B99EF: virAllocN (viralloc.c:191) ==29385== by 0x56821B1: virNetClientProgramCall (virnetclientprogram.c:359) ==29385== by 0x563B304: virLogManagerDomainReadLogFile (log_manager.c:272) ==29385== by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485) ==29385== by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660) ==29385== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==29385== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==29385== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) ==29385== by 0x217F71A4: qemuProcessStart (qemu_process.c:5152) ==29385== by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396) ==29385== by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So I can observe this crasher that with freshly started daemon (and virtlogd enabled) I am trying to startup a domain that immediately dies (because it's said to use huge pages but I haven't allocated a single one in the pool). Hardly reproducible with -O0 or under valgrind. But I just got lucky: ==20469== Invalid write of size 8 ==20469== at 0x4C2E99B: memcpy@GLIBC_2.2.5 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20469== by 0x217EDD07: qemuProcessReadLog (qemu_process.c:1670) ==20469== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==20469== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==20469== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) ==20469== by 0x217F71A4: qemuProcessStart (qemu_process.c:5152) ==20469== by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396) ==20469== by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450) ==20469== by 0x21846845: qemuDomainCreate (qemu_driver.c:7468) ==20469== by 0x5611CD0: virDomainCreate (libvirt-domain.c:6753) ==20469== by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613) ==20469== by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589) ==20469== Address 0x27a52ad0 is 0 bytes after a block of size 5,584 alloc'd ==20469== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20469== by 0x9B8D1DB: xdr_string (in /lib64/libc-2.21.so) ==20469== by 0x563B39C: xdr_virLogManagerProtocolNonNullString (log_protocol.c:24) ==20469== by 0x563B6B7: xdr_virLogManagerProtocolDomainReadLogFileRet (log_protocol.c:123) ==20469== by 0x164B34: virNetMessageDecodePayload (virnetmessage.c:407) ==20469== by 0x5682360: virNetClientProgramCall (virnetclientprogram.c:379) ==20469== by 0x563B30E: virLogManagerDomainReadLogFile (log_manager.c:272) ==20469== by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485) ==20469== by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660) ==20469== by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696) ==20469== by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957) ==20469== by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955) This points to memmove() in qemuProcessReadLog(). Imagine we just read the following string from qemu: "abc\n2016-01-18T09:40:44.022744Z qemu-system-x86_64: Error\n" After the first pass of the while() loop in the qemuProcessReadLog() (in which we have taken the false branch in the if) @buf still points to the beginning of the string, @filter_next points to the beginning of the second line. So we start second iteration because there is yet another newline character at the end. In this iteration @eol points to it actually. Now, the control gets inside true branch of if(). Just to remind you: got = 58 filter_next = buf + 5, eol = buf + 58. Therefore skip = 54 which is correct. The message we want to skip is 54 bytes long. However: memmove(filter_next, eol + 1, (got - skip) +1); which is memmove(filter_next, eol + 1, 5) is obviously wrong as there is only one byte we can access, not 5! Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 1月, 2016 2 次提交
-
-
由 Martin Kletzander 提交于
When building with gcc-5 (particularly gcc-5.3.0 now) and having pdwtags installed (package dwarves) make check fails with the following error: $ make lock_protocol-struct GEN lock_protocol-struct --- lock_protocol-structs 2016-01-13 15:04:59.318809607 +0100 +++ lock_protocol-struct-t3 2016-01-13 15:05:17.703501234 +0100 @@ -26,10 +26,6 @@ virLockSpaceProtocolNonNullString name; u_int flags; }; -enum virLockSpaceProtocolAcquireResourceFlags { - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1, - VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2, -}; struct virLockSpaceProtocolAcquireResourceArgs { virLockSpaceProtocolNonNullString path; virLockSpaceProtocolNonNullString name; Makefile:10415: recipe for target 'lock_protocol-struct' failed make: *** [lock_protocol-struct] Error 1 That happens because without any specific options gcc doesn't keep enum information in the resulting binary object. I managed to isolate the parameters of gcc that caused this issue to disappear, however I remember that they influenced the resulting binaries quite a bit and were definitely not something we would want to add as mandatory to the build process. So to deal with this cleanly, let's take that enum and separate it out to its own header file. Since it is only used in the lockd driver and the protocol, lock_driver_lockd.h feels like a suitable name. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Wido den Hollander 提交于
This was reported in bug #1298024 where r would be filled with the return code of rbd_open(). Should rbd_snap_unprotect() fail for any reason the virReportSystemError call would return 'Success' since rbd_open() succeeded. https://bugzilla.redhat.com/show_bug.cgi?id=1298024Signed-off-by: NWido den Hollander <wido@widodh.nl>
-
- 15 1月, 2016 6 次提交
-
-
由 Jiri Denemark 提交于
A device tree binary file specified by /domain/os/dtb element is a read-only resource similar to kernel and initrd files. We shouldn't restore its label when destroying a domain to avoid breaking other domains configure with the same device tree. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Kernel/initrd files are essentially read-only shareable images and thus should be handled in the same way. We already use the appropriate label for kernel/initrd files when starting a domain, but when a domain gets destroyed we would remove the labels which would make other running domains using the same files very unhappy. https://bugzilla.redhat.com/show_bug.cgi?id=921135Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Yaniv Kaul 提交于
We have this function qemuAgentNotifyEvent() which is supposed to be called from thread pool responsible for processing qemu monitor events. The function then should wake up other thread that is waiting for a guest to shutdown or reboot. However, if we have received a different error a warning is printed out. This warning lacks info on which event is expected. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit id '90b721e4' moved where the virCgroupAddTask was made until after the check for the vcpupin checks. However, in doing so it missed an option where if the cpumap didn't exist, then the code would continue back to the top of the current vcpu loop. The results was that the virCgroupAddTask wouldn't be called. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
This reverts commit ae09988e. Since commit id '71ce4759' has been reverted, this one is no longer necessary.
-
由 John Ferlan 提交于
This reverts commit 71ce4759. Since commit id 'a41c00b4' has been reverted, this no longer is necessary
-
- 14 1月, 2016 3 次提交
-
-
由 John Ferlan 提交于
This reverts commit a41c00b4. After much testing and upstream discussion this has been deemed to be the incorrect operation since it means we no longer have any guarantee about which resource controllers the QEMU processes in general are in.
-
由 Cédric Bosdonnat 提交于
There is no need to deny writes on a readonly mount: write still won't be accepted, even if the user remounts the folder as RW in the guest as qemu sets the 9p mount as ro. This deny rule was leading to problems for example with readonly /: The qemu process had to write to a bunch of files in / like logs, sockets, etc. This deny rule was also preventing auditing of these denials, making it harder to debug.
-
由 John Ferlan 提交于
Commit id '7bf3198d' neglected to initialize deflate leading to a possibility if model allocation/checks fail, then the VIR_FREE(deflate) would be erroneous. Noted by Jan Tomko.
-
- 13 1月, 2016 3 次提交
-
-
由 Michal Privoznik 提交于
So, you try to start a domain, but before we even get to the part where chardev part of qemu command line is generated (and possibly missing path to unix sockets is made up) an error occurs which results in calling qemuProcessStop. This will then try to clean up the mess and possibly ends up calling unlink(NULL). ==8085== Thread 3: ==8085== Syscall param unlink(pathname) points to unaddressable byte(s) ==8085== at 0xA85EA57: unlink (in /lib64/libc-2.21.so) ==8085== by 0x213D3C24: qemuProcessCleanupChardevDevice (qemu_process.c:2866) ==8085== by 0x558D6B1: virDomainChrDefForeach (domain_conf.c:22924) ==8085== by 0x213DA9AE: qemuProcessStop (qemu_process.c:5326) ==8085== by 0x213DA2F2: qemuProcessStart (qemu_process.c:5190) ==8085== by 0x2142957F: qemuDomainObjStart (qemu_driver.c:7396) ==8085== by 0x214297DB: qemuDomainCreateWithFlags (qemu_driver.c:7450) ==8085== by 0x21429842: qemuDomainCreate (qemu_driver.c:7468) ==8085== by 0x5611B95: virDomainCreate (libvirt-domain.c:6753) ==8085== by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613) ==8085== by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589) ==8085== by 0x568BF41: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==8085== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==8085== Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
Commit ec63000a missed checking the return value of regcomp(), which coverity promptly identified.
-
由 Jim Fehlig 提交于
Commmit fd2e3c4c used the domctl version 8 structure for version 9 in the xen_getdomaininfolist union, resulting in insufficient buffer size (and subsequent memory corruption) for the GETDOMAININFOLIST ioctl. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 12 1月, 2016 17 次提交
-
-
由 Dmitry Andreev 提交于
Autodeflate can be enabled/disabled for memballon device of model 'virtio'. xml: <devices> <memballoon model='virtio' autodeflate='on'/> </devices> qemu: qemu -device virtio-balloon-pci,...,deflate-on-oom=on Autodeflate cannot be enabled/disabled for running domain.
-
由 Dmitry Andreev 提交于
Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
-
由 Dmitry Andreev 提交于
Excessive memory balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. QEMU memballoon device has a feature to release some memory at the last moment before some process will be get killed by OOM-killer. Introduce a new optional balloon device attribute 'autodeflate' to enable or disable this feature.
-
由 Cole Robinson 提交于
On every socket connect(2) attempt we were re-launching session libvirtd, up to 100 times in 5 seconds. This understandably caused some weird load races and intermittent qemu:///session startup failures https://bugzilla.redhat.com/show_bug.cgi?id=1271183
-
由 Cole Robinson 提交于
When we autolaunch libvirtd for session URIs, we spin in a retry loop waiting for the daemon to start and the connect(2) to succeed. However if we exceed the retry count, we don't explicitly raise an error, which can yield a slew of different error messages elsewhere in the code. Explicitly raise the last connect(2) failure if we run out of retries.
-
由 Cole Robinson 提交于
- Add some debugging - Make the loop dependent only on retries - Make it explicit that connect(2) success exits the loop - Invert the error checking logic
-
由 Roman Bogorodskiy 提交于
Commit 2b6f6ad6 introduced the virxdrdefs.h header with common definitions to be included in the protocol files, but logging/log_protocol.x was missed, so add it there as well. Hopefully this fixes build on OS X.
-
由 Ben Gray 提交于
When we are receiving data in smaller chunks it might happen that virNetServerClientDispatchRead() will be called multiple times. And as that happens, if it is a message that also transfer headers, we decode the number of them every single time and, unfortunately, also allocate the memory for them. That causes a leak, in the best scenario. Best viewed with '-w'. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
if instanceId is NULL When virNetDevVPortProfileGetStatus() was called with instanceId = NULL (which is the case for all DISASSOCIATE requests in 802.1Qbh) it would log the following error: Could not find netlink response with expected parameters even though the disassociate had been successfully completely. Then, due to the fortunate coincidence of status having been initialized to 0 and then not changed when the "failure" was encountered, it would still return a status of 0 (PORT_VDP_RESPONSE_SUCCESS), so the caller would assume a successful operation. This would result in a spurious log message though, and would fill in LastErrorMessage, so that the API would return that error if it happened during cleanup from some other error. That, in turn, would lead to an incorrect supposition that the response to the port profile disassociate was the cause of the failure. During debugging, I noticed that the VF in question usually had *no uuid* associated with it (big surprise)by the time the disassociate completed, so the solution is *not* to send the previous instanceId down. This patch fixes virNetDevVPortProfileGetStatus() to only check the VF's uuid in the status if it was given an instanceId to check against when originally called. Otherwise it only checks that the particular VF is present (it will be). This does cause a slight difference in behavior - rather than returning with status unchanged (and thus always 0) it will actually get the IFLA_PORT_RESPONSE. This could lead to revelation of error conditions we were previously ignoring. Or not. So far "not".
-
由 Laine Stump 提交于
Use the VIR_TRISTATE_SWITCH_* enums appropriately. No functional change.
-
由 Laine Stump 提交于
Use virDomainDefAddUSBController() to add an EHCI1+UHCI1+UHCI2+UHCI3 controller set to newly defined Q35 domains that don't have any USB controllers defined.
-
由 Laine Stump 提交于
This new function will add a single controller of the given model, except the case of ich9-usb-ehci1 (the master controller for a USB2 controller set) in which case a set of related controllers will be added (EHCI1, UHCI1, UHCI2, UHCI3). These controllers will not be given PCI addresses, but should be otherwise ready to use. "-1" is allowed for controller model, and means "default for this machinetype". This matches the existing practice in qemuDomainDefPostParse(), which always adds the default controller with model = -1, and relies on the commandline builder to set a model (that is wrong, but will be fixed later).
-
由 Laine Stump 提交于
We need a virDomainDefAddController() that doesn't check for an existing controller at the same index (since USB2 controllers must be added in sets of 4 that are all at the same index), so rather than duplicating the code in virDomainDefMaybeAddController(), split it into two functions, in the process eliminating existing duplicated code that loops through the controller list by calling virDomainControllerFind(), which does the same thing).
-
由 Laine Stump 提交于
The real Q35 machine puts the first USB controller set (EHCI+(UHCIx4)) on bus 0 slot 0x1D, and the 2nd USB controller set on bus 0 slot 0x1A, so let's attempt to make the virtual machine match that for controllers with auto-assigned addresses when possible. Three test cases were added to assure that the proper addresses are assigned - one with a single set of unaddressed USB controllers, one with 3 (to grab both preferred slots plus one more), and one with the order of the controller definitions reordered, to assure that the auto-assignment isn't mixed up by order.
-
由 Laine Stump 提交于
When qemuAssignDevicePCISlots() is looking for companion controllers for a USB controller that has no PCI address specified, it initializes a virDevicePCIAddress to 0000:00:00.0, fills it in with the companion's address if one is found, then checks whether or not there was a find based on slot == 0. On a system with a single PCI bus, that is a valid way to check, because slot 0 is reserved, but on most other PCI buses, slot 0 is not reserved, and is open for use by any device. This patch adds a separate bool that is set when a companion is found rather than relying on the faulty information provided with "slot == 0".
-
Some of the protocol files already include handing of the missing int types such as xdr_uint64_t, some don't. To fix it everywhere, move out of the appropriate defines to the utils/virxdrdefs.h file and include it where needed. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
OpenBSD uses 'struct sockpeercred' instead of 'struct ucred'. Add a configure check that detects its presence and use if in the code that could be compiled on OpenBSD. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-