This is logically enforced by existing checks, thus we can formalize it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In at least one case we've wanted a mandatory argument which requires
the explicit flag. Fix the assumption before converting everything over
to the new flags.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add 'positional' and 'required' fields to vshCmdOptDef, which will
explicitly track the two properties of arguments.
To ensure that we have proper coverage, add checks to
vshCmddefCheckInternals validating the state of the above flags by
infering it from existing data.
This conversion will allow us:
- remove VSH_OT_DATA in favor of VSH_OT_STRING
- use VSH_OT_INT when required both as positional and non-positional
- properly annotate which VSH_OT_ARGV are positional and which are not
(currently inferred by whether an previous positional option exists)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's just one command taking a list of domains as argument, thus
declare it inline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Declare one argument per line, separate disticnt conditions by newline,
move some checks earlier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract flag check to a separate variable and replace ternary operators
by normal conditions and use allocated buffer instead of a static one
to improve readability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract flag check to a separate variable and replace ternary operators
by normal conditions and directly output the text rather than using
extra variable to improve readability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Store the pointers to 'help' and 'description' information in the struct
directly rather than in a key-value list.
The generic approach never got any extra use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new option dumps the full help outputs for every command so that
it's possible to conveniently check that subsequent refactors will not
impact any of the external functionality.
No man page entry is needed as the command is internal/undocumented.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some description of virsh commands referenced itself in a multi-line
example of usage, which is pointless as virsh help already shows how to
use the command:
.data = N_("Get or set the current memory parameters for a guest"
" domain.\n"
" To get the memory parameters use following command: \n\n"
" virsh # memtune <domain>")
Change it to just state what the command does and leave the example for
the help printer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use a switch statement to cover all cases and check for missing
completers for arguments declared as VSH_OT_ARGV.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's obvious that a command is an alias when the 'alias' property is
set, thus an extra flag is redundant. Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a check that the default 0 assignment will not mean that an option
is considered to be VSH_OT_BOOL.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The command invoking the code is internal and meant for developers,
there's no point in translating the errors.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the clients use the 'command set' approach and other pieces of
code such as the command validator already assume that command groups
are in use. Remove the unused 'command set' stuff.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In a few cases (CH driver) we want
virCapabilitiesDomainSupported() just to check whether given
virtType is supported and report a different error message (that
suggests how to solve the problem). Introduce reportError
argument which makes the function report an error iff set.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In near future we will want to check whether capabilities for
given virtType exist, but report an error on our own. Introduce
reportError argument which makes the function report an error iff
set.
In one specific case (virQEMUCapsGetDefaultVersion()) we were
even overwriting (more specific) error message reportd by
virCapabilitiesDomainDataLookup(). Drop that too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
If the host doesn't have /dev/kvm nor /dev/mshv, i.e. CH driver
is unable to run any guests, then an error is reported. But the
usual thing to do here is print an info message into the logs and
return VIR_DRV_STATE_INIT_SKIPPED. It is a recoverable error
after all.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As of previous commit, the CH driver checks for /dev/kvm and/or
/dev/mshv presence. In order to make chxml2xmltest work
regardless of host configuration, introduce a mock that pretends
both of these files are accessible.
Fixes: 51c14df967
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Change the default to modern qcow2 as it's supported by all qemu
versions supported by libvirt and in fact 'qemu-img' already defaults to
the new format for a long time.
Some Unittests require changes to pass, now that version 1.1 is default.
Unittests like `qcow2-1.1.argv` may not be relevant anymore, but this
patch doesn't affect them.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/602
Signed-off-by: Abhiram Tilak <atp.exp@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Remove some code repetition between desc and net-desc commands.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When editing the title of a domain or network via the `desc` or
`net-desc` commands, we strip the final newline that is added by some
editors.
Do the same when editing the description as well.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similar to other VIR_ERR_NO_* errors, we don't want to spam the daemon
log with these messages.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce the domdisplay-reload command to make the domain reload
its graphics certificates
#virsh domdisplay-reload <domain> --type <type>
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'display-reload' QMP command had been introduced from QEMU 6.0.0:
9cc0765165
Currently it only supports reloading TLS certificates for VNC.
Resloves: https://issues.redhat.com/browse/RHEL-16333
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The new virDomainGraphicsReload API is used to make the domain reload
its certificates without restart, and avoid service interruption.
Currently, only QEMU VNC TLS certificates are supported, but
flags are also reserved for subsequent scenarios.
To reload QEMU VNC TLS certificates as an example, we can call:
virDomainGraphicsReload(domain, 0, 0);
Then the specified QMP message would be send to QEMU:
{"execute": "display-reload", "arguments":{"type": "vnc", "tls-certs": true}}
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'display-reload' QMP command was introduced in QEMU 6.0.0, so we
add a compatible capability to check if target QEMU binary supports it.
{"execute":"display-reload", "arguments":{"type": "vnc", "tls-certs": true}}
The new QMP refer to:
9cc0765165
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Cloud-Hypervisor is capable of running VMs with kvm or mshv as the
hypervisor on Linux Host. Guest to hypevisor ABI with mshv hypervisor is
the same as in the case of VIR_DOMAIN_VIRT_HYPERV. So, VIR_DOMAIN_VIRT_HYPERV
type will be reused to represent the config with Linux Host and mshv as the
hypervisor.
While initializing ch driver, check if either of /dev/kvm or /dev/mshv
device is present on the host. Before starting ch domains, check if the
requested hypervisor device is present on the host.
Users can specify hypervisor in ch guests's domain definitions like
below:
<domain type='kvm'>
_or_
<domain type='hyperv'>
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Praveen K Paladugu <praveenkpaladugu@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With Unix mode, pass a socket path to cloud-hypervisor.
Cloud-Hypervisor will attach guest's serial port to this socket path.
Users can connect to the serial port using one of the following commands:
`socat -,crnl UNIX-CONNECT:<path/to/socket>`
OR
`minicom --device unix#<path/to/socket>`
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Unix Socket backend is only supported for serial port in
cloud-hypervisor. Add relevant checks in chValidateDomainDeviceDef.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using check='none' when starting a domain with a CPU model marked as
usable is no longer needed as libvirt will do the right thing even with
check='partial'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Currently all machine types which do honour '-usb' are already covered
by code which will either select a proper controller model or would
select the same one which '-usb' would use.
Thus all of the legacy -usb controller code can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'virt*' machines already don't allow downgrade
- 'versatilepb' and 'realview' machines use 'pci-ohci' controller with '-usb'
- all other machines ignore '-usb' (some have sysbus-based USB
controller which we don't even consider)
For the 'versatilepb' and 'realview' machines libvirt would already
resort to picking either an existing controller model or trying to pick
the one which '-usb' would select and thus fail either way.
All other machine types ignore it.
We can thus remove the fallback for all arm-based machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'pseries' machines already don't allow downgrade
- 'g3beige' and 'mac99' machines use 'pci-ohci' controller with '-usb'
- all other machines ignore '-usb'
For 'g3beige' and 'mac99' libvirt already has 'pci-ohci' as contoller it
would select as one of the options when picking a model, thus it's
impossible to reach situation when '-usb' would be honoured.
All other machine types ignore it.
We can thus remove the fallback for all ppc-based machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The default USB device auto-selection code for 'pseries' machines picks
controller models which are also selected when '-usb' is used thus it's
impossible to end up in the case when using '-usb' would be possible:
$ qemu-system-ppc64 --machine pseries,usb=on
qemu-system-ppc64: could not find a module for type 'nec-usb-xhci'
$ qemu-system-ppc64 --machine pseries-2.5,usb=on
qemu-system-ppc64: could not find a module for type 'pci-ohci'
Remove the impossible downgrade and adjust tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'q35' machine type already explicitly forbids fallback
- 'isapc' never supported USB and '-usb' is ignored
- 'i440fx' does support '-usb' and translates it into 'piix3-uhci' which
is identical to what libvirt selects
- we currently don't care about 'microvm'
Attempting to start an 'pc' (i440fx) machine with -usb when 'piix3-uhci'
is compiled out will fail and in any other case libvirt will use the
proper explicitly selected controller.
Drop the '-usb' downgrade for x86 arch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This controller is used as the default/implicit USB controller by
multiple machine types which honour the '-usb' flag of qemu. Add it as
fallback in libvirt too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The machine types historically have a default USB controller populated
via '-usb' which libvirt assumed implicitly. Qemu will use 'pci-ohci'
for both if '-usb' is used.
Unfortunately an USB controller instantiated via '-usb' is unusable as
the bus name libvirt generates doesn't reflect the real name qemu uses,
and thus no libvirt-defined USB devices can be put on the controller.
This patch will populate the default USB controller into the XML and
select it's model to 'pci-ohci' unconditionally as the machine would
fail to start with '-usb' if that controller model is not available.
This patch doesn't try to make any other assumptions about
auto-populated model of USB controllers, which means that for an
explicit USB controller without model a different model will be picked.
Note that this will likely cause ABI differences and break migration for
the two machine types, in the corner case when the default USB
controller would be populated, but given that both are obsolete board
types and USB was unusable it doesn't make sense to keep supporting this
specific case when '-usb' was formatted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Assign VIR_DOMAIN_CONTROLLER_MODEL_USB_DEFAULT rather than -1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Most machine types are avaliable in all arches by qemu. This is also
true for the 'versatilepb' machine type example in the tests.
Move all the ARM architectures together so that they are handled in
sync.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add an example using the old binary/machine type to also see how legacy
cases are handled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Move the test invocation and rename the test files according to the
pattern.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
