After v6.3.0-rc1~64 a lease can have infinite expiry time. This
means that the expiration time will appear as a value of zero.
Do the expiration check only if the expiration time is not zero.
Fixes: 97a0aa2467
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
After v6.3.0-rc1~64 a lease can have infinite expiry time. This
means that the expiration time will appear as a value of zero.
Do the expiration check only if the expiration time is not zero.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1908053
Fixes: 97a0aa2467
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, bring variables that are used only within loops into
their respective loops. Secondly, drop 'error' label which is
redundant since we have @rv which holds the return value.
Thirdly, fix indendation in one case, the rest is indented
properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This function is misusing VIR_INSERT_ELEMENT() to behave like
VIR_APPEND_ELEMENT(). Use the latter to make it explicit what we
are trying to achieve.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We don't need to track the lease file size. Instead, we can
simply check if the file was empty by comparing the buffer the
file was read into with an empty string.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When adding a new lease by our leaseshelper then virLeaseNew() is
called. Here, we check for DNSMASQ_LEASE_EXPIRES environment
variable which is the expiration time for the lease. For infinite
lease time the value is zero. However, our code is not prepared
for that and adds "expiry-time" into the JSON file only if lease
expiry time is non-zero. This breaks the assumption that the
"expiry-time" attribute is always present (as can be seen in
virLeaseReadCustomLeaseFile() and virLeasePrintLeases()).
Store "expiry-time" always.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In virLeaseNew() we are trying to remove trailing space (per
comment it may happen that older versions of dnsmasq put it into
an env variable). Well, instead of open coding it, we can use
virTrimSpaces().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are some variables which are used only inside the single
loop the function has. Let's declare them inside the loop body to
make that obvious. Also, fix indendation.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If leasehelper fails all that we are left with is a simple error
message produced by dnsmasq:
lease-init script returned exit code 1
This is because the leasehelper did not write any message to
stderr. According to dnsmasq's manpage, whenever it's invoking
leasehelper the stderr is kept open:
All file descriptors are closed except stdin, which is open to
/dev/null, and stdout and stderr which capture output for
logging by dnsmasq.
As debugging leasehelper is not trivial (because dnsmasq invokes
it with plenty of env vars set - that's how data is passed onto
helper), let's print an error into stderr if exiting with an
error. And since we are not calling public APIs, we have to call
virDispatchError() explicitly and since we don't have any
connection open, we have to pass NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In v6.3.0-rc1~64 we've introduced ability to configure lease
time, but forgot to document the feature. Let's fix that.
Fixes: 97a0aa2467
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1908631
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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 <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
Currently translated at 3.1% (329 of 10440 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/bg/
Co-authored-by: Nickys Music Group <nickys.music.group@gmail.com>
Signed-off-by: Nickys Music Group <nickys.music.group@gmail.com>
Currently translated at 23.4% (2444 of 10440 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/pl/
Co-authored-by: Piotr Drąg <piotrdrag@gmail.com>
Signed-off-by: Piotr Drąg <piotrdrag@gmail.com>
In recent patches new mambers to _qemuAgentDiskAddress struct
were introduced to keep optional CCW address sent by the guest
agent. These two members are a struct to store CCW address into
and a boolean to keep track whether the CCW address is valid.
Well, we can hold the same information with a pointer - instead
of storing the CCW address structure let's keep just a pointer to
it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
On s390x, devices are attached to the channel IO subsytem by default,
so we need to look up scsi controllers via their CCW address there
instead of using PCI.
This fixes "virsh domfsinfo" on s390x for virtio-scsi devices (the first
attempt from commit f8333b3b0a did it in the wrong way, reporting the
device name on the guest side instead of the target name on the host side).
Fixes: f8333b3b0a ("qemu: Fix domfsinfo for non-PCI device information ...")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1858771
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
On s390x, devices are accessed via the channel subsystem by default,
so we need to look up the devices via their CCW address there instead
of using PCI.
This fixes "virsh domfsinfo" on s390x for virtio-block devices (the first
attempt from commit f8333b3b0a did it in the wrong way, reporting the
device name on the guest side instead of the target name on the host side).
Fixes: f8333b3b0a ("qemu: Fix domfsinfo for non-PCI device information ...")
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1858771
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Newer versions of the QEMU guest agent will provide the CCW address
of devices on s390x. Store this information in the qemuAgentDiskInfo
so that we can use this later.
We also map the CSSID 0 from the guest to the value 0xfe on the host,
see https://www.qemu.org/docs/master/system/s390x/css.html for details.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Make
./cpu-gather.py --gather --parse
an alias of
./cpu-gather.py [--gather] | ./cpu-gather.py --parse
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
More reliable, easier to parse, easier to edit.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This changes the invocation from
./cpu-gather.py | ./cpu-parse.sh
to
./cpu-gather.py [--gather] | ./cpu-gather.py --parse
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is a preparatory step to replace the output format with
something more readable.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Fixes the leaking file descriptors. Does not silently ignore errors
(e.g. permission denied on /dev/cpu/0/msr if run as non-root) and
always attempt to read from /dev/kvm if /dev/cpu/0/msr failed.
'gather_msr()' returns a dictionary of values, as a later patch will
add more registers to be interrogated.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is useful if cpuid was compiled from source in a non-standard
location.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Turn the comment on how to aquire cpuid into a runtime error message.
Use "http" instead of "https" in the URL, as the latter is broken.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some hardware, e.g. exotic platforms or pre-production hardware, may
report wrong or random data for the cpu model name. As the name of
the created files is derived from that name, this may lead to issues.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This changes the invocation from
./cpu-gather.sh | ./cpu-parse.sh
to
./cpu-gather.py | ./cpu-parse.sh
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the capabilities include a counter element, e.g.
<counter name='tsc' frequency='2591999000' scaling='no'/>
the XML could not be validated:
$ virsh capabilities > cap.xml
$ virsh [hypervisor-]cpu-compare cap.xml --validate
error: Failed to compare hypervisor CPU with cap.txt
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/cpu.rng
Did not expect element counter there
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The duplicate had the "dies" attribute missing, causing
$ virsh capabilities > cap.xml
$ virsh [hypervisor-]cpu-compare cap.xml --validate
to fail with
error: Failed to compare hypervisor CPU with cap.xml
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/cpu.rng
Invalid attribute dies for element topology
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
