Prepare the parser code and anything using 'virStorageNetHostTransport'
to support passing a FD instead of opening the connection by qemu
itself.
For now this just prepares the parser and data structures, but the code
is dormant.
Only code paths which will actually support FD passing will then enable
it in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Spellchecked-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use a 'switch' statement instead of a bunch of if statements to do
validation and selection what to parse.
Remove the pre-clearing of the struct as we always allocate cleared
memory for it and we can reorder assignments to avoid the need for
cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the refactor to use proper enum type for the network transport the
'transport' variable is no longer filled. Remove it and fix the error
message which references it without using NULLSTR.
Fixes: 452695926d
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the 'dataStore' is internally represented as a virStorageSource
object it has provisions for nesting which is not supported.
When I've reviewed and modified the commit adding data file parsing
support I've added code that was supposed to reject any 'backingStore'
and 'dataStore' structures nested in a source of a 'dataStore'.
Unfortunately the check was broken as one of the terms checked the
presence of parent's 'backingStore' instead of the nesting.
Fix it and add tests.
Fixes: b3171cf8da
Resolves: https://issues.redhat.com/browse/RHEL-85320
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In esxConnectListAllDomains if the lookup of the VM name and UUID fails
for a single VM (possible e.g. with broken storage) the whole API would
return failure even when there are working VMs.
Rework the lookup so that if a subset fails we ignore the failure on
those. We report an error only if lookup of all of the objects failed.
Failure is reported from the last one.
Resolves: https://issues.redhat.com/browse/RHEL-80606
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we mandate version 3, any remaining conditional checks
in meson/source code can be removed.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 19eb8abc9a.
There is no longer any need to dynamically generate version specific
rules. This revert can be reverted, if the need ever arises again
in the future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 63a312fa2d.
There is no longer any need to dynamically generate version specific
rules. This revert can be reverted, if the need ever arises again
in the future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
By assuming version 3, we can drop all the conditional version
substitutions from the profiles.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We can now assume at least version three:
* Debian 12: 3.0.8
* openSUSE Leap 15.5: 3.0.4
* openSUSE Leap 15.6: 3.1.7
* Ubuntu 22.04: 3.0.4
* Ubuntu 24.04: 4.0.0
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This comment is wrong as later qemuMigrationSrcRun() is called which
checks if TLS should be used and activated. QEMU has built-in support
for TLS, which this refers to.
The comment originates from a time when tunneled support was the only
way to get encryption.
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
When invoking virDomainSaveParams with a relative path, the image is
saved to the daemon's CWD. Similarly, when providing virDomainRestoreParams
with a relative path, it attempts to restore from the daemon's CWD. In most
configurations, the daemon's CWD is set to '/'. Ensure a relative path is
converted to absolute before invoking the driver domain{Save,Restore}Params
functions.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit 28a0621528 added support to restore
sparse images but changed the boolean that controls if we open the file
as read-only or read-write. Editing XML in the save image resulted in
following error message:
failed to write header to domain save file '/data/images/fedora40.save': Bad file descriptor
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
So far, we only process NIC_RX_FILTER_CHANGED event when the
corresponding device has 'trustGuestRxFilters' enabled. And the
event is emitted only for virtio model. IOW, this is fairly
limited situation and other scenarios don't emit any event (e.g.
change of MAC address on a PCI passthrough device).
Resolves: https://issues.redhat.com/browse/RHEL-7035
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The aim off this event is to notify management application that
guest changed MAC address on one of its vNICs so the app can
update its internal records, e.g. for finding match between
guest/host view of vNICs.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If a guest changes MAC address on its vNIC, then QEMU emits
NIC_RX_FILTER_CHANGED event (the event is emitted in other cases
too, but that's not important right now). Now, domain XML allows
users to chose whether to trust these events or not:
<interface trustGuestRxFilters='yes|no'/>
For the 'no' case no action is performed and the event is
ignored. But for the 'yes' case, some host side features of
corresponding vNIC (well tap/macvtap device) are tweaked to
reflect changed MAC address. But what is missing is reflecting
this new MAC address in domain XML.
Basically, what happens is: the host sees traffic with new MAC
address, all tools inside the guest see the new MAC address
(including 'virsh domifaddr --source agent') which makes it
harder to match device in the guest with the one in the domain
XML.
Therefore, report this new MAC address as another attribute of
the <mac/> element:
<mac address="52:54:00:a4:6f:91" currentAddress="00:11:22:33:44:55"/>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In the two cases when we know that the command returned failure switch
to the new error code so that management applications can
programatically detect failure of the guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a special error code for when the guest agent returned a failure
message.
Allow management applications to deterministically detect failure of the
guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the error constant appearing add docs hinting that this
new error code can be produced on timeouts.
The most relevant place is to do it when setting the timeout.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the agent disappears after geting a proper command we ought to
report the same error code as if we timed out as it's uncertain whether
the guest agent did anything.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the guest agent code uses timeouts it is possible that we stop
waiting before the guest agent replies. If this happens while syncing
everything is okay because we didn't send any state-changing command.
In case when the timeout happens after a real command was transmitted
it's unknown if the guest-agent processed it or not.
Use the new special error code VIR_ERR_AGENT_COMMAND_TIMEOUT for cases
when we sent non-sync commands, so that the management applications or
users have possibility to react to this situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a new special error code for guest agent commands.
The error code will be specifically reported only when an actual command
(not a sync) was issued to the guest agent and the timeout time was
reached.
This will allow users and management applications to differentiate
between the cases when the sync timed out and thus there's no risk in
the agent actually having executed the command and when the actual
command was sent.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a 'New features' entry for mapped-ram itself, and another
for the parallel save/restore feature built on top.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commits c2518f7bc7 and 28a0621528 introduced build failures on 32-bit
platforms by using incorrect format specifiers with g_strdup_printf.
In one case, an 'unsigned long' format specifier is used with a
'long long int' variable. Fix by changing the format specifier to
'uintmax_t', and casting the variable likewise.
In a second case, an 'unsigned long' format specifier is used with a
'size_t' variable, which is 'unsigned int' on 32-bit systems. Fix by
changing the format specifier to use the 'z' modifier.
Fixes: c2518f7bc7
Fixes: 28a0621528
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Option --parallel-channels would require changing configuration file to
be used so introduce this option as well to make it convenient for
users.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We should use the newest API only when user sets parallel-channels.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
We should use the newest API only when user sets parallel-channels.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to use extra flag in addition to the new
"parallel.channels" param.
Using the flag without param would result in using uninitialized
variable. Fixing it would result in error that parallel channels cannot
be less then 1 or setting 1 as default.
Using the param without the flag is ignored.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to have --parallel and --parallel-channels especially
when --parallel on its own is the same as not used at all. In both cases
libvirt will default to single channel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
There is no need to have --parallel and --parallel-channels especially
when --parallel on its own is the same as not used at all. In both cases
libvirt will default to single channel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Peter Krempa
Daniel P. Berrangé
Jiri Denemark
김인수
Andi Chandler
Harikumar Rajkumar
Michal Privoznik
Philipp Schuster
Jim Fehlig
Weblate
Pavel Hrdina
Boris Fiuczynski
Nicolás Gal
Ján Tomko
hsu zangmen
Sergey A
Jim Fehlig via Devel