- 26 1月, 2016 7 次提交
-
-
由 Daniel P. Berrange 提交于
The VIR_DOMAIN_STATS_VCPU flag to virDomainListGetStats enables reporting of stats about vCPUs. Currently we only report the cumulative CPU running time and the execution state. This adds reporting of the wait time - time the vCPU wants to run, but the host scheduler has something else running ahead of it. The data is reported per-vCPU eg $ virsh domstats --vcpu demo Domain: 'demo' vcpu.current=4 vcpu.maximum=4 vcpu.0.state=1 vcpu.0.time=1420000000 vcpu.0.wait=18403928 vcpu.1.state=1 vcpu.1.time=130000000 vcpu.1.wait=10612111 vcpu.2.state=1 vcpu.2.time=110000000 vcpu.2.wait=12759501 vcpu.3.state=1 vcpu.3.time=90000000 vcpu.3.wait=21825087 In implementing this I notice our reporting of CPU execute time has very poor granularity, since we are getting it from /proc/$PID/stat. As a future enhancement we should prefer to get CPU execute time from /proc/$PID/schedstat or /proc/$PID/sched (if either exist on the running kernel) Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Peter Krempa 提交于
Idioms are usually weird and obscure when translated literally.
-
由 Peter Krempa 提交于
Report error: invalid argument: requested vcpu '100' is not present in the domain instead of error: invalid argument: requested vcpu is higher than allocated vcpus
-
由 Peter Krempa 提交于
Remove unnecessary condition and variable.
-
由 Peter Krempa 提交于
The array doesn't necessarily have the same cardinality as the count of vCPUs for a domain. Iterating it can cause access beyond the end of the array.
-
由 Peter Krempa 提交于
Counterintuitively the user would end up with a VM with maximum number of vCPUs available. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1290324
-
由 Peter Krempa 提交于
Next patch will add minimum checking, so use a more generic name. Refactor return values to the commonly used semantics.
-
- 25 1月, 2016 5 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1266088 We are missing this value for cdrom-image device. It seems like there's no added value to extend this to other types of disk devices [1]. 1: https://www.redhat.com/archives/libvir-list/2016-January/msg01038.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Since 'savevm' was not converted to QMP libvirt has to parse for error strings in the text monitor output. One of the unhandled errors is produced when qemu treats a device as unmigratable. As current qemu actually does support AHCI migration this bug is applicable only to older versions of qemu. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1293899
-
由 Peter Krempa 提交于
Unify few error conditions into a single error reporting case.
-
由 Roman Bogorodskiy 提交于
Make bhyveload respect boot order as specified by os.boot section of the domain XML or by "boot order" for specific devices. As bhyve does not support a real boot order specification right now, it's just about choosing a single device to boot from.
-
由 Roman Bogorodskiy 提交于
These functions are going to be used by the Bhyve driver.
-
- 23 1月, 2016 1 次提交
-
-
由 Laine Stump 提交于
libvirt always resets the MAC address of the physdev used for macvtap passthrough when the guest is finished with it. This was happening prior to the 802.1Qb[gh] DISASSOCIATE command, and was quite often failing, presumably because the driver wouldn't allow the MAC address to be reset while the association was still active, with a log message like this: virNetDevSetMAC:168 : Cannot set interface MAC to 00:00:00:00:00:00 on 'eth13': Cannot assign requested address This patch changes the order - we now do the 802.1Qb[gh] disassociate and delete the macvtap interface first, then and reset the MAC address.
-
- 22 1月, 2016 8 次提交
-
-
由 Cole Robinson 提交于
'free' on fedora23 wants to use the Slab field for calculated used memory. The equation is: used = MemTotal - MemFree - (Cached + Slab) - Buffers We already set Cached and Buffers to 0, do the same for Slab and its related values https://bugzilla.redhat.com/show_bug.cgi?id=1300781
-
由 Cole Robinson 提交于
'free' on Fedora 23 will use MemAvailable to calculate its 'available' field, but we are passing through the host's value. Set it to match MemFree, which is what 'free' will do for older linux that don't have MemAvailable https://bugzilla.redhat.com/show_bug.cgi?id=1300781
-
由 Cole Robinson 提交于
We virtualize bits of /proc/meminfo by replacing host values with values specific to the container. However for calculating the final size of the returned data, we are using the size of the original file and not the altered copy, which could give garbelled output.
-
由 Cole Robinson 提交于
Reverse the conditional at the start so we aren't stuffing all the logic in an 'if' block
-
由 Ian Campbell 提交于
... and consolidate the cmdline/extra/root parsing to facilitate doing so. The logic is the same as xl's parse_cmdline from the current xen.git master branch (e6f0e099d2c17de47fd86e817b1998db903cab61). On the formatting side switch to producing cmdline= instead of extra=. Update a few tests and add serveral more. - test-cmdline is added to test the exclusive use of cmdline. - test-fullvirt-direct-kernel-boot.cfg is updated due to the switch on the formatting side and now tests the exclusive use of cmdline=. - Tests are added for both paravirt and fullvirt where the .cfg uses extra= and (paravirt only) root=. These are format (xl->xml) only since the inverse will generate cmdline= hence is not a round trip (which was already true if using root=, which used to generate extra= on the way back). - Tests are added for both paravirt and fullvirt where the .cfg declares cmdline= as well as bogus extra= and (paravirt only) root= entries which should be ignored. Again these are format only tests since the inverse won't include the bogus lines. The last two bullets here required splitting the DO_TEST macro into two halves, as is done in the xmconfigtest.c case. In order to introduce a use of VIR_WARN for logging I had to add virerror.h and VIR_LOG_INIT. Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
-
由 Joao Martins 提交于
As suggested in a previous thread [0] this patch adds some missing calls to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info operations which would otherwise lead to memory leaks. [0] https://www.redhat.com/archives/libvir-list/2015-September/msg00519.htmlSigned-off-by: NJoao Martins <joao.m.martins@oracle.com>
-
由 Jim Fehlig 提交于
Add "Xen XL Config" to the virErrorDomain enum and use it in src/xenconfig/xen_xl.c.
-
由 Jim Fehlig 提交于
The virErrorDomain enum has VIR_FROM_XEN, VIR_FROM_XEND, VIR_FROM_XENSTORE, VIR_FROM_SEXPR, and VIR_FROM_XENXM. Use these elements in the corresponding .c files. While at it, remove the VIR_FROM_THIS define in src/xenconfig/xenxs_private.h.
-
- 21 1月, 2016 3 次提交
-
-
由 Jiri Denemark 提交于
The corresponding event in QEMU is called MIGRATION_PASS. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 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>
-
由 Dmitry Andreev 提交于
When acpi is used to reboot/shutdown qemu domain, qemu emits SHUTDOWN event. Libvirt uses fakeReboot variable in order to differentiate reboot or shutdown. fakeReboot value is reseted to false after domain restart/reset. When mode=agent is used to reboot qemu domain, qemu doesn't emit SHUTDOWN event and libvirt doesn't reset fakeReboot value to false. In this case next 'shutdown -h now' performs reboot. That's why we don't need to set fakeReboot=true for mode=agent. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 20 1月, 2016 10 次提交
-
-
由 Cole Robinson 提交于
The generated output is dependent on perl hashtable ordering, which gives different results for i686 and x86_64. Fix this by sorting the hash keys before iterating over them https://bugzilla.redhat.com/show_bug.cgi?id=1173641
-
由 Ján Tomko 提交于
Instead of nested ifs, jump out early. Mostly whitespace changes.
-
由 Ján Tomko 提交于
We do not care if the mac was specified in the delete section, we are going to delete the record anyway.
-
由 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 2 次提交
-
-
由 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>
-