After previous patches neither vshReadlineCommandGenerator() nor
vshReadlineOptionsGenerator() use prefix that user wants to
complete. The argument is marked as unused in both functions.
Drop it then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Firstly, move variable declarations into the inner most block
they are used. Secondly, use for() loop instead of while so that
we don't have to advance loop counter explicitly on 'continue'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The way we currently call completer callbacks is that if we've
found --option that user wants to complete value for and it has
callback set then the callback is called.
And just before that, if no --option to have the value completed
is found or is found and is of boolean type then a list of
--option is generated (for given command).
But these two conditions can never be true at the same time
because boolean type of --options do not accept values. Therefore
the calling of completer callback can be promoted onto the same
level as the --option list generation.
This means that merging of two lists can be dropped to and
completer callback can store its retval directly into @list (but
as shown earlier one of the string lists to merge is always
empty).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Completer callbacks generate all possible outputs ignoring any partial
input (e.g. prefix of a domain name) and then use vshCompleterFilter() to
filter out those strings which don't fit the partial input (prefix).
In contrast, vshReadlineCommandGenerator() does some internal filtering and
only generates completions that match a given prefix. Rather than treating
these scenarios differently, simply generate all possible options and
filter them all at the end.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Completer callbacks generate all possible outputs ignoring any partial
input (e.g. prefix of a domain name) and then use vshCompleterFilter() to
filter out those strings which don't fit the partial input (prefix).
In contrast, vshReadlineOptionsGenerator() does some internal filtering and
only generates completions that match a given prefix. Rather than treating
these scenarios differently, simply generate all possible options and
filter them all at the end.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The vshReadlineParse() function is called whenever user hits
<TAB><TAB>. If there is no command (or a partially written one),
then a list of possible commands is printed to the user. But, if
there is a command then its --options are generated. But
obviously, we can not generate --options if there already is an
--option that's expecting a value. For instance, consider:
virsh # start --domain <TAB><TAB>
In this case we want to call completer for --domain option, but
that's a different story.
Anyway, the way that we currently check whether --options list
should be generated is checking the type of the last --option. If
it isn't DATA, STRING, INT, or ARGV (all these expect a value),
then we can generate --option list. Well, writing the condition
this way is needlessly verbose and also prone to errors (see
d9a320bf97 for example).
We know that boolean type does not require a value. This leaves
us with the only type that was not mentioned yet - VSH_OT_ALIAS.
This is a special type for backwards compatibility and it refers
to another --option which can be just any type.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
There are two functions that are used to generate completion
lists: vshReadlineCommandGenerator() for command names and
vshReadlineOptionsGenerator() for --options for given command.
Both return a string list, but may also fail while constructing
it. For that case, they call g_strfreev() explicitly, which is
needless since we have g_auto(GStrv).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The vshReadlineOptionsGenerator() function returns a string list
of all --options for given command. But the way that individual
items on the list are allocated can be written better.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The aim of vshCompleterFilter() is to take a string list and a
prefix and remove all strings from the list that don't have the
desired prefix. The function is used to filter out those strings
returned by a completer callback that don't correspond with
user's (partial) input. For instance, domain name completer
virshDomainNameCompleter() returns all domain names and then
vshCompleterFilter() refines the list so that only domains with
correct prefix of their name are offered to user. This was a
design choice - it allows us to have shorter completers as they
do not have to copy the list filtering over and over.
Having said all of that, it may happen that a completer does not
return anything (e.g. there is no domain in requested state,
virsh is not connected and thus completer exited early, etc.). In
that case, the string list is NULL and vshCompleterFilter() can
simply return early.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This saves us explicit call of g_strfreev() in error path.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
We've invented VSH_OT_ALIAS type for --option so that we can
rewrite some --options (e.g. fix spelling). For instance
blkdeviotune command uses this feature heavily:
--options-with-dash are preferred over old
--options_with_underscore. Both versions are supported but only
the new ones (not aliased) are documented and reported in --help.
Except for options completer, which happily put also aliased
versions in front of user's eyes.
Note, there is a second (gross) way we use aliases: to rewrite
options from --oldoption to --newoption=value (for instance
--shareable option of attach-disk is an alias of
--mode=shareable). And just like with the previous group - don't
generate them into the list of possible options.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
There are few cases where STREQLEN() is called like this:
STREQLEN(var, string, strlen(string))
which is the same as STRPREFIX(var, string). Use STRPREFIX()
because it is more obvious what the check is doing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The version of macOS running on Apple Silicon doesn't need to
concern itself with backwards compatibility with 32-bit
applications, and so it could jettison all the symbol aliasing
shenanigans involved.
https://gitlab.com/libvirt/libvirt/-/issues/121
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
A <machine/> element can have "deprecated" attribute that
corresponds to 'deprecated' member of _virQEMUCapsMachineType
struct. But the member is of boolean type. Therefore, the string
returned by virXMLPropString() must be freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If parsing "maxCpus" attribute of <machine/> element fails an
error is printed but the corresponding string is not freed. While
it is very unlikely to happen (parsed XML is not user provided
and we are the ones generating it), it is possible. Instead of
freeing the variable in the error path explicitly, let's declare
it as g_autofree. And while I'm at it, let's bring it into the
loop where it's used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The various virtproxyd socket files are generated with invalid syntax,
e.g. from virtproxyd.socket
[Unit]
Description=Libvirt proxy local socket
Before=virtproxyd.service
libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket libvirtd-tcp.socket libvirtd-tls.socket
Note the missing 'Conflicts=' in the last line. Fix it by prepending
'Conflicts=' to libvirtd_socket_conflicts when adding virtproxyd
to virt_daemon_units.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Update to qemu commit v5.2.0-1684-gd0dddab40e which includes the removal
of pc-1.0/pc-1.1/pc-1.2 machine types, adds the new QMP commands for
internal snapshots as well as includes the background-snapshot
capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The test doesn't depend on a specific machine type.
The test uses a machine type which is becoming deprecated so it would
break the _LATEST version of the test once we update the qemu data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
A couple of these were wrong, resulting in the build job not
waiting for the correct container to be built before starting.
Fixes: 77296c807b
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
On platforms that lack both getauxval() and elf_aux_info(),
such as OpenBSD and macOS, host CPU detection can't work.
https://gitlab.com/libvirt/libvirt/-/issues/121
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
No need to fetch the same information twice.
As a side effect, this solves a bug where, on platforms where
elf_aux_info() is used instead of getauxval(), we would not
make sure the CPUID feature is available before attempting to
use it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This header is not present on several non-Linux targets that
nonetheless support aarch64.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
A few commits back I've introduced new 'virtio-pmem' <memory/>
device. Since it's virtio it goes onto PCI bus. Therefore, on
hotplug new PCI address is generated (or provided one is
reserved). However, if hotplug fails (for whatever reason) the
address needs to be released. This is different to 'dimm' type of
address because for that type we don't keep a map of used slots
rather generate one on each address assign request. The map is
then thrown away. But for PCI addresses we keep internal state
and thus has to keep it updated. Therefore, this new
qemuDomainReleaseMemoryDeviceSlot() function is NOP for those
models which use 'dimm' address type ('dimm' and 'nvdimm').
While I'm at it, let's release the address in case of hot unplug.
Not that is supported (any such attempt fails with the following
error:
"virtio based memory devices cannot be unplugged"
But if QEMU ever implements hot unplug then we don't have to
remember to fix our code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Currently, nmdm console device requires user to specify master and slave
path attributes (such as /dev/nmdm0A and /dev/nmdm0B respectively).
However, making user find a non-occupied device name might be not
convenient, especially for the remote connections.
Update the logic to make these attributes optional. In case if not
specified, use /dev/nmdm$UUID[AB], where $UUID is a domain's UUID.
With this schema it's unlikely nmdm device will clash with other domains
or even other non-bhyve nmdm devices.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently translated at 13.5% (1415 of 10451 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
All of these options are actually supported by vhostuser disk so
we should allow them to be usable.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, requesting domain capabilities fails when the specified
emulator binary does not equal to "/usr/sbin/bhyve". As we're
not using user-specified emulator anyway, drop this check to avoid
showing errors for values like "bhyve" (without absolute path).
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Many of Xen's text documents have been converted to man pages over
the years, the channel doc being one of them. Replace the broken
channel.txt link with the name of the man page providing the same
information.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Parameter 'known_hosts_verify' is supported for some time now,
but it is not yet documented.
Signed-off-by: Jakob Meng <jakobmeng@web.de>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Get rid of the 'need_release' variable. The code can be rewritten
so that it is not needed.
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we're no longer using gnulib, we can treat macOS the
same as all other targets.
This reverts commit 0ae6f5cea5
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
When deleting the vhostuserclient interface, OVS prompts that the interface does not exist,
Through the XML file, I found that the "target dev" has a '\n', results in an XML parsing error.
XML file:
<target dev='vm-20ac9c030a47
'/>
That is because 'ovs-vsctl' returns a newline result, always come with a '\n',
and the vircommandrun function puts it in ifname.
So virNetDevOpenvswitchGetVhostuserIfname should remove '\n' from ifname.
Signed-off-by: Yalei Li <liyl43@chinatelecom.cn>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function is only called from one place, and has, well... not a
*misleading* name, but it doesn't fit the standard frame of functions
that end in "Free" (it doesn't actually free the object pointed to by
its argument, but frees *some parts* of the content of the object).
Rather than try to think up an appropriate name, let's just move the
meat of this function into its one and only caller,
virNetLibsshSessionDispose(), which will allow us to convert its
VIR_FREEs into g_free in a future patch.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
virDomainCapsDispose() was the only caller of
virDomainCapsStringValuesFree(), which 1) didn't actually free the
object it was called with, but only cleared it, making it less
mechanical to convert from VIR_FREE to g_free (since it's not
immediately obvious from looking at virDomainCapsStringValuesFree()
that the pointers being cleared will never again be used).
We could have renamed the function to virDomainCapsStringValuesClear()
to side-step the confusion of what the function actually does, but
that would just make the upcoming switch from VIR_FREE to g_free
require more thought. But since there is only a single caller to the
function, and it is a vir*Dispose() function (indicating that the
object containing the virDomainCapsStringValues is going to be freed
immediately after the function finishes), and thus VIR_FREE() *could*
be safely replaced by g_free()), we instead just move the contents of
virDomainCapsStringValuesFree() into virDomainCapsDispose() (and
*that* function will be trivially converted in an upcoming
"mechanical" patch).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This is another *Free() function that doesn't free the object it is
passed. Instead it frees and clears some parts of the object.
In this case, the function is actually called from two places, and one
of them (virNetSSHSessionAuthReset) appears to be assuming that the
pointers actually *will* be cleared. So the proper thing to do here
(?) is to rename the function to virNetSSHSesionAuthMethodsClear().
(NB: virNetSSHSessionAuthReset is seemingly never called from
anywhere. Is this one of those functions that actually *is* called by
some strange MACRO invocation? Or it is truly one of those
"written-but-never-used" functions that can be deleted? (if the latter
is the case, then I would rather move the contents of
virNetSessionAuthMethodsFree() into its only other caller,
virNetSSHSessionDispose(), so that the VIR_FREEs could be replaced
with g_free.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
