The constants for maximum units on a bus are slightly tricky because for
the narrow bus it does not need to account for the extra unit used by
the controller, but the wide and super-wide ones need to.
With this patch a VMX with 64 disks on a pvscsi controller can be
properly parsed.
To properly handle the maximum numbers one of the conditions also needs
to be changed to not allow for units 16 and 65. This does not change
various conditionals in XML parsing and VMX formatting as they need a
significant rewrite. And since that is already working only with the
wide scsi controller (and not the super-wide one) we leave that refactor
for another day as it was done previously.
Tests show this is now possible and they fail before this change.
Resolves: https://redhat.atlassian.net/browse/RHEL-181350
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement domain reboot using the guest agent.
Implementation is very similar to the domain shutdown
added earlier.
Also, change the VIR_DOMAIN_REBOOT_ACPI_POWER_BTN flag
to VIR_DOMAIN_REBOOT_SIGNAL. Even though bhyve emulates
the ACPI button, it's triggered by sending a signal to the
bhyve process, so VIR_DOMAIN_REBOOT_SIGNAL looks like
a more accurate description of communication between
libvirt and bhyve.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement shutdown using a guest agent.
Implementation and behaviour is very similar to the one
found in the qemu driver.
The bhyveDomainShutdownFlags() function now supports
the VIR_DOMAIN_SHUTDOWN_SIGNAL and VIR_DOMAIN_SHUTDOWN_GUEST_AGENT.
If flags were not specified, try the agent first, and if it does
not work, proceed with the signal.
As we do not expect a response from the agent shutdown command,
we do not check qemuAgentShutdown()'s return value. Assume that the
command failed if the agent did not receive EOF, thus "priv->agent"
is not NULL.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemuDomainAuthorizedSSHKeysSet() call currently uses
VIR_AGENT_JOB_QUERY. While it's not an issue as this call does not
modify any of the libvirt-stored state, semantically it modifies
the domain, so VIR_AGENT_JOB_MODIFY fits better. Also, similar
calls like qemuDomainSetUserPassword() or qemuDomainSetTime()
already use VIR_AGENT_JOB_MODIFY, so use it in
qemuDomainAuthorizedSSHKeysSet() too.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The detach-interface virsh command requires domain (obviously)
and --type to identify <interface/>. Optionally, --mac can be
provided to chose from multiple interfaces. Well, that renders
--type argument redundant. I mean, if there are but unique MACs
within domain XML, then interface type is implied. If there are
duplicate MACs then --type can help to differentiate, though at
that point detach-device seems like a better fit.
Long story short, make --type optional.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The cleanup section in lxcDomainAttachDeviceNetLive() is
suspicious. It checks @ret for success and adds net into domain
definition. This is not something fits into cleanup. It belongs
right before 'ret = 0' line when we know everything before
succeeded. Moving that piece of code where it belongs, the
cleanup section becomes error because it is executed only in case
of failure.
Change the label to error, fix corresponding goto-s, and drop
@ret variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
During hotplug of an <interface/> into an LXC domain
(lxcDomainAttachDeviceNetLive()), the host side name of the
interface is stored in @veth variable. Well, all possible paths
that set the variable (virLXCProcessSetupInterfaceTap(),
virLXCProcessSetupInterfaceDirect()) document it is caller's
responsibility to free the memory. But it never does so.
==49848== 12 bytes in 2 blocks are definitely lost in loss record 68 of 1,763
==49848== at 0x4913888: malloc (vg_replace_malloc.c:447)
==49848== by 0x546F0BC: __vasprintf_internal (in /usr/lib64/libc.so.6)
==49848== by 0x5077A70: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50404DB: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x50405A4: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8400.4)
==49848== by 0x4A8591E: virNetDevGenerateName (virnetdev.c:3573)
==49848== by 0x4A93C38: virNetDevVethCreate (virnetdevveth.c:124)
==49848== by 0xED6C505: virLXCProcessSetupInterfaceTap (lxc_process.c:279)
==49848== by 0xED5F7A7: lxcDomainAttachDeviceNetLive (lxc_driver.c:3517)
==49848== by 0xED60D24: lxcDomainAttachDeviceLive (lxc_driver.c:3925)
==49848== by 0xED6262D: lxcDomainAttachDeviceFlags (lxc_driver.c:4453)
==49848== by 0xED62819: lxcDomainAttachDevice (lxc_driver.c:4485)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When staring an LXC domain (well, container) its consoles are
opened and each one is assigned an alias (for later use with
virDomainOpenConsole()). Now, before generating new alias the old
one is freed. But the old one can never be anything other than
NULL. The domain is inactive at this point (we are in process of
starting it, after all). And LXC driver does not support user
aliases, yet.
Just drop the pointless g_free().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'qemuValidateDomainDeviceDefVideo' ensures that only the correct video
device models are selected as well as that only QXL and VIRTIO video
devices can be selected as secondary.
Remove unnecessary checks and simplify the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virtio video device frontend type is either selected by the
post-parse code based on capabilities or provided by the user/existing
XML explicitly. No need to try to come up with a model when generating
commandline based on broken logic.
The difference in test output shows:
- honours user's config in case of the new 'device' attribute
- shows how incorrect fallback would be used for 'virtio-vga-gl'
(picked virtio-vga (non-gl) instead of 'virtio-gpu-gl')
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The currently existing checks are broken:
- only QEMU_CAPS_DEVICE_VHOST_USER_GPU is checked for vhostuser
backends (vhost-user-vga is actually separately packaged)
- the check for the 3d accelerated (-gl) versions checks only if one
of them exists (the commandline formatter picks a non-gl afterwards)
- 'virtio-vga'/'virtio-gpu' is not checked at all
The code also doesn't yet check if, when the user passes the new
'device' property manually the config actually makes sense.
To fix all of the above introduce a table of supported frontend devices
as well as properties that need to be checked for them.
This requires fixing a recently-introduced test case which shows a
nonsensical situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically 'virtio-vga' was always picked as the first '<video>'
(virtio) device and any sub-sequent ones were 'virtio-gpu'. When support
for aarch64 VMs was being added an exception to use 'virtio-gpu' for the
primary device was added as aarch64 doesn't have anything resembling the
"legacy" 'VGA' interface. At this point this exception was only for
aarch64. The distinction between 'virtio-vga' and 'virtio-gpu' was *not*
recorded in the VM XML as it was a new feature (for aarch64) and it
didn't make sense to pick 'virtio-vga'.
Some time later the following commit:
commit 4c029e8cfa
Author: Pavel Hrdina <phrdina@redhat.com>
Date: Fri Sep 30 14:41:37 2016 +0200
qemu_command: properly detect which model to use for video device
This improves commit 706b5b6277 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not. This is not a case only for arm/aarch64.
modified the code to do this picking by checking presence of
'virtio-vga' device instead. That approach didn't consider the fact that
the modular deployment of qemu allows for the 'virtio-vga' device to be
missing in certain cases, thus introducing a latent bug as we'll pick
'virtio-gpu' in such case but don't record it anywhere.
Now this creates a problem, if the deployments differ, because you can
have two *incompatible* (at migration stream level) setups which are
based on the same identical XML without the possibility for the
destination libvirt instance during migration to pick which is the
correct one.
To prevent this and actually fix any existing such deployment (which
allows upgrade of libvirt daemons on the source) we will record the
picked device frontend at post-parse time into the XML. This luckily
properly handles running VMs even if 'virtio-vga' were already
installed since we record the actual qemuCaps we've started the VM with.
Now 'virtio-vga' vs 'virtio-gpu' is not the only broken piece of logic.
In fact 'virtio-vga-gl' could have been downgraded to 'virtio-vga' based
on some very weird logic (see comments in code for explanation).
The logic in 'qemuDomainDeviceVideoDefPostParse' re-creates the logic
used to setup virtio-vga vs. virtio-gpu, and 'vhost-user-vga' vs.
'vhost-user-gpu' as those still make sense. For the 'gl' variants two
versions exist, one meant to recover running VMs and one for new VMs
where the broken logic makes no sense.
Now this patch just records what was selected into the XML, but doesn't
yet modify the commandline to actually use that value verbatim (e.g. if
the user specified an actual non-default value already).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There's no point in falling through to the check reporting invalid
type since if the code picks a model that one will be valid.
Reorganize the code so that we can return final decision right away.
This means that the two flags 'virtio' and 'virtioBusSuffix' need to be
set prior to the return.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a test case demonstrating the switch to 'virtio-gpu' on a host which
would normally pick 'virtio-vga'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU's commandline generator picks for virtio video between various
actual device models not only based on the XML definition but also
capabilities present. Since none of the devices is actually ABI
compatible we need to record the actually selected device in the XML.
Introduce 'device' attribute:
<video>
<model type='virtio' heads='1' primary='yes' device='virtio-gpu'/>
which will record the actually selected model so that we can preserve
ABI across restarts on deployment changes but more importantly across
migrations where the deployment differs.
The code specifically avoids an ABI stability check for the new field
because there are already possibly broken configurations that the users
may want to fix by picking the proper model which could be forbidden.
Users are instructed to not set the field in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add example of two running configs with distinct recorded capabilities
(presence of QEMU_CAPS_DEVICE_VIRTIO_VGA at startup) which will
demonstrate the recording of the picked actual device type on the
commandline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to previous patch add testing of 'virtio-gpu-gl' or
'virtio-vga-gl' with missing the respective capabilities, but this time
allowing VIR_DOMAIN_DEF_PARSE_ABI_UPDATE.
This will later on show that in case when the fallback can't be honoured
the code will not pick a device that doesn't support acceleration (the
non-gl variant).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability check in 'qemuValidateDomainDeviceDefVideo' which
validates whether a <video> definition with acceleration enabled is
possible is only aggregate, thus validates that any '-gl' video backend
is available.
Since qemu compiles each backend into a separate module it's possible to
have an installation where 'virtio-gpu-pci-gl' exist but 'virtio-vga-gl'
doesn't and it will not be rejected at validation. The commandline
though will generate a device *without* the '-gl' which is ABI
incompatible with the counterpart which does have '-gl', but the VM
starts. If such a VM is then migrated to a deployment which does have
the '-gl' variant available, migration will fail because qemu will
generate the '-gl' device as we don't record this fact in the XML.
This test case captures this situation which will be fixed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The test case shows that if the 'QEMU_CAPS_DEVICE_VIRTIO_VGA' capability
is not present (e.g. if the corresponding qemu module isn't installed)
libvirt will pick:
-device '{"driver":"virtio-gpu-pci", ...
instead of:
-device '{"driver":"virtio-vga", ...
but without any discernable difference in the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will add additional testing for various virtio-*-gl
devices, including filling of the default model. The output file needs
to not influnece the input for this test to work properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When querying capabilities for the default emulator with no other
arguments (e.g. 'virsh domcapabilities) fix error whithout emulator
installed an error is reported but the error would mention '(null)'
architecture:
# virsh domcapabilities
error: failed to get emulator capabilities
error: unsupported configuration: unable to find any emulator to serve '(null)' architecture
This happens as the error formatting takes 'archStr' which is NULL for
the default architecture instead of using 'arch' which is populated by
the host's architecture and converting it back.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the post parse code code didn't see these.
Apply the capability modification prior to running post parse code so
that defaults are properly picked based on the configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The user configuration of added/removed qemu capabilities via the qemu
namespace element was applied only right before generating a
commandline, but the validation code didn't see these.
Modify the validation entry points so that they apply this optionally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move and rename the function to 'qemuDomainUpdateCustomCapabilities' and
modify the arguments so that it will be possible to reuse it also in the
post-parse and validation code which ought to base decisions on the same
logic as VM startup would.
Since copying of the qemu capabilities object is very expensive (I've
observed an almost 4x slowdown of qemuxmlconftest)
'qemuDomainUpdateCustomCapabilities' copies the capabilities only when
necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patch will add a function which will need to optionally copy
passed capabilities for modification. Export 'virQEMUCapsNewCopy'
outside of tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'capability_filters' allows admins to globally disable some qemu
capabilities via the config file.
Until now it was applied only directly when starting the VM, but that is
too late as the capability is still present when e.g. the post-parse
code is picking defaults.
Rework the code so that 'capability_filters' is applied directly after
probing qemu so all existing capabilities will lack the filtered out
ones.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new parameter was added as part of commit ee06a78790 ("remote: allow
passing argv to the ext transport").
Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Switch from openSUSE Leap 15.5 to 16.0. Not just CI build job,
but also codestyle_job which runs on Leap too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bhyveConnectAgent() function calls qemuAgentOpen() to open an agent
connection. If it fails, e.g. because of insufficient permissions to
open the socket, it returns NULL. Currently, if that happens,
bhyveConnectAgent() just sets agentError to true and exits with 0.
This does not match the contract of bhyveDomainEnsureAgent(), which
should either provide an agent connection or fail.
Fix that by returning -1 when qemuAgentOpen() fails. To make intent
clearer, add a documentation for bhyveConnectAgent().
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
bhyve supports populating SMBIOS fields. Each
field is set using the -o option, such as:
-o system.product_name=Virt-Manager
There are 4 groups of options:
- bios.*
- system.*
- board.*
- chassis.*
As a side note, the '-o' option can be used
for setting options not related to the SMBIOS fields.
Extend virBhyveProcessBuildBhyveCmd() to build the appropriate
arguments for what's specified in the domain's
`<sysinfo type='smbios'>` section.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the bhyve driver reboot implementation
does not take into account domain's on_reboot action.
Update it so it shuts a domain down on reboot when it is
configured this way.
Additionally, introduce the bhyveDomainShutdownSignal() helper
which shares a common shutdown and reboot implementation
using a signal.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the bhyve driver shutdown implementation
does not take into account domain's on_poweroff action.
Update it so it reboots a domain on shutdown when it is
configured this way.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Trying to pass STDIO fds to a virCommand is very bad and test cases must
not do that.
Same way with invalid FDs.
Add code which makes qemuxmlconftest fail if any test case would attempt
that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add 'errors' field for tracking a list of errors and
'virTestDummyFDContextMarkError' function to add to the list.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'virTestDummyFDContext' was a copy of GHashTable to be able to register
a cleanup function. Upcoming patches will want to track more data
together with the hash table so turn virTestDummyFDContext into a proper
struct which contains the hash table.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
glib's G_REGEX_OPTIMIZE invokes pcre's JIT optimizer which requires
writable executable memory. On hosts with SELinux this by default caused
AVC denials to be logged. The solution in Fedora's SELinux policy was
to allow execmem for e.g. virtqemud, but e.g. virtlogd or
libvirt_leaseshelper on the other hand got a 'dontaudit' rule.
Now the optimizer itself does have a substantial effect; I've measured
around 3x speedup when matching VIR_LOG_REGEX against a sample of a qemu
VM log file. On the other hand, only 3 out of 10 uses of 'g_regex_new'
used the flag and also none of the regexes which used 'G_REGEX_OPTIMIZE'
are on a hot path:
- virDomainQemuMonitorEventStateRegisterID
Used only when custom qemu monitor event callback is registered,
which resides in libvirt_qemu.so so noone will actually use this
in production.
- virCommandRunRegex
Used in:
- virStorageBackendFileSystemNetFindNFSPoolSources
Invoked only via API on output of 'showmount'. Unlikely to ever
see lots of data.
- virStorageBackendLogicalFindLVs
- virStorageBackendLogicalGetPoolSources
- virStorageBackendLogicalRefreshPool
Invoked on output of lvs/pvs/vgs. Neither of them are likely to
ever see lots of output to match.
- virISCSIGetSession
- virISCSIScanTargetsInternal
Invoked on output of iscsiadm, unlikely to see lots of data.
- virLogProbablyLogMessage
- virLXCProcessIgnorableLogLine
- domainLogContextReadFiltered
Both of the above are used on code paths processing log output
when failure to startup a VM process or one of the helper
processes for devices for a qemu domain. Thus they are not invoked
on success and the processed buffer is capped to 1k of data.
Since none of the above are on anything resembling a hot path and thus
likely to substantially benefit from the optimizer, and we do have
plenty of other uses without optimization, drop the optimizations
everywhere and add a note to sc_G_REGEX_OPTIMIZE that we're currently
avoiding the use of this flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
glib's G_REGEX_OPTIMIZE flag for regex operations implies the use of
pcre's JIT optimizer for regexes which requires writable executable
memory for the optimized code.
Security frameworks such as SELinux can restrict program's access to
writable executable memory to harden the code.
glib's implementation of the regex functions handles downgrade to
interpreted evaluation of regexes gracefully if writable executable
memory is unavailable, but that is non-obvious and has a performance
penalty.
Add a syntax check which requires all uses of G_REGEX_OPTIMIZE to be
annotated so that the reader of the code can be hinted to why
G_REGEX_OPTIMIZE should perhaps be avoided.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainInitializePflashStorageSource() always attaches a non-NULL
src->backingStore used as an empty virStorageSource chain terminator
(type VIR_STORAGE_TYPE_NONE). qemuValidateDomainDefNvram() incorrectly
interpreted every non-NULL backingStore as a genuine backing overlay and
reported VIR_ERR_CONFIG_UNSUPPORTED, so legitimate UEFI/NVRAM setups were
rejected.
Use 'virStorageSourceHasBacking' helper as the check.
Fixes: d57630c282
Signed-off-by: Fima Shevrin <efim.shevrin@virtuozzo.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Do not reject setvcpu --enable --async or setvcpus --guest --async in virsh.
For setvcpu, async only affects live unplug and is documented as having no
effect when enabling vCPUs. For setvcpus, guest+async is a driver-visible flag
combination; drivers should decide whether they can support it. Keep virsh
validation limited to API-level constraints and let drivers report unsupported
combinations.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The vCPU APIs have API-specific flag enums that alias the generic
VIR_DOMAIN_AFFECT_* values for live and config state.
Use the vCPU-specific aliases in the public API checks, QEMU driver flag masks,
and virsh flag construction. The values are unchanged; this is only a
consistency cleanup.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
On monolythic kernel /sys/modules/*/drivers may not exist (ENOENT)
On kernels with enhanced security (e.g. grsecurity), it might not be
accessible: EACCESS or EPERM.
Directly try to open if it fails with any of those errors, we fallback
on the module name.
Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When modules.alias is not available (e.g. monolithic kernel),
virPCIDeviceFindBestVFIOVariant() would fail, causing the entire
PCI device detach to abort.
Instead, log a warning and return success with no variant found,
allowing the caller to fall back to the generic vfio-pci driver.
Signed-off-by: Baptiste Daroussin <baptiste.daroussin@ovhcloud.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virt-aa-helper calls virStorageSourceGetMetadata before adding a disk
path to a domain's apparmor profile. This probes the device and may
trigger an AppArmor denial when the disk is an AoE device under
/dev/etherd/.
The return value of virStorageSourceGetMetadata is not checked, so the
denial has no functional impact but results in noisy dmesg logs.
Explicitly deny read access to /dev/etherd/e*.* in the virt-aa-helper profile to
avoid these spurious denials.
Co-Authored-By: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: PUSHKARAJ PATIL <pushkaraj.patil@in.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement the domainAuthorizedSSHKeys{Get,Set} APIs using
the guest agent.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement the domainSetUserPassword API for setting user
password using the guest agent.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implement the domain{Get,Set}Time APIs for getting and setting
domain time.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, bhyveDomainQemuAgentCommand() uses
bhyveDomainAgentAvailable()
which works only if the agent was already initialized.
It should use bhyveDomainEnsureAgent() instead.
Also, remove the bhyveDomainAgentAvailable() function,
there are no cases when it should be used instead of
bhyveDomainEnsureAgent().
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Martin Kletzander
Roman Bogorodskiy
Michal Privoznik
Peter Krempa
Mark Cave-Ayland
Fima Shevrin
Akash Kulhalli
Baptiste Daroussin
PUSHKARAJ PATILandPeter Krempa