Lin Ma [Fri, 11 Sep 2020 07:13:07 +0000 (15:13 +0800)]
vshReadlineParse: Ignore vshReadlineOptionsGenerator for VSH_OT_INT options
Commit c7151b0 added the completion for VSH_OT_INT options, say '--cellno'
and '--pagesize', So we need to ignore VSH_OT_INT otherwise we get the
incorrect completion.
A lot of virReportError() calls use VIR_ERR_INTERNAL_ERROR to represent
the number of the error, even in cases where there is one fitting more.
Hence, replace some of them with better virErrorNumber values.
Signed-off-by: Pino Toscano <ptoscano@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When a list is freed, we iterate through all the items, invoking the
free function for each; the actual free function called for each element
is the function of the actual type of each element, and thus the @_next
pointer in the element struct has the same type as the element itself.
Currently, the free function gets the parent of the current element
type, and invoke its free function to continue freeing the list.
However, in case the hierarchy of the classes has more than 1 level
(i.e. Class <- SubClass <- SubSubClass), the invoked free function is
only the parent class' one, and not the actual base class of the
hierarchy.
To fix that, change the generator to get the base class of a class, and
invoking that instead. Also, avoid to set the @_next back, as it is not
needed.
Ian Wienand [Fri, 11 Sep 2020 11:34:17 +0000 (21:34 +1000)]
network: Only check kernel added routes in virNetDevIPCheckIPv6Forwarding
The original motivation for adding virNetDevIPCheckIPv6Forwarding
(commit 00d28a78b5) was that networking routes would disappear when
ipv6 forwarding was enabled for an interface.
This is a fairly undocumented side-effect of the "accept_ra" sysctl
for an interface. 1 means the interface will accept_ra's if not
forwarding, 2 means always accept_RAs; but it is not explained that
enabling forwarding when accept_ra==1 will also clear any kernel RA
assigned routes, very likely breaking your networking.
The check to warn about this currently uses netlink to go through all
the routes and then look at the accept_ra status of the interfaces.
However, it has been noticed that this problem does not affect systems
where IPv6 RA configuration is handled in userspace, e.g. via tools
such as NetworkManager. In this case, the error message from libvirt
is spurious, and modifying the forwarding state will not affect the RA
state or disable your networking.
If you refer to the function rt6_purge_dflt_routers() in the kernel,
we can see that the routes being purged are only those with the
kernel's RTF_ADDRCONF flag set; that is, routes added by the kernel's
RA handling. Why does it do this? I think this is a Linux
implementation decision; it has always been like that and there are
some comments suggesting that it is because a router should be
statically configured, rather than accepting external configurations.
The solution implemented here is to convert the existing check into a
walk of /proc/net/ipv6_route (because RTF_ADDRCONF is apparently not
exposed in netlink) and look for routes with this flag set. We then
check the accept_ra status for the interface, and if enabling
forwarding would break things raise an error.
This should hopefully avoid "interactive" users, who are likely to be
using NetworkManager and the like, having false warnings when enabling
IPv6, but retain the error check for users relying on kernel-based
IPv6 interface auto-configuration.
Signed-off-by: Ian Wienand <iwienand@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com> Reviewed-by: Cedric Bosdonnat <CBosdonnat@suse.com>
Lin Ma [Fri, 11 Sep 2020 07:06:09 +0000 (15:06 +0800)]
qemu: Return perf status that affect next boot for shutoff domains
While we set up perf events for a shutoff domain and check the settings,
All of perf events are reported as 'disabled', unless we add --config,
This is redundant for a shutoff domain.
Use virDomainObjGetOneDefState instead of virDomainObjGetOneDef to fix
the issue. After patch, The perf event status of a shutoff domain is
reported correctly:
Signed-off-by: Lin Ma <lma@suse.de> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Erik Skultety [Fri, 11 Sep 2020 12:44:27 +0000 (14:44 +0200)]
qemu: qemuDomainPMSuspendAgent: Don't assign to 'ret' in a conditional
When the guest agent isn't running, we still report success on a PM
suspend action even though we logged an error correctly, this is because
we poisoned the 'ret' value a few lines above.
Fixes: a663a860819287e041c3de672aad1d8543098ecc Signed-off-by: Erik Skultety <eskultet@redhat.com>
Michal Privoznik [Fri, 11 Sep 2020 09:50:33 +0000 (11:50 +0200)]
virnuma: Use numa_nodes_ptr when checking available NUMA nodes
In v6.7.0-rc1~86 I've tried to fix a problem where we were not
detecting NUMA nodes properly because we misused behaviour of a
libnuma API and as it turned out the behaviour was correct for
hosts with 64 CPUs in one NUMA node. So I changed the code to use
nodemask_isset(&numa_all_nodes, ..) instead and it fixed the
problem on such hosts. However, what I did not realize is that
numa_all_nodes does not reflect all NUMA nodes visible to
userspace, it contains only those nodes that the process
(libvirtd) an allocate memory from, which can be only a subset of
all NUMA nodes. The bitmask that contains all NUMA nodes visible
to userspace and which one I should have used is: numa_nodes_ptr.
For curious ones:
And as I was fixing virNumaGetNodeCPUs() I came to realize that
we already have a function that wraps the correct bitmask:
virNumaNodeIsAvailable().
Fixes: 24d7d85208f812a45686b32a0561cc9c5c9a49c9
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1876956 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Fri, 11 Sep 2020 11:10:25 +0000 (13:10 +0200)]
virnuma: Assume numa_bitmask_isbitset() exists
This function was introduced in the 2.0.6 release which happened
in December 2010. I think it is safe to assume that all libnuma
we deal with have the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Laine Stump [Fri, 4 Sep 2020 16:44:33 +0000 (12:44 -0400)]
network: don't wait for IPv6 DAD completion when starting a network
0f7436ca54 added code during virtual network startup to wait for DAD
(Duplicate Address Detection) to complete if there were any IPv6
addresses on the network. This wait was needed because (according to
the commit log) "created problems when [the "dummy" tap device] is set
to IFF_DOWN prior to DAD completing".
That commit in turn referenced commit db488c7917, which had added the
code to set the dummy tap device IFF_DOWN, commenting "DAD has
happened (dnsmasq waits for it)", and in its commit message pointed
out that if we just got rid of the dummy tap device this wouldn't be
needed.
Now that the dummy tap device has indeed been removed (commit ee6c936fbb), there is no longer any need to set it IFF_DOWN, and thus
nothing requiring us to wait for DAD to complete. At any rate, with
the dummy tap device removed, leaving nothing else on the bridge when
it is first started, DAD never completes, leading to failure to start
any IPv6 network.
So, yes, this patch removes the wait for DAD completion, and IPv6
networks can once again start, and their associated dnsmasq process
starts successfully (this is the problem that the DAD wait was
originally intended to fix)
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are currently adding -lutil and -lkvm to the linker using the
add_project_link_arguments method. On FreeBSD 11.4, this results in
build errors because the args appear too early in the command line.
We need to pass the libraries as dependencies so that they get placed
at the same point in the linker args as other dependencies.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Matt Coleman [Tue, 8 Sep 2020 20:43:52 +0000 (16:43 -0400)]
Fix a typo in compiling.html.in: that -> from
The original author intended to write "different than".
"Different" is commonly followed by "from", "than", and "to".
Globally, "from" is the most common.
Signed-off-by: Matt Coleman <matt@datto.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
rpc: use new virt-ssh-helper binary for remote tunnelling
This wires up support for using the new virt-ssh-helper binary with the ssh,
libssh and libssh2 protocols.
The new binary will be used preferentially if it is available in $PATH,
otherwise we fall back to traditional netcat.
The "proxy" URI parameter can be used to force use of netcat e.g.
qemu+ssh://host/system?proxy=netcat
or the disable fallback e.g.
qemu+ssh://host/system?proxy=native
With use of virt-ssh-helper, we can now support remote session URIs
qemu+ssh://host/session
and this will only use virt-ssh-helper, with no fallback. This also lets
the libvirtd process be auto-started, and connect directly to the
modular daemons, avoiding use of virtproxyd back-compat tunnelling.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Switch keyfile and netcat parameters, since the netcat path and
socket path are a logical pair that belong together. This patches
the other constructors.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When accessing libvirtd over a SSH tunnel, the remote driver needs a way
to proxy the SSH input/output stream to a suitable libvirt daemon. This
is currently done by spawning netcat, pointing it to the libvirtd socket
path. This is problematic for a number of reasons:
- The socket path varies according to the --prefix chosen at build
time. The remote client is seeing the local prefix, but what we
need is the remote prefix
- The socket path varies according to remote env variables, such as
the XDG_RUNTIME_DIR location. Again we see the local XDG_RUNTIME_DIR
value, but what we need is the remote value (if any)
- The remote driver doesn't know whether it must connect to the legacy
libvirtd or the modular daemons, so must always assume legacy
libvirtd for back-compat. This means we'll always end up using the
virtproxyd daemon adding an extra hop in the RPC layer.
- We can not able to autospawn the libvirtd daemon for session mode
access
To address these problems this patch introduces the 'virtd-ssh-helper'
program which takes the URI for the remote driver as a CLI parameter.
It then figures out which daemon to connect to and its socket path,
using the same code that the remote driver client would on the remote
host's build of libvirt.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: extract logic for determining daemon to connect to
We'll shortly want to reuse code for determining whether to connect to
the system or session daemon from places outside the remote driver
client. Pulling it out into a self contained function facilitates reuse.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We delay converting the remote transport string to enum form until
fairly late. As a result we're doing string comparisons when we
could be just doing enum comparisons.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
remote: push logic for default netcat binary into common helper
We don't want to repeat the choice of default netcat binary setting in
three different places. This will also make it possible to do better
error reporting in the helper.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
rpc: merge logic for generating remote SSH shell script
Three parts of the code all build up the same SSH shell script
snippet for remote tunneling the RPC protocol, but in slightly
different ways. Combine them all into one helper method in the
virNetClient code, since this logic doesn't really belong in
the virNetSocket code.
Note that the this change means the shell snippet is passed to
the SSH binary as a single arg, instead of three separate args,
but this is functionally identical, as the three separate args
were combined into one already when passed to the remote system.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
disk storage: fix allocation size for pool format dos
The changed condition was always false because the function was always
called with boundary values 0.
Use the free extent's start value to get its start offset from the
cylinder boundary and determine if the needed size for allocation
needs to be expanded too in case the offset doesn't fit within extra
bytes for alignment.
This fixes an issue where vol-create-from will call qemu-img convert
to create a destination volume of same capacity as the source volume
and qemu-img will error 'Cannot grow device files' due to the partition
being too small for the source although both destination partition and
source volume have the same capacity.
Signed-off-by: Sebastian Mitterle <smitterl@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Unfortunately while for IPv4 it's well-known what addresses ranges are
useful for NAT, with IPv6 unless you enjoy digging through RFC's going
back-and-forth over unique local addresses and the meaning of the word
"site" it's generally much less obvious. I've tried to add some
details on choosing a range inline with RFC 4193 and then some
pointers for when it maybe doesn't work in the guest as you first
expect despite you doing what the RFC's say!
Signed-off-by: Ian Wienand <iwienand@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Hao Wang [Sat, 18 Jul 2020 07:43:30 +0000 (15:43 +0800)]
client: fix memory leak in client msg
When closing client->waitDispatch in virNetClientIOEventLoopRemoveAll
or virNetClientIOEventLoopRemoveDone, VIR_FREE() is called to free
call->msg directly, resulting in leak of the memory call->msg->buffer
points to.
Use virNetMessageFree(call->msg) instead of VIR_FREE(call->msg).
Signed-off-by: Hao Wang <wanghao232@huawei.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
qemuFirmwareFillDomain: Fill NVRAM template on migration too
In 8e1804f9f66 I've tried to fix the following use case: domain
is started with path to UEFI only and relies on libvirt to figure
out corresponding NVRAM template to create a per-domain copy
from. The fix consisted of having a check tailored exactly for
this use case and if it's hit then using FW autoselection to
figure it out. Unfortunately, the NVRAM template is not saved in
the inactive XML (well, the domain might be transient anyway).
Then, as a part of that check we see whether the per-domain copy
doesn't exist already and if it does then no template is looked
up hence no template will appear in the live XML.
This works, until the domain is migrated. At the destination, the
per-domain copy will not exist so we need to know the template to
create the per-domain copy from. But we don't even get to the
check because we are not starting a fresh new domain and thus the
qemuFirmwareFillDomain() function quits early.
The solution is to switch order of these two checks. That is
evaluate the check for the old style before checking flags.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1852910 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Ján Tomko [Wed, 9 Sep 2020 08:55:40 +0000 (10:55 +0200)]
virsh: cmdScreenshot: fix cbdata passing to virshStreamSink
The changes for sparse stream support started passing
virshStreamCallbackDataPtr to virshStreamSink
instead of passing a simple file descriptor, but
forgot to adjust all the callers.
cpu_ppc64.c: use g_autoptr() in virCPUppc64GetHost()
We don't need to call virCPUppc64DataFree() in a cleanup label.
This function is already assigned to the 'dataFree' interface
of cpuDriverPPC64, and it will be called by virCPUDataFree(), the
autocleanup function of virCPUDataPtr, via driver->dataFree.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Ján Tomko [Tue, 8 Sep 2020 12:57:14 +0000 (14:57 +0200)]
check for NULL before calling g_regex_unref
g_regex_unref reports an error if called with a NULL argument.
We have two cases in the code where we (possibly) call it on a NULL
argument. The interesting one is in virDomainQemuMonitorEventCleanup.
Based on VIR_CONNECT_DOMAIN_QEMU_MONITOR_EVENT_REGISTER_REGEX, we unref
data->regex, which has two problems:
* On the client side, flags is -1 so the comparison is true even if no
regex was used, reproducible by:
$ virsh qemu-monitor-event --timeout 1
which results in an ugly error:
(process:1289846): GLib-CRITICAL **: 14:58:42.631: g_regex_unref: assertion 'regex != NULL' failed
* On the server side, we only create the regex if both the flag and the
string are present, so it's possible to trigger this message by:
$ virsh qemu-monitor-event --regex --timeout 1
Use a non-NULL comparison instead of the flag to decide whether we need
to unref the regex. And add a non-NULL check to the unref in the
VirtualBox test too.
Signed-off-by: Ján Tomko <jtomko@redhat.com> Fixes: 71efb59a4de7c51b1bc889a316f1796ebf55738f
https://bugzilla.redhat.com/show_bug.cgi?id=1876907 Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Even though this was brought up in upstream discussion [1] it
missed my patches: users should prefer <oemStrings/> over fwcfg.
The reason is that fwcfg is considered somewhat internal to QEMU
and it has limited number of slots and neither of these applies
to <oemStrings/>.
While I'm at it, I'm fixing the example too (because it contains
incorrect element name) and clarifying sysfs/ exposure.
projects / thirdparty / libvirt.git / log
