The video private data was not initializing the vhostuser FD
causing us to attempt to close FD 0 many times over.
Fixes
commit ca60ecfa8c
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: Mon Sep 23 14:44:36 2019 +0400
qemu: add qemuDomainVideoPrivate
Since the test suite does not invoke qemuExtDevicesStart(), no
vhost_user_fd will be present when generating test XML. To deal
with this we can must a fake FD number. While the current XML
is using FD == 0, we pick a very interesting number that's unlikely
to be a real FD, so that we're more likely to see any mistakes
closing the invalid FD.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the new generator residing in the monitor code rather than directly
using qemuMonitorJSONTransactionAdd.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Unify with other code that generates parameters for the 'transaction'
command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Rather than generating the transaction contents in random places add a
unified set of APIs to generate the contents for a 'transaction' for the
dirty bitmap APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The QEMU_CAPS_INCREMENTAL_BACKUP will be enabled once all bits of the
incremental backup feature work as expected which means also properly
interacting with blockjobs and snapshots.
Thus we can allow blockjobs and snapshots if QEMU_CAPS_INCREMENTAL_BACKUP
is present even when checkpoints exist.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Rather than having to fix 5 places once we support the combination, add
a function called by all the blockjob/snapshot APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Checkpoints by themselves are not very useful for anything else than
testing the few bitmap interactions that are currently implemented.
It's very unlikely that anybody used this feature and thus we can
disable it until we have a more complete implementation ready.
Additionally the code for deleting checkpoints has many broken failure
scenarios which should be fixed first. This will require support of
deleting a bitmap in a qemu 'transaction' which was not released yet.
Curious users obviously can use the qemu namespace in the XML to enable
this for experiments:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
<qemu:capabilities>
<qemu:add capability='incremental-backup'/>
</qemu:capabilities>
</domain>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Add a new all-covering capability which will be used to interlock
incremental backup support until all bits are ready.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Add a 'cleanup' label and use jumps as we do in other places.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Once somebody is motivated enough to add the support for the quiesce
flag or offline checkpoint deletion they are welcome to do so but we
don't need to have a reminder.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
There's nothing that uses it directly now. Also not allowing direct use
will promote our layering.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Finish the refactor by moving and renaming functions from qemu_domain.c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Move all extensive functions to a new file so that we don't just pile
everything in the common files. This obviously isn't possible with
straight code movement as we still need stubs in qemu_driver.c
Additionally some functions e.g. for looking up a checkpoint by name
were so short that moving the impl didn't make sense.
Note that in the move the new file also doesn't use
virQEMUMomentReparent but rather an stripped down copy. As I plan to
split out snapshot code into a separate file the unification doesn't
make sense any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The interlocking with snapshots is executed prior to the ACL check so if
a VM has snapshots invoking the checkpoint API may leak it's existance.
Introduced with the qemuDomainCheckpointCreateXML API implementation in
commit 5f4e079650.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It is documented that a command to run inside the container can be
passed with the -c arg.
virt-login-shell -c "ls -l /"
This fixes
commit 4feeb2d986
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Aug 1 10:58:31 2019 +0100
tools: split virt-login-shell into two binaries
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We recently forbid the use of --listen with socket activation:
commit 3a6a725b8f
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Aug 22 14:52:16 2019 +0100
remote: forbid the --listen arg when systemd socket activation
In this change we forgot that virtproxyd doesn't have a --listen
parameter, and instead behaves as if it was always present. Thus
when systemd socket activation is present, we must disable this
built-in default
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a symbol file for either of NSS modules is changed then
subsequent 'make' doesn't regenerate the library, because there
is no implicit dependency between the library and symbols file.
Put an explicit dependency into the Makefile then. Unfortunately,
setting _DEPENDENCIES makes us lose automake's generated
dependencies (see src/Makefile.am:592 for details). But
fortunately, the only dependency we had was _LIBADD variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Similarly to gethostbyname3(), the @addr must be freed on return
from the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The findLease() function allocates @addr array iff no error
occurred and at least one satisfactory record was found.
Therefore, there is no need to call free() if findLease() failed,
or did not find any records as addr == NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When parsing leases file, appendAddr() is called to append parsed
tuple (address, expiry time, family) into an array. Whilst doing
so, the array is searched for possible duplicate. This is done by
comparing each item of the array by passed @family: if @family is
AF_INET then the item is viewed as IPv4 address. Similarly, if
@family is AF_INET6 then the item is viewed as IPv6 address. This
is not exactly right - the array can contain addresses of both
families and thus the address family of each item of the array
must be considered.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
On Fedora 31, starting a 'mock' build alters /proc/$pid/cgroup,
probably due to usage of systemd-nspawn.
Before:
$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/...
After:
$ cat /proc/self/cgroup
1:name=systemd:/
0::/user.slice/user-1000.slice/...
The cgroupv2 code mishandles that first line in the second case, which
causes VM startup to fail with: Unable to read from
'/sys/fs/cgroup/machine/cgroup.controllers': No such file or directory
The kernel docs[1] say that the cgroupv2 path will always start with
'0::', which in the code here controllers="". Only set the v2 placement
path when we see that cgroup file entry.
[1] https://www.kernel.org/doc/html/v5.3/admin-guide/cgroup-v2.html#processeshttps://bugzilla.redhat.com/show_bug.cgi?id=1751120
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The code that gets the job to refresh disk sizes was not merged yet so
remove this artifact.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
'vm' is passed in which contains the definition which contains the UUID
so we don't need another parameter for this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'vm' is passed in which contains the definition which contains the UUID
so we don't need another parameter for this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move it to qemu_domain.c and rename it to qemuDomainObjFromDomain. This
will allow reusing it after splitting out checkpoint code from
qemu_driver.c.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Blacklist Perl and Shell code in favour of Python for
sake of readability and portability.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As it turns out, on my 32bit ARM machine size_t is not the same
size as ULL. However, @length argument for both functions is type
of size_t but it's treated as ULL - for instance when passed to
qemuMonitorJSONMakeCommand(). The problem is that because of
"U:size" the virJSONValueObjectAddVArgs() expects an ULL argument
but on the stack there are size_t and char * arguments (which
coincidentally add up to size of ULL). So the created command has
only two arguments "val" and incorrect "size" and no "path" which
is required.
I've tried to find other occurrences of this pattern but at the
rest of places where size_t is used it tracks size of an array so
that's safe.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
We stopped generating a giant ChangeLog file in
commit ce97c33a79
Author: Andrea Bolognani <abologna@redhat.com>
Date: Mon Apr 1 17:33:03 2019 +0200
maint: Stop generating ChangeLog from git
so there is no reason to compress it anymore.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Drop the 'driver' argument since it can be extracted from private data
to shorten the argument list.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Now that qemu 4.1 was released we can update the capabilities to the
final form.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Before the refactoring that properly separated the network driver from
the hypervisor driver and forced all interaction to go through public
APIs, all network usage counters were zeroed when the network driver
was initialized, and the network driver's now-deprecated
"semi-private" API networkNotifyActualDevice() was called for every
interface of every domain as each hypervisor "reconnected" its domains
during a libvirtd restart, and this would refresh the usage count for
each network.
Post-driver-split, during libvirtd restart/reconnection of the running
domains, the function virDomainNetNotifyActualDevice() is called by
each hypervisor driver for every interface of every domain restart,
and this function has code to re-register interfaces, but it only
calls into the network driver to re-register those ports that don't
already have a valid portid (ie. one that is not simply all 0),
assuming that those with valid portids are already known (and counted)
by the network driver.
commit 7ab9bdd47 recently modified the network driver so that, in most
cases, it properly resyncs each network's connection count during
libvirtd (or maybe virtnetworkd) restart by iterating through the
network's port list. This doesn't account for the case where a network
is destroyed and restarted while there are running domains that have
active ports on the network. In that case, the entire port list and
connection count for that network is lost, and now even a restart of
libvirtd/virtnetworkd/virtqemud, which in the past would resync the
connection count, doesn't help (the network driver thinks there are no
active ports, while the hypervisor driver knows about all the active
ports, but mistakenly believes that the network driver also knows).
The solution to this is to not just bypass valid portids during the
call to virDomainNetworkNotifyActualDevice(). Instead, we query the
network driver about the portid that was preserved in the domain
status, and if it is not registered, we register it.
(NB: while it would technically be correct to just generate a new
portid for these cases, it makes for less churn in portids (and thus
may make troubleshooting simpler) if we make the small fix to
virDomainNetDefActualToNetworkPort() that preserves existing valid
portids rather than unconditionally generating a new one.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
define a VIR_DEFINE_AUTOPTR_FUNC() to autofree virNetworkPortDefs, and
convert all uses of virNetworkPortDefPtr that are appropriate to use
it.
This coincidentally fixes multiple potential memory leaks (in failure
cases) in networkPortCreateXML()
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The existing QEMU and vbox URI path validation consider
that a privileged user can use both a "/system" and a
"/session" URI. This differs from all the other drivers
that forbids the root user to use "/session" URI.
Let's update virConnectValidateURIPath() to handle these
cases as exceptions, using the already existent 'entityName'
value to handle "QEMU" and "vbox" differently. This allows
us to use the validateURI function in these cases without
changing the existing behavior of other drivers.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The code to validate the URI path is repeated across several
files. This patch creates a common validation code to be
used across all of them.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
