- 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 5 次提交
-
-
由 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.
-
由 Michal Privoznik 提交于
In 50078cfb I've tried to fix distcheck but accidentally broke rpm build. The problem is that rpm build not only sets DESTDIR but also passes plugindir path. This results in double DESTDIR being in the plugin path, Drop one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Guido Günther 提交于
Mention that we run a command in that namespace
-
- 13 1月, 2016 8 次提交
-
-
由 Cole Robinson 提交于
Even though the Makefile has WITH_WIRESHARK guards, the _SOURCES variables are still processed when adding bits to the dist archive. plugin.c is a generated file that is only built when wireshark is enabled and it shouldn't be distributed, so use 'nodist'
-
由 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.
-
由 Michal Privoznik 提交于
Like everything we install, it should be prefixed with DESTDIR. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 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>
-
由 Cole Robinson 提交于
- Don't double check for expectName - actual is always non-NULL by this point, so don't check it either
-
由 Cole Robinson 提交于
Just handle it all in tools/Makefile.am. I verified the generated output looks similar to the pre patch output, but I didn't test it.
-
由 Michal Privoznik 提交于
So after da176bf6 and friend we have switched to $(wildcard some/path/*.xml) instead of enumerating the files explicitly. This is nice, however it makes distcheck build from VPATH fail. The reason is that it's is not obvious to what does the wildcard refer to: srcdir or builddir? Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 1月, 2016 21 次提交
-
-
由 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.
-
由 Andrea Bolognani 提交于
-
由 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>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. Note that not all '{.name = "interface",' entries are replaced, just those that have the common .help string of "interface name or MAC address". Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. Note that not all '{.name = "network",' entries are replaced, just those that have the common .help string of "network name or uuid". Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create common macros to be used generically. Replace the more commonly used "vol" option with a macro. This also adjusts 2 commands that didn't have the correct helpstr - 'vol-create-from' and 'vol-clone'. Both are described in the man page as taking vol, path, or key and the code uses the virshCommandOptVol instead of virshCommandOptVolBy. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. The macro will take a single argument _helpstr for the less common help string for each command option. Note that only file options using "OT_DATA" and "OFLAG_REQ" will be replace - others are left as is. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. The macro will take a single argument _helpstr which for many options in virsh-domain.c is simply "affect current domain". So, create a second macro within that file in order to define the more common use as a revector to the common macro with the common _helpstr. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. The macro will take a single argument _helpstr which for many options in virsh-domain.c is simply "affect running domain". So, create a second macro within that file in order to define the more common use as a revector to the common macro with the common _helpstr. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. The macro will take a single argument _helpstr which for many options in virsh-domain.c is simply "affect next boot". So, create a second macro within that file in order to define the more common use as a revector to the common macro with the common _helpstr. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. Note that not all '{.name = "persistent",' entries are replaced, just those that have the common .help string of "make live change persistent". Non replaced instances are unique to the command. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than continually cut-n-paste the strings into each command, create a common macro to be used generically. The macro will take a single argument _helpstr which will be used to pass the translatable helpstr since not all domain options can take the same string. The majority of the options take 'N_("domain name, id or uuid")', so create a separate macro with a _FULL suffix while those that do not take the same string will use the VIRSH_COMMON_OPT_DOMAIN macro. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The macro is slightly adjusted to add an argument "_helpstr". This will be passed as a translation macro string since other uses of the option may not have the same exact help string (such as is the case when the uuid is not suppliable for create commands). In virsh-pool.c - we'll create a singular VIRSH_COMMON_OPT_POOL_FULL in order to pass along the 'N_("pool name or uuid")' In virsh-volume.c there will be a VIRSH_COMMON_OPT_POOL_FULL and a VIRSH_COMMON_OPT_POOL_NAME, which passes 'N_("pool name")' for the commands that can only pass a name. There will also be a VIRSH_COMMON_OPT_POOL_OPTIONAL which is used for the command options which use OT_STRING and don't require the --pool argument. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id's 'cf793b00', 'e178688f', 'f9a6110f', '5372d49b', and 'e1937354' added new VSH_POOL_ macros; however, it was pointed out after push that commit id '834c5720' preferred use of VIRSH_ for the prefix over VSH_. So this patch just changes the VSH_ to VIRSH_ and it changes the naming format from VIRSH_<opt>_OPT_COMMON to VIRSH_COMMON_OPT_<opt>. Signed-off-by: NJohn Ferlan <jferlan@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".
-