-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] master from libvirt:master #2918
Conversation
When removing rotated log files, their name is matched against a regex (@log_regex) and if they contain '.N' suffix the 'N' is then parsed into an integer. Well, due to a bug in virLogCleanerParseFilename() this is not how the code works. If the suffix isn't found then g_match_info_fetch() returns an empty string instead of NULL which then makes str2int parsing fail. Just check for this case before parsing the string. Based on the original patch sent by David. Reported-by: David Negreira <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
While the function is exported via header, the symbol itself was not. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…ation Some of the checks make sense only after the address is allocated and thus we need to re-do the validation after the address is assigned. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…un-assigned addresses When hot-plugging a FS device with un-assigned address with a bootindex the recently-added validation check would fail as validation on hotplug is done prior to address assignment. To fix this problem we can simply relax the check to also pass on _NONE addresses. Unsupported configurations will still be caught as previous commit re-checks the definition after address assignment prior to hotplug. Resolves: https://issues.redhat.com/browse/RHEL-39271 Fixes: 4690058 Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
When the 'pages' job is configured to run 'on_success' it's skipped if any other pipeline fails. This is bad in cases such as if an external service runs out of CI minutes as the web stops being updated. Since the 'artifacts' of the 'website_job' are generated only if that phase succeeds this will update the web when the web part is buildable. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Fixes: 296b6ba Signed-off-by: Peter Krempa <[email protected]>
Currently translated at 73.6% (7703 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 73.1% (7643 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
Currently translated at 99.7% (10418 of 10442 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/ Translated using Weblate (Korean) Currently translated at 99.7% (10413 of 10442 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/ Co-authored-by: 김인수 <[email protected]> Signed-off-by: 김인수 <[email protected]>
Currently translated at 87.3% (9119 of 10442 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ru/ Co-authored-by: Sergey A <[email protected]> Signed-off-by: "Sergey A." <[email protected]>
Signed-off-by: Jiri Denemark <[email protected]>
Signed-off-by: Jiri Denemark <[email protected]>
Signed-off-by: Andrea Bolognani <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
When attempting to run: libvirt.git/_build # ./run --selinux ./src/libvirtd the following error is thrown: Refusing to change selinux context of file './src/libvirtd' outside build directory which is obviously wrong. The problem is 'being inside of build directory' is detected by simple progpath.startswith(builddir). While builddir is an absolute path, progpath isn't necessarily. And while looking into the code, I've noticed chcon() function accessing variable outside its scope when printing out the path it's working on. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
We never release the reference on the GSource created for interrupting the main loop, nor do we remove it from the main context if our thread is woken up prior to the wakeup callback firing. This can result in a leak of GSource objects, along with an ever growing list of GSources attached to the main context, which will gradually slow down execution of the loop, as several operations are O(N) for the number of attached GSource objects. Reviewed-by: Michal Privoznik <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
The udevInterfaceGetXMLDesc method takes a reference on the udev driver as its first action. If the virCheckFlags() condition fails, however, this reference is never released. Reviewed-by: Peter Krempa <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
The %meson_test macro expands to have a newline at the start, so rather than expanding to VIR_TEST_DEBUG=1 meson test .... we get VIR_TEST_DEBUG=1 meson test .... which has no effect, since VIR_TEST_DEBUG isn't exported. Reviewed-by: Peter Krempa <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
While __attribute((sentinel)) (exposed by glib under G_GNUC_NULL_TERMINATED macro) is a gcc extension, it's supported by clang too. It's already being used throughout our code but some functions that take variadic arguments and expect NULL at the end were lacking such annotation. Fill them in. After this, there are still some functions left untouched because they expect a different sentinel than NULL. Unfortunately, glib does not provide macro for different sentinels. We may come up with our own, but let's save that for future work. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Ján Tomko <[email protected]>
…AddErrorResponse() The qemuMonitorTestAddErrorResponse() function is a printf-like function. But the annotation was mistakenly done in .c file instead of corresponding .h file rendering the annotation ineffective. Move the annotation to the header file. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Ján Tomko <[email protected]>
Currently translated at 100.0% (10442 of 10442 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/ Co-authored-by: 김인수 <[email protected]> Signed-off-by: 김인수 <[email protected]>
Currently translated at 74.0% (7743 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
This copies the behaviour of the native builds that disable -Werror on Fedora, since frequently updating toolchains and deps often introduce new warnings. Reviewed-by: Pavel Hrdina <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
Currently translated at 74.4% (7782 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 74.2% (7762 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 74.0% (7743 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
We have a non-trivial amount of architecture-specific logic dealing with TPM, so it's good to have coverage for it. Note that two architectures currently don't have support for TPM devices enabled by default in QEMU: loongarch64 and s390x. The situation might change for the former, but that's unlikely to happen for the latter. Signed-off-by: Andrea Bolognani <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
The default-models tests provide coverage for these scenarios now. Signed-off-by: Andrea Bolognani <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
TPM 1.2 is a pretty bad default these days, especially for architectures which were introduced when TPM 2.0 already existed. We're already carving out exceptions for several scenarios, but that's basically backwards: at this point, using TPM 1.2 is the exception. Restructure the code so that it reflects reality and we don't have to remember to update it every time a new architecture is introduced. Signed-off-by: Andrea Bolognani <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Everywhere we use TPM 2.0 as our default, the chances of TPM 1.2 being supported by the guest OS are very slim. Just reject such configurations outright. Signed-off-by: Andrea Bolognani <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
We link to libsasl2.so, so get a dep on cyrus-sasl-libs automatically. The dep on cyrus-sasl-gssapi gets us the mechanism that matches our default config. The 'cyrus-sasl' package merely contains some man pages and the saslauthd daemon, which is not required by libvirt. This dep appears to have been redundant since we first added in commit 1b1d647 Author: Daniel P. Berrangé <[email protected]> Date: Wed Dec 5 15:24:15 2007 +0000 Initial integration of SASL authentication, working for Kerberos only Reviewed-by: Michal Privoznik <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
We currently hardcode the systemd unitdir, but it is desirable to be able to choose a different location in some cases. For examples, Fedora flatpak builds change the RPM %_unitdir macro, but we can't currently honour that. Reviewed-by: Michal Privoznik <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>
Change the 'include' in the AppArmor policy to use 'include if exists' when including <uuid>.files. Note that 'if exists' is only available after AppArmor 3.0, therefore a #ifdef check must be added. When the <uuid>.files is not present, there are some failures in the AppArmor tools like the following, since they expect the file to exist when using 'include': ERROR: Include file /etc/apparmor.d/libvirt/libvirt-8534a409-a460-4fab-a2dd-0e1dce4ff273.files not found Signed-off-by: Georgia Garcia <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
The current "building from git" test uses "test -d .git"; however, that doesn't work when libvirt is used as a submodule, as in that case .git is a normal file. Use "test -e .git" instead. Signed-off-by: John Levon <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
New element 'openfiles' had confusing name. Since the patch with this new element wasn't propagate yet, old name ('rlimit_nofile') was changed. ... <binary> <openfiles max='122333'/> </binary> ... Signed-off-by: Adam Julis <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
If there are absent values in an already existing element specifying rom settings, we simply use the old ones. This behaviour is not desired, as users might think that deleting the element from XML would delete the setting (because the hotplug succeeds) - which does not happen. Because of that, we should not accept an interface without elements that cannot be changed. Therefore, we should not allow absent values for already existing rom setting during hotplug. Resolves: https://issues.redhat.com/browse/RHEL-7109 Signed-off-by: Kristina Hanicova <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
In cases when a QEMU process takes longer than the time sigterm and sigkill are issued to kill the process do not simply fail and leave the VM in state VIR_DOMAIN_SHUTDOWN until the daemon stops. Instead set up an fd on /proc/$pid and get notified when the QEMU process finally has terminated to cleanup the VM state. Resolves: https://issues.redhat.com/browse/RHEL-28819 Signed-off-by: Boris Fiuczynski <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
The new option style renamed one of the cache modes. https://issues.redhat.com/browse/RHEL-50329 Signed-off-by: Ján Tomko <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
This capability tracks whether QEMU has acpi-erst device. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Kristina Hanicova <[email protected]>
The aim of pstore device is to provide a bit of NVRAM storage for guest kernel to record oops/panic logs just before the it crashes. Typical usage includes usage in combination with a watchdog so that the logs can be inspected after the watchdog rebooted the machine. While Linux kernel (and possibly Windows too) support many backends, in QEMU there's just 'acpi-erst' device so stick with that for now. The device must be attached to a PCI bus and needs two additional values (well, corresponding memory-backend-file needs them): size and path. Despite using memory-backend-file this does NOT add any additional RAM to the guest and thus I've decided to expose it as another device type instead of memory model. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Kristina Hanicova <[email protected]>
Nothing special going on here. Resolves: https://issues.redhat.com/browse/RHEL-24746 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Kristina Hanicova <[email protected]>
The acpi-erst backend for pstore device exposes a path in the host accessible to the guest and as such we must set seclabels on it to grant QEMU RW access. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Kristina Hanicova <[email protected]>
Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Kristina Hanicova <[email protected]>
…of 0 If dry run of a command was requested (virCommandSetDryRun()) then a specified callback is called instead of running actual command. This is meant to be used in tests. To mimic running the command as closely as possible the callback can also set exit status of the command it's implementing. To save some lines though, the exit status is initialized to 0 so that callback has to set it only on failures. Now, 0 is not exactly portable value - that's why stdlib.h has EXIT_SUCCESS (and EXIT_FAILURE) values. Initialize the exit status (held in dryRunStatus) to EXIT_SUCCESS then. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
dmidecode always puts a newline character at the end of each OEM string it prints. It's the dmi_oem_strings() function [1] that iterates over strings and calls pr_attr() over each one which puts "\n" at the end, unconditionally [2[. Since it's not part of the string though, trim it. 1: https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/dmidecode.c#n2431 2: https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/dmioutput.c#n63 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
Introduce a test case for sysinfotest. The data was obtained by running dmidecode as libvirt would run it: dmidecode -q -t 0,1,2,3,4,11,17 Now, the expected output fits almost perfectly, except for OEM strings where the third string looks nothing like in the dmidecode output. This is because of testDMIDecodeDryRun() which overwrites the third OEM string (see v6.5.0-rc1~214 for more info). But that's okay for now. Speaking of OEM strings, it's worth noticing two 'OEM Strings' sections in the dmidecode output. This is causing some troubles and will be fixed in next commit. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
On some systems, there are two or even more 'OEM Strings' sections in DMI table. Here's an example of dmidecode output on such system: # dmidecode -q -t 11 OEM Strings String 1: Default string OEM Strings String 1: ThunderX2 System String 2: cavium.com String 3: Comanche Now, this poses a problem, because when one tries to obtain individual strings, they get: # dmidecode -q --oem-string 1 Default string ThunderX2 System # dmidecode -q --oem-string 2 No OEM string number 2 cavium.com NB, the "No OEM string number 2" is printed onto stderr and everything else onto stdout. Oh, and trying to get OEM strings from just one section doesn't fly: # dmidecode -q -H 0x1d --oem-string 2 Options --string, --type, --handle and --dump-bin are mutually exclusive This means two things: 1) we have no way of distinguishing OEM strings at the same index but in different sections, 2) because of how virSysinfoDMIDecodeOEMString() is written, we fail in querying OEM string that exists in one section but not in the others (for instance string #2 from example above). While there's not much we can do about 1), there is something that can be done about 2) - refine the error condition and make the function return an error iff there's nothing on stdout and there's something on stderr. Resolves: https://issues.redhat.com/browse/RHEL-45952 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
As can be seen in earlier commits, there can be two OEM strings with the same index. But since our parser (virSysinfoParseOEMStrings()) doesn't expect that, it increments index in each run and thus skips over these strings. Fortunately, we have the right index at hand - we're just skipping over it in a loop. Just reconstruct the index back inside the loop. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Jiri Denemark <[email protected]>
Currently translated at 47.9% (5032 of 10497 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/en_GB/ Co-authored-by: Andi Chandler <[email protected]> Signed-off-by: Andi Chandler <[email protected]>
Currently translated at 82.1% (8643 of 10516 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 81.8% (8603 of 10516 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 81.6% (8583 of 10516 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
Signed-off-by: Jiri Denemark <[email protected]>
Introduced only a couple of commits ago (in v10.5.0-84-g90e50e67c6) the pstore device acts as a nonvolatile storage, where guest kernel can store information about crashes. This device, however, expects a file in the host from which the crash data is read. So far, we expected users to provide a path, but we can autogenerate one if missing. Just put it next to per-domain's NVRAM stores. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Andrea Bolognani <[email protected]>
There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]> Reviewed-by: Boris Fiuczynski <[email protected]>
Currently translated at 82.5% (8679 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 82.3% (8663 of 10516 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ Co-authored-by: Weblate <[email protected]> Signed-off-by: Fedora Weblate Translation <[email protected]>
Currently translated at 82.3% (8663 of 10516 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
Currently translated at 100.0% (10508 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ko/ Co-authored-by: 김인수 <[email protected]> Signed-off-by: 김인수 <[email protected]>
So far we are relying on QEMU or sysadmin to create the file for pstore. This is suboptimal as in the case of the former we can not set proper seclabels (there's nothing to set seclabels on until QEMU is started). Therefore, make sure the file is created before launching QEMU and that it has the correct size. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Andrea Bolognani <[email protected]>
The whole point of pstore device is that the guest writes crash dumps into it. But the way SELinux label is set on the corresponding file warrants RO access only. This is due to a copy-paste from code around: kernel/initrd/DTB/SLIC - these are RO indeed, but pstore MUST be writable too. In a sense it's closer to NVRAM/disks - hence set imagelabel on it. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Andrea Bolognani <[email protected]>
Thank you for your interest in the libvirt project. Since this repository is a read-only mirror of the project's master We kindly request that contributors fork the project at https://gitlab.com/libvirt/libvirt/ push changes to the fork, and then open a new merge request at https://gitlab.com/libvirt/libvirt/-/merge_requests/new Thank you for your time and understanding. |
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )