Q35 machine types 2.3 and older had an integrated floppy controller.
Support for these machine types was removed by QEMU commit
commit 86165b499edf8b03bb2d0e926d116c2f12a95bfe
q35: Remove old machine versions
git describe: v2.5.0-1530-g86165b499e contains: v2.6.0-rc0~76^2~4
In libvirt, we have bumped the minimum QEMU version to 2.11:
commit b4cbdbe90bbf85eaf687f532d5a52a11e664b781
qemu: Formally deprecate support for qemu < 2.11
git describe: v7.3.0-13-gb4cbdbe90b contains: v7.4.0-rc1~300
Since this QEMU version only supports Q35 machine versions 2.4+,
remove the code dealing with older ones.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This patch also includes propagation of flags into the
virNetworkDefParse().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Where easily possible, declare variables with g_auto to reduce
the amount of calls in cleanup sections.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
In all three cases (LXC, QEMU and VBox drivers) the caller has
access to host capabilities and thus know the maximum NUMA node.
This means, that virHostMemAllocPages() doesn't have to query
it. Querying may fail if libvirt was compiled without numactl
support.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In all three cases (LXC, QEMU and VBox drivers) the caller has
access to host capabilities and thus know the maximum NUMA node.
This means, that virHostMemGetFreePages() doesn't have to query
it. Querying may fail if libvirt was compiled without numactl
support.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
A logic bug in the code creating overlays on existing images resulted
into wrongly using "luks" instead of "qcow2" for the backing format if
the backing image is an luks-encrypted qcow2. The special format munging
is needed only for raw luks images.
In practice the impact is not as critical as to use encrypted images in
the backing chain the user must fully describe the backing chain
including backing images to provide encryption keys, which overrides the
metadata recorded in the qcow2 header.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions have this option so there's no need for us
to base it on the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All QEMU versions we support have these and it's very unlikely that they
will be removed. Remove the capability checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'set-numa-node' is the command which can set the equivalent parameters
to '-numa' in preconfig mode, so we can use it as witness to see that
-numa is supported.
To ensure that the old detection method is removed once we'll be bumping
qemu support add a comment with the appropriate version check.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions have all the fields so we can remove the
booleans controlling which fields are used on the monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuMonitorJSONCheckError instead of handcrafted error reporting.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to automatic memory freeing and remove the cleanup section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
They are no longer used as we now assume that all tuning caps are
present and in case some will be removed we'll need to use different
probing methods.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All currently supported qemu versions support all throttling
capabilities. It is unlikely that any of the fields will be removed in
the future and if it will we will need to do specific probing which is
possible via the 'throttle' object which is the replacement for the
legacy way to configure throttling.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The configurability of the number of dies in a CPU can be inferred from
the presence of the 'die-id' field in 'query-hotpluggable-cpus'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Probing QEMU_CAPS_DRIVE_DISCARD and QEMU_CAPS_DRIVE_DETECT_ZEROES can be
replaced by looking into the QMP schema rather than looking at -drive
which isn't in use any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make it more obvious that we care about passing FDs on the commandline
before startup of qemu, which is used to avoid startup monitor polling.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU_CAPS_CHARDEV_RECONNECT, QEMU_CAPS_CHARDEV_LOGFILE and
QEMU_CAPS_CHARDEV_FILE_APPEND can be probed from the appropriate fields
in 'chardev-add' probed via the QMP schema instead of the command line
parameters.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a comment that will attempt to discourage adding new capabilities
based on 'query-command-line-options'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a cross reference of the enum value name with the string
representation. This allows a quick cross-reference of the values
without having to open the header and implementation files separately.
To achieve this the checker code at first obtains a list of the
flags and cross-references them when checking the grouping in
syntax-check, thus we are guaranteed to stay in sync.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Further commits will be refactoring and minimizing capabilities being
parsed from 'query-command-line-options'. Group the struct driving the
detection by argument name so it's easier to spot options belonging
together.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Based on kernel commit messages the interface is
/sys/class/fc/fc_udev_device/appid_store
where we need to write the following string "$INODE:$APPID".
$INODE is the VM root cgroup inode in hexadecimal and $APPID is user
provided string that will be attached to each FC frame for the VM
within the cgroup identified by inode and has limit 128 bytes.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Libvirt assumes that a SCSI bus can fit up to 8 devices
(including controller itself), except for so called wide bus
which can accommodate up to 16 devices (again, including
controller). This plays important role when computing 'drive'
address in virDomainDiskDefAssignAddress(). So far, the only
driver that enables wide SCSI bus is VMX. But with newer
releases, ESX is capable of "super wide" bus (64 devices).
We can blindly bump the limit in our code because then we would
compute address that's invalid for older ESX versions that we
still want to support.
Unfortunately, I haven't found a better place where to store this
than virDomainDef.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the QEMU driver is configured to use the old "file" stdio
handler (meaning virtlogd is out of the picture) and a chardev
has a log file configured we rely on QEMU being able to create
the file itself. This may not be always possible (e.g. if the
logfile is set to a directory that QEMU process can't reach).
In such case we should create the file and just pass its FD to
QEMU.
We could do that unconditionally and just either pass FD from
virtlogd or the one we opened, because we bumped QEMU version
and are now requiring new enough QEMU. However, I'm keeping the
old style where logfile is appended on the cmd line for the tests
sake.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1989457
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Tested-by: Ján Tomko <jtomko@redhat.com>
Again, we don't need full driver, just its config.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Tested-by: Ján Tomko <jtomko@redhat.com>
The function doesn't really need domain object, but domain
definition from which it takes seclabels.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Tested-by: Ján Tomko <jtomko@redhat.com>
We didn't always save status xml after generating new taint message
which resulted in it being deleted in case of a libvirtd restart.
Some taint messages were preserved thanks to saving status xml
separately at the end of the calling functions. With this, every taint
message is saved, regardless of the calling functions.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1965589
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'devMountsPath' and 'devMountsSavePath' are NULL terminated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'devMountsPath' can be converted to an auto-cleared stringlist and thus
asking for the number of entries is not necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only caller is passing a NULL terminated string list as
'devMountsPath' thus we don't need to get the count of elements.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The value of 'next' is copied into 'item.file' so we can move the update
to the 'next' pointer earlier and move the VIR_APPEND_ELEMENT call to
where we figure out that we need to append the value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We always process the full list so there's no value in storing the count
separately.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We always process the full list so there's no value in storing the count
separately.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously they were stored in two separate arrays. This way it's
obvious when referencing the same one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
