This fixes bug in
commit bbe2aa627f
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Jul 26 17:24:30 2018 +0100
conf: simplify link from hostdev back to network device
hostdevs have a link back to the original network device. This is fairly
generic accepting any type of device, however, we don't intend to make
use of this approach in future. It can thus be specialized to network
devices.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
which mistakenly deleted the assignment to the 'net' variable,
which meant we never invoked the network driver release callback
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The functions are left returning an "int" to avoid an immediate
big-bang cleanup. They'll simply never return anything other
than 0.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Only a few of the _QUIET allocation macros are used. Since we're no
longer reporting OOM as errors, we want to eliminate all the _QUIET
variants. This starts with the easy, unused, cases.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The functions are left returning an "int" to avoid an immediate
big-bang cleanup. They'll simply never return anything other
than 0, except for virInsertN which can still return an error
if the requested insertion index is out of range. Interestingly
in that case, the _QUIET function would none the less report
an error.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The OOM handling requires special build time options which we never
enable in our CI. Even once enabled the tests are incredibly slow and
typically require manual inspection of the results to weed out false
positives.
Since there was previous agreement to switch to abort on OOM in libvirt
code, there's no point continuing to keep the unused OOM testing code.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetworkPortDef config stores the 'managed' attribute
as the virTristateBool type.
The virDomainDef config stores the 'managed' attribute as
the bool type.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the hypervisor driver has not yet created the network port, the
portid field will be "00000000-0000-0000-0000-000000000000".
If a failure occurs during early VM startup, the hypervisor driver may
none the less try to release the network port, resulting in an
undesirable warning:
2019-09-12 13:17:42.349+0000: 16544: error :
virNetworkObjLookupPort:1679 : network port not found: Network port with
UUID 00000000-0000-0000-0000-000000000000 does not exist
By checking if the portid UUID is valid, we can avoid polluting the logs
in this way.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The pci_dev->physical_function is rewritten in
virPCIGetPhysicalFunction() to a newly allocated pointer.
Therefore, we must free the old one to avoid memleak.
Signed-off-by: Jiang kun <jiang.kun2@zte.com.cn>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have qemuFirmwareGetSupported() so that it also
returns a list of FW image paths, we can use it to report them in
domain capabilities instead of the old time default list.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The qemuFirmwareGetSupported() function is called from qemu
driver to generate domain capabilities XML based on FW descriptor
files. However, the function currently reports only some features
from domcapabilities XML and not actual FW image paths. The paths
reported in the domcapabilities XML are still from pre-FW
descriptor era and therefore the XML might be a bit confusing.
For instance, it may say that secure boot is supported but
secboot enabled FW is not in the listed FW image paths.
To resolve this problem, change qemuFirmwareGetSupported() so
that it also returns a list of FW images (we have the list
anyway). Luckily, we already have a structure to represent a FW
image - virFirmware.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This function is going to get some new arguments. Document the
current ones for clarity.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This function frees a _virFirmware struct. So far, it doesn't
need to be called from outside of the module, but this will
change shortly. In the light of recent VIR_DEFINE_AUTOPTR_FUNC()
additions, do the same to virFirmwareFree().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The snapshot-create operation of running guests saves the live
XML and uses it to replace the active and inactive domain in
case of revert. So, the config XML is ignored by the snapshot
process. This commit changes it and adds the config XML in the
snapshot XML as the <inactiveDomain> entry.
In case of offline guest, the behavior remains the same and the
config XML is saved in the snapshot XML as <domain> entry. The
behavior of older snapshots of running guests, that don't have
the new <inactiveDomain>, remains the same too. The revert, in
this case, overrides both active and inactive domain with the
<domain> entry. So, the <inactiveDomain> in the snapshot XML is
not required to snapshot work, but it's useful to preserve the
config XML of running guests.
Signed-off-by: Maxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The function virDomainDefFormatInternal() has the predefined root name
"domain" to format the XML. But to save both active and inactive domain
in the snapshot XML, the new root name "inactiveDomain" was created.
So, the new function virDomainDefFormatInternalSetRootName() allows to
choose the root name of XML. The former function became a tiny wrapper
to call the new function setting the correct parameters.
Signed-off-by: Maxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Once we copy the domain definition from virDomainSnapshotDef, we either
need to assign it to the domain object or free it to avoid memory leaks.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit f10562799 introduced a regression: if reverting to a snapshot
fails early (such as when we refuse to revert to an external
snapshot), we lose track of the domain's current snapshot.
Before that patch, we were tracking the notion of the domain's current
snapshot via two means: vm->current_snapshot (which was left untouched
on early exit) and snap->def->current (which only controls what gets
written to XML to remember snapshots across libvirtd restarts). That
patch was fixing a real bug: if a revert operation failed early, later
questions from the same libvirtd did not see any change to the current
snapsthot, but restarting libvirtd would now claim there is no current
snapshot. But it fixed it in the wrong direction, in that the current
snapshot was forgotten unconditionally, rather than only when the
snapshot to revert to has a chance of being useful.
It didn't help that the code after that patch had two separate spots
clearing the old notion of the current snapshot - one after
determining the snapshot to revert to was viable, the other
unconditionally on all failure exit paths. At any rate, the fix is
simple: drop the unconditional cleanup on error paths, and rely only
on the normal cleanup after early checks.
Sadly, it is not possible to test this bug in the existing
tests/virsh-snapshot, as the test driver does not have the same
prohibition against reverting to an external snapshot as the qemu
driver.
See: https://bugzilla.redhat.com/1738747
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190909205242.15406-1-eblake@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
In recent commit of 3d21ff72e0 the virNetDevMacVLanTapOpen() and
virNetDevMacVLanTapSetup() functions were exported in our private
symbols. But these functions live in an #ifdef so they need a
stub implementation.
Then in 1b46566ee the virNetDevMacVLanIsMacvtap() function was
implemented but again, only for #idef and without stub.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The Perl bindings for libvirt use the test driver for unit tests. This
tries to load the cpu_map/index.xml file, and when run from an
uninstalled build will fail.
The problem is that virFileActivateDirOverride is called by our various
binaries like libvirtd, virsh, but is not called when a 3rd party app
uses libvirt.so
To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be
set and make virInitialize look for this. The 'run' script will set it,
so now build using this script to run against an uninstalled tree we
will correctly resolve files to the source tree.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The only caller for which this check makes sense is virDomainDefParse.
Thus the check should be moved there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit 39dded7bb6.
This commit broke virpolkittest on Ubuntu 18 which has an old
dbus (v1.12.2). Any other distro with the recent one works
(v1.12.16) which hints its a bug in dbus somewhere. Revert the
commit to stop tickling it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There are two 'cleanup' labels - one in
virQEMUDriverConfigHugeTLBFSInit() and the other in
virQEMUDriverConfigSetDefaults() that do nothing more than
return and integer value. No memory freeing or anything important
is done there. Drop them in favour of returning immediately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Our naming rules prefer qemuObjectOperation() scheme rather than
qemuOperationObject() for function names. These were not honoured
in recent commits to qemu_conf.c.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Traditionally, macvtap devices are supported using <interface
type='direct'>, but that type requires specifying a source device name
and macvtap mode which can't be altered after the initial device
creation (and may not even be available to the management software
that's creating the XML config to feed to libvirt).
But the attributes in the <source> are essentially describing how the
device will be connected to the network, and if libvirt is to be
supplied with the name of a macvtap device that has already been
created, that device will also already be connected to the network
(and the connection can't be changed). Thus it seems more appropriate
to use type='ethernet', which was created explicitly for this purpose
- for devices that have already been (or will be) connected to the
external network by someone/something outside of libvirt. The fact
that it is a *macv*tap rather than a contentional tap device is just a
detail.
This patch supports using an existing macvtap device with <interface
type='ethernet'> by checking the supplied target dev name to see if it
is a macvtap device and, when this is the case, calling
virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For
consistency, this is only done when target managed='no'.
Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If managed='no', then the tap device must already exist, and setting
of MAC address and online status (IFF_UP) is skipped.
NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate,
because those bits must be properly set in the TUNSETIFF we use to set
the tap device name of the handle we've opened - if IFF_VNET_HDR has
not been set and we set it the request will be honored even when
running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be
different than how it was created, that will result in an error from
the kernel. This means that you don't need to pay attention to
IFF_VNET_HDR when creating the tap devices, but you *do* need to set
IFF_MULTI_QUEUE if you're going to use multiple queues for your tap
device.
NB2: /dev/vhost-net normally has permissions 600, so it can't be
opened by an unprivileged process. This would normally cause a warning
message when using a virtio net device from an unprivileged
libvirtd. I've found that setting the permissions for /dev/vhost-net
permits unprivileged libvirtd to use vhost-net for virtio devices, but
have no idea what sort of security implications that has. I haven't
changed libvrit's code to avoid *attempting* to open /dev/vhost-net -
if you are concerned about the security of opening up permissions of
/dev/vhost-net (probably a good idea at least until we ask someone who
knows about the code) then add <driver name='qemu'/> to the interface
definition and you'll avoid the warning message.
Note that virNetDevTapCreate() is the correct function to call in the
case of an existing device, because the same ioctl() that creates a
new tap device will also open an existing tap device.
Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Although <interface type='ethernet'> has always been able to use an
existing tap device, this is just a coincidence due to the fact that
the same ioctl is used to create a new tap device or get a handle to
an existing device.
Even then, once we have the handle to the device, we still insist on
doing extra setup to it (setting the MAC address and IFF_UP). That
*might* be okay if libvirtd is running as a privileged process, but if
libvirtd is running as an unprivileged user, those attempted
modifications to the tap device will fail (yes, even if the tap is set
to be owned by the user running libvirtd). We could avoid this if we
knew that the device already existed, but as stated above, an existing
device and new device are both accessed in the same manner, and
anyway, we need to preserve existing behavior for those who are
already using pre-existing devices with privileged libvirtd (and
allowing/expecting libvirt to configure the pre-existing device).
In order to cleanly support the idea of using a pre-existing and
pre-configured tap device, this patch introduces a new optional
attribute "managed" for the interface <target> element. This
attribute is only valid for <interface type='ethernet'> (since all
other interface types have mandatory config that doesn't apply in the
case where we expect the tap device to be setup before we
get it). The syntax would look something like this:
<interface type='ethernet'>
<target dev='mytap0' managed='no'/>
...
</interface>
This patch just adds managed to the grammar and parser for <target>,
but has no functionality behind it.
(NB: when managed='no' (the default when not specified is 'yes'), the
target dev is always a name explicitly provided, so we don't
auto-remove it from the config just because it starts with "vnet"
(VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
same pattern of names that libvirt itself uses when it automatically
creates the tap devices.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will simplify addition of another attribute to the <target> element
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This just moves around a few things in qemuInterfaceConnect() with no
functional difference (except that a few failures that would have
previously resulted in a "success" audit log will now properly produce
a "fail" audit). The change is so that adding support for unmanaged
tap/macvtap devices will be more easily reviewable.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In virNetDevMacVLanOpen(), The "retries" arg has been removed and the
value hardcoded as 10, since previously the function was only called
from one place, so it was always 10.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This function returns T if the given name is a macvtap device. This is
determined by 1) getting the ifindex of the device with that name (if
there is one), and 2) checking for existence of /dev/tapXX, where "XX"
is the ifindex learned in (1).
It's also possible to learn this by getting a netlink dump of the
interface and parsing through it to look for some attributes, but that
is complicated to figure out, takes longer to execute, and I'm lazy.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This patch adds hostdev test cases in qemuhotplugtest.c.
Note: the small tweak inside virpcimock.c was needed because
the new tests added a code path in which virHostHasIOMMU()
(virutil.c) started being called, and the mocked '/sys/kernel/'
prefix that is mocked in virpcimock.c wasn't being considered
in the opendir() mock. An alternative to avoid these situations
in virpcimock.c is implemented in the next patch.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
When starting a domain, we use the presence of a vfio-pci or
mdev hostdev to determine if the memlock maximum needs to be
increased. But if we hotplug either of these devices, only the
vfio-pci path gets that love. This means that attaching a, say,
vfio-ccw device will appear to succeed but the device may be
unusable as the guest may see I/O errors on long CCW chains.
The host, meanwhile, would be flooded with these messages:
vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded
Let's adjust the maximum memlock value in the mdev hotplug path,
so that the domain has the same value as if it were started with
one or more mdev devices in its configuration.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If attaching a PCI hostdev fails, there are several things that
need to be un-done as part of the cleanup. One thing that is
not done is re-calculating/re-setting the maximum amount of locked
memory for the domain, since we may have changed that.
Let's fix that, just to ensure everything is back the way it was.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Let's pull this hunk out into a function, so it can be reused
in another codepath that needs to do the same thing.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In f08e6883cb I've made @pcidevs in
virHostdevReAttachPCIDevices() to be automatically unrefed using
VIR_AUTOUNREF() but I forgot to remove the line that explicitly
unrefs the object at the end of the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
After the previous commits, qemuAddSharedDevice() and
qemuRemoveSharedDevice() are now the same code with a different
flag to call the internal functions.
This patch aggregates the common code into a new function called
qemuAddRemoveSharedDeviceInternal() to further reduce
code repetition. Both qemuAddSharedDevice() and
qemuRemoveSharedDevice() are kept since they are public
functions used elsewhere.
No functional change was made.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Following the same idea of avoid code repetition from the
previous patch, this commit introduces a new function that
aggregates the functions of qemuAddSharedDisk() and
qemuRemoveSharedDisk() into a single place, using a flag to
switch between add/remove operations.
Both qemuAddSharedDisk() and qemuRemoveSharedDisk() are
public, so keep them around to avoid changing other files
due to an internal qemu_conf.c refactory.
No functional change was made.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
qemuAddSharedHostdev() has a code similar to
qemuRemoveSharedHostdev(), with exception of one line that
defines the operation (add or remove).
This patch introduces a new function that aggregates the common
code, using a flag to switch between the operations, avoiding
code repetition.
No functional change was made.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since commit fd9ef3b31e, virDomainFindByUUIDRef() no longer exists and
all virDomainObjListFindBy*() functions now increment the reference
count.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
As a result of changes in
commit d5f0c1b6dd
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Jul 18 12:30:22 2019 +0100
remote: stop trying to print help as giant blocks of text
The socket path built would be libvirt//var/run/libvirt-sock
instead of /var/run/libvirt/libvirt-sock. Fortunately this only
affects users who have set the 'unix_sock_dir' config parameter
in /etc/libvirt/libvirtd.conf, which is pretty rare/unusual.
Signed-off-by: eater <=@eater.me>
Exception made for the psuedonym above since patch is considered
trivial & thus non-copyrightable material.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In some places where virDomainObjListForEach() is called the
passed callback calls virDomainObjListRemoveLocked(). Well, this
is unsafe, because the former only grabs a read lock but the
latter modifies the list.
I've identified the following unsafe calls:
- qemuProcessReconnectAll()
- libxlReconnectDomains()
The rest seem to be safe.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virDomainObjCheckActive() returns -1 if domain is not active, not 0.
Fixes cb50436c6f "libxl: implement virDomainPM* functions"
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
This is an issue for LXC loop devices when you are trying to get loop
devices info using `ioctl`. Modern apps uses `/sys/dev/block` to grab
information about devices, but if you use the method mention you won't
be able to retrive the associated file with that loop device. See
example below from cryptsetup sources:
static char *_ioctl_backing_file(const char *loop)
{
struct loop_info64 lo64 = {0};
int loop_fd;
loop_fd = open(loop, O_RDONLY);
if (loop_fd < 0)
return NULL;
if (ioctl(loop_fd, LOOP_GET_STATUS64, &lo64) < 0) {
close(loop_fd);
return NULL;
}
lo64.lo_file_name[LO_NAME_SIZE-2] = '*';
lo64.lo_file_name[LO_NAME_SIZE-1] = 0;
close(loop_fd);
return strdup((char*)lo64.lo_file_name);
}
It will return an empty string because lo_file_name was not set.
Function `virFileLoopDeviceOpenSearch()` is using `ioctl` to query data,
but it is not checking `lo_file_name` field.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
When the network interface is of "user" type, and QEMU has the "-net
socket,fd=" datagram support, call qemuInterfacePrepareSlirp() to
probe and associate a slirp-helper with the interface.
The usage of automated slirp-helper can be prevented with
disableSlirp (in particular when resuming a
VM that didn't start with slirp-helper before).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If a slirp-helper is associated with a network interface (after
probing & preparing succesfully), pass the socket fd to QEMU and use
"-net socket,fd=".
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If a slirp-helper is associated with a network interface,
prepare/start/stop the process via qemu-extdevice.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For VM started and migrated/saved without slirp-helpers, let's prevent
the automatic setup (as it would fail to migrate otherwise).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Save & restore the slirp helper PID associated with a network
interface & the probed features.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The unit provides the functions associated with a slirp-helper:
- probing / checking capabilities
- opening the socketpair
- starting / stoping the helper
- registering for dbus-vmstate migration
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A slirp helper is a process that provides user-mode networking through
a unix domain socket. It is expected to follow the following
specification:
https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README.rst
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add dbusVMStates to keep a list of dbus-vmstate objects needed for
migration. They are populated on the command line during start or
qemuDBusVMStateAdd/Remove() will hotplug them as needed.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a generic way to run a command through the security management.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
pid filenames (from swtpm and other helpers from this series) are
based on VM shortname, which is derived from VM id. If the id is reset
to early, the state filenames will not be found.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This object is being proposed to qemu upstream "Add dbus-vmstate
object". It handles data migration of external processes.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Datagram socket is available since qemu 4.0, commit
fdec16e3c2a614e2861f3086b05d444b5d8c3406 ("net/socket: learn to talk
with a unix dgram socket").
Required for slirp-helper communication.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Once QEMU is started, the qemuDomainLogContext is owned by it, and can
no longer be used from libvirt. Instead, use
qemuDomainLogAppendMessage() which will redirect the log.
This is not strictly necessary for swtpm, but the following patches
are going to reuse qemuExtDeviceLogCommand().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
dbus_message_new() does not construct correct replies by itself, it is
recommended to use dbus_message_new_method_return() instead.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implicitly the query depth is limited by the length of the QAPI schema
query, but 'alternate' and 'array' QAPI meta-types don't consume a part
of the query string thus a loop on such types would get our traversal
code stuck in an infinite loop. Prevent this from happening by limiting
the nesting depth to 1000.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
After parsing a video device with a model type of
VIR_DOMAIN_VIDEO_TYPE_NONE, all device info is cleared (see
virDomainDefPostParseVideo()) in order to avoid formatting any
auto-generated values for the XML. Subsequently, however, an alias is
generated for the video device (e.g. 'video0'), which results in an
alias property being formatted in the XML output anyway. This creates
confusion if the user has explicitly provided an alias for the video
device since the alias will change.
To avoid this, don't clear the user-defined alias for video devices of
type "none".
https://bugzilla.redhat.com/show_bug.cgi?id=1720612
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When we set cpu.max period we need to parse the cpu.max file first as
it contains both quota and period values separated by space. When only
a single number is written to that file it will set quota. However,
in order to change period we need to write both values.
The code was prepared for that but mistakenly used new line to end the
string with the first value.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1749227
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When blockdev is used we always should use the blockdev mode for
non-shared storage migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Remove libvirt's support check for the target of an external snapshot to
the blockdev code or qemu. This will potentially require a more complex
cleanup but removes a level of hardcoded feature checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the code for creating or attaching new storage source in the
snapshot code and switch to 'blockdev-snapshot' for creating the
snapshot itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With blockdev we'll be able to support protocols which are not supported
by the storage backends in libvirt. This means that we have to be able
to skip the creation and relative storage path reading if it's not
supported. This will make it impossible to use relative backing for
network protocols but that would be almost insane anyways.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After we always assume support for the 'transaction' command
(c358adc571) and follow-up cleanups
qemuDomainSnapshotCreateSingleDiskActive lost its value. Move the code
into appropriate helpers and remove the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix and unify the naming of external snapshot preparation functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make qemuDomainSnapshotDiskDataCleanup cleanup section friendly by
moving the error preservation code inside it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We changed to always saving the status and config XMLs to simplify
code. After a few more refactors it's now possible to move it to the
appropriate place and save the XMLs only on success again.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When we take a snapshot we must properly remove our locking
infrastructure locks. This was broken by commit 3817fa10c4 which
attempted to properly track the readonly state for the image as the
locking code was executed after this change. Since we forced the image
which was locked as read-write to read-only prior to unlocking it the
write lock was not dropped.
Fix it by moving the locking code prior to modifying the readonly flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1745618
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code preparing data for creating/attaching the target image of block
copy didn't use the correct reference to the existing backing chain in
case when the copy should inherit it. This meant that qemu actually
opened a second copy of the chain and operated on that.
This would de-sync qemu from libvirt's view of node names. Luckily this
is only hypothetical at this point since it happens only when -blockdev
is enabled.
Fix it by passing 'mirrorBacking' which has the proper data as the
backing store when calling
qemuBuildStorageSourceChainAttachPrepareBlockdevTop.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In some cases we'll need to pass in a backing store which is not
recorded as the backing store of @src. Export backingStore as variable
and fix all callers to pass in the backing store. No semantic changes
for now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pass backing store as an argument rather than extracting it locally and
fix the callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the loop and supporting infrastructure to the caller as only one
of the two callers actually cares about looping and rename the helper to
qemuBuildStorageSourceChainAttachPrepareBlockdevOne.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pass in backing store explicitly to qemuBlockStorageSourceGetBlockdevProps
and fix the callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move all bits of the formatting of the 'backing' attribute to a single
condition and make it use a single extracted copy of the backing store.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since libvirt stores the backing chain into the XML in a nested way it
is the prime possibility to hit libxml2's parsing limit of 256 layers.
Introduce code which will crawl the backing chain and verify that it's
not too deep. The maximum nesting is set to 200 layers so that there's
still some space left for additional properties or nesting into snapshot
XMLs.
The check is applied to all disk use cases (starting, hotplug, media
change) as well as block copy which changes image and snapshots.
We simply report an error and refuse the operation.
Without this check a restart of libvirtd would result in the status XML
failing to be parsed and thus losing the VM.
https://bugzilla.redhat.com/show_bug.cgi?id=1524278
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With blockdev we must issue the block_set_io_throttle QMP command to
setup disk throttling as we currently can't do it with the 'throttle'
layer.
Unfortunately there's nothing we can do if it fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1733163
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When virtlogd is used to capture QEMU's stdout, qemuDomainObjTaint would
always fail to write the message to the log file when QEMU is already
running (i.e., outside qemuProcessLaunch). This can happen during device
hotplug or by sending a custom QEMU guest agent command:
warning : qemuDomainObjTaint:8757 : Domain id=9 name='blaf'
uuid=9cfa4e37-2930-405b-bcb4-faac1829dad8 is tainted:
custom-ga-command
error : virLogHandlerDomainOpenLogFile:388 : Cannot open log file:
'/var/log/libvirt/qemu/blaf.log': Device or resource busy
error : virNetClientProgramDispatchError:172 : Cannot open log file:
'/var/log/libvirt/qemu/blaf.log': Device or resource busy
The fix is easy, we just need to use the right API for appending a
message to QEMU log file instead of creating a new log context.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'u' modifier creates an unsigned int JSON attribute but the disk size
and capacity fields are unsigned long long. If the size of the created
image would be more than 4GiB we'd overflow and create sub-4G image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The xenapi driver has not seen any development since its initial
contribution 9 years ago. There have been no bug reports, no patches,
and no queries about the driver on the developer or user mailing lists.
Remove the driver from the libvirt sources.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A specially crafted XML which would reference a non-existing disk but
request the mirror to be registered with the blockjob could potentially
make the parser dereference NULL. Fix it by moving the code slightly and
just treat it as a wrong job XML. Found by Coverity.
Reported-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If a block job reaches failed/cancelled state, or is completed
without pivot then we must remove security driver metadata
associated to the backing chain so that we don't leave any
metadata behind.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741456
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
When a block job is completed, the security image metadata are
moved to the new image. If this fails an warning is printed, but
the message contains only domain name and lacks image paths. Put
them both into the warning message.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
Currently, there are only a few lines of code so a separate
function was not necessary, but this will change. So instead of
putting all the new code under 'case
QEMU_BLOCKJOB_TYPE_ACTIVE_COMMIT' create a separate function.
Just like every other case has one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
I guess the reason for that was the automatic interpretation/stringification of
setfilecon_errno, but the code was not nice to read and it was a bit confusing.
Also, the logs and error states get cleaner this way.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Coverity noted that 'reply' can be NULL after calling
qemuAgentCommand(). Avoid dereferencing reply in
qemuAgentErrorComandUnsupported() in that case.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Introduced by commit <c854e0bd33c7a5afb04a36465bf04f861b2efef5> that
tried to fix an issue where we would fail to parse values from files.
We cannot change the original pointer that is going to be used by
VIR_AUTOFREE.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1747440
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
'virQEMUDriverConfigPtr cfg' is declared, initiated, but never
used in virQEMUDriverCreateCapabilities().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
There are some network file systems that do support XATTRs (e.g.
gluster via FUSE). And they appear to support SELinux too.
However, not really. Problem is, that it is impossible to change
SELinux label of a file stored there, and yet we claim success
(rightfully - hypervisor succeeds in opening the file). But this
creates a problem for us - from XATTR bookkeeping POV, we haven't
changed the label and thus if we remembered any label, we must
roll back and remove it.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740506
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is no longer needed because after previous commits
it's just an alias to virSecuritySELinuxSetFilecon.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Now, that we don't need to remember if setting context is
'optional' (the argument only made
virSecuritySELinuxSetFileconImpl() return a different success
code), we can drop it from the _virSecuritySELinuxContextItem
structure as we don't need to remember it in transactions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There is no real difference between
virSecuritySELinuxSetFilecon() and
virSecuritySELinuxSetFileconOptional(). Drop the latter in favour
of the former.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The only thing that the @optional argument does is that it makes
the function return 1 instead of 0 if setting SELinux context
failed in a non-critical fashion. Drop the argument then and
return 1 in that case. This enables caller to learn if SELinux
context was set or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
As qemu documents we should use everything in the 'props' sub-object of
the data returned by query-hotpluggable-cpus. Until now we only used
everything we recognized, but that may break in cases when qemu
introduces new fields.
This change requires a fix to the test data as some fields were
reordered.
https://bugzilla.redhat.com/show_bug.cgi?id=1741658
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
In addition to the data that libvirt needs and extracts internally,
copy and store the whole 'props' JSON sub-object of the data returned by
query-hotpluggable-cpus for future use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
On error paths, info_ret could potentially leak. Make sure it's freed.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
After 7cfb7aab57 commit starting a domain pullutes logs with
warnings like [1]. The reason is resource files do not
have timestamp before starting a domain and after destroying
domain the timestamp is cleared. Let's check the timestamp
only if attribute with refcounter is found.
[1] warning : virSecurityValidateTimestamp:198 : Invalid XATTR timestamp detected on \
/some/path secdriver=dac
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When we're collecting guest information, older agents may not support
all agent commands. In the case where the user requested all info
types (i.e. types == 0), ignore unsupported command errors and gather as
much information as possible. If the agent command failed for some other
reason, or if the user explciitly requested a specific info type (i.e.
types != 0), abort on the first error.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Due to a typo, some of the field names didn't have closing quotes,
the information about the hostname was omitted and there was an
empty line missing after filesystem info description (which helps
our docs generator produce better looking HTML).
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add support to specify a boot order on vfio-ccw passthrough devices.
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Refactoring the method signatures in preparation for
checking boot index of the mediated devices.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Changing the error messages to report the problem encountered.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Moving the hostdev boot support validation from the command line
generator code into the domain validation code.
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
At two places we are open coding xdr_free():
remoteRelayDomainEventTunable() and
remoteRelayDomainEventJobCompleted().
Bot of these functions use make_nonnull_domain() to put domain
IDs tuple into return structure and then continue encoding the
rest of structure. If that fails, they call VIR_FREE() directly.
While this okay, we should use xdr_free() which frees the whole
return structure for us.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If there's a problem in encoding @ret (for instance
virTypedParamsSerialize() fails) then @ret is leaked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The same way we check for limits when decoding typed parameters
(virTypedParamsDeserialize()) we should do the same check when
serializing them so that we don't put onto the wire more than our
limits allow. Surprisingly, we were doing so explicitly in some
places but not all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The return structure is a bit complicated and that's why it is
very easy to check for RPC limits incorrectly. The structure is
an array of remote_domain_stats_record structures with the limit
of REMOTE_DOMAIN_LIST_MAX. The latter structure then poses a
different limit on typed params:
REMOTE_CONNECT_GET_ALL_DOMAIN_STATS_MAX (which is what we are
checking for mistakenly).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Introduced in v3.0.0-rc1~336, the commit message doesn't really
justifies the expensive domain def copy creation. Now, that
vm->def is guarded in this function by job acquirement we can use
vm->def directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These two functions work with vm->def in their critical sections
(i.e. after the job was acquired and before it is released). But
that means, they need QUERY domain job too to prevent vm->def
change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When using systemd socket activation the --listen arg has no
effect. This is confusing to users upgrading from previous versions of
libvirt as their config is silently ignored. Turn use of --listen into a
fatal error when sockets are passed from systemd.
This helps the admin discover the change in behaviour and thus decide
whether to stick with socket activation or revert to previous behaviour.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We need to give users the ability to customize the length of the
shutdown timeout, or even disable timeouts entirely. Thus we must move
the timeout arg into the sysconf file, instead of the service unit.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
To facilitate upgrades from earlier versions of libvirt which did not
use socket activation for libvirtd, we want to allow the libvirtd socket
units to be disabled (masked). This can only be supported if we use the
weaker Wants statement instead of Requires.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All code using LOCALSTATEDIR "/run" is updated to use RUNSTATEDIR
instead. The exception is the remote driver client which still
uses LOCALSTATEDIR "/run". The client needs to connect to remote
machines which may not be using /run, so /var/run is more portable
due to the /var/run -> /run symlink.
Some duplicate paths in the apparmor code are also purged.
There's no functional change by default yet since both expressions
expand to the same value.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Creating various directories using $(runstatedir) instead of
$(localstatedir)/run.
There's no functional change by default yet since both expressions
expand to the same value.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a systemd socket uses /var/run in its path, systemd prints a warning
at runtime
[ 15.139976] systemd[1]: /usr/lib/systemd/system/virtlockd.socket:5:
ListenStream= references a path below legacy directory /var/run/,
updating /var/run/libvirt/virtlockd-sock → /run/libvirt/virtlockd-sock;
please update the unit file accordingly.
This minimal change updates the socket unit files to honour the
$runstatedir path.
There's no functional change by default yet since both expressions
expand to the same value.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The recent cleanups allow us to clean up the code a bit.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
That way devstr will only be used for the device string.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of getting the string then passing it to virCommand.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use separate variables for the chardev and the device.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reduce the scope of the variable to get it freed for every controller
processed.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Simplify the code by annotating all the temporary virBuffers
with VIR_AUTOCLEAN.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After the legacy xen driver was removed the libxl driver became
the only consumer of xenconfig. Move the few files in xenconfig
to the libxl driver and remove the directory.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Iimplements the new guest information API by querying requested
information via the guest agent.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function adds the complete filesystem information returned by the
qemu agent to an array of typed parameters with field names intended to
to be returned by virDomainGetGuestInfo()
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Since version 3.0, qemu has returned disk usage statistics in
guest-get-fsinfo. And since 3.1, it has returned information about the
disk serial number and device node of disks that are targeted by the
filesystem.
Unfortunately, the public API virDomainGetFSInfo() returns the
filesystem info using a virDomainFSInfo struct, and due to API/ABI
guarantees it cannot be extended. So this new information cannot
easily be added to the public API. However, it is possible to add this
new filesystem information to a new virDomainGetGuestInfo() API which
will be based on typed parameters and is thus more extensible.
In order to support these two use cases, I added an internal struct
which the agent code uses to return all of the new data fields. This
internal struct can be converted to the public struct at a cost of some
extra memory allocation.
In a following commit, this additional information will be used within
virDomainGetGuestInfo().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function queries timezone information within the guest and adds
the information to an array of typed parameters with field names
intended to be returned to virDomainGetGuestInfo()
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function queries the guest operating system information and adds
the returned information to an array of typed parameters with field
names intended to be returned in virDomainGetGuestInfo().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function fetches the list of logged-in users from the qemu agent
and adds them to a list of typed parameters so that they can be used
internally in libvirt.
Also add some basic tests for the function.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Add daemon and client code to serialize/deserialize
virDomainGetGuestInfo().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This API is intended to aggregate several guest agent information
queries and is ispired by stats API virDomainListGetStats(). It is
anticipated that this information will be provided by a guest agent
running within the domain.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Move the internals into qemuDomainSnapshotDiskDataCollectOne to make it
obvious what's happening after moving more code here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Soon we'll allow more protocols and storage types with snapshots where
we in some cases can't check whether the storage already exists.
Restrict the sanity checks whether the destination images exist or not
for local storage where it's easy. For any other case we will fail
later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refactor the code to avoid having a cleanup label. This will simplify
the change necessary when restricting this check in an upcoming patch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
dd->src is always allocated in this function as it contains the new
source for the snapshot which is meant to replace the disk source.
The label handling code executed if that source was not present thus is
dead code. Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the VM is running the persistent source of a disk might differ
e.g. as the 'newDef' was redefined. Our snapshot code would blindly
rewrite the source of such disk if it shared the 'target'. Fix this by
checking whether the source is the same in the first place.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Using inline authentication for storage volumes will not work properly
as libvirt requires use of the secret driver for the auth data and
thus would not be able to represent the passwords stored in the backing
store string.
Make sure that the backing store parsers return 1 which is a sign for
the caller to not use the file in certain cases.
The test data include iscsi via a json pseudo-protocol string and URIs
with the userinfo part being present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virStorageFileGetMetadataRecurse would include files in the backing
chain which would not really be usable by libvirt directly e.g.
when such file would be promoted to the top layer by an active block
commit as for example inline authentication data can't be represented in
the VM xml file. The idea is to use secrets for this.
With the changes to the backing store string parsers we can report and
propagate if such a thing is present in the configuration and thus start
skipping those files in the backing chain traversal code. This approach
still allows to report the appropriate backing store string in the
storage driver which doesn't directly use the backing file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virStorageFileGetMetadata does not report error if we can't interrogate
the file somehow. Clarify this in the description of the @report_broken
flag as it implies we should report an error in that case. The problem
is that we don't know whether there's a problem and unfortunately just
offload it to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce new semantics to virStorageSourceNewFromBacking and some
of the helpers used by it which propagate the return value from the
callers.
The new return value introduced by this patch allows to notify the
calller that the parsed virStorageSource correctly describes the source
but contains data such as inline authentication which libvirt does not
want to support directly. This means that such file would e.g. unusable
as a storage source (e.g. when actively commiting the overlay to it) or
would not work with blockdev.
The caller will then be able to decide whether to consider this backing
file as viable or just fall back to qemu dealing with it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Return the parsed storage source via an pointer in arguments and return
an integer from the function. Describe the semantics with a comment for
the function and adjust callers to the new semantics.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virStorageSourceParseBackingURI will report special return values in
some cases. Preserve it in virStorageSourceParseBackingJSONUriStr.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Return the storage source definition via a pointer in the arguments and
document the returned values. This will simplify the possibility to
ignore certain backing store types which are not representable by
libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free the 'root' temporary variable to get rid of some
complexity.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically clean the 'uri' variable and get rid of the 'cleanup'
label.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free the intermediate JSON data to get rid of the cleanup
section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit fb64e176f4 forgot to delete the check that short-circuits the
disk alias creation if the alias is already present. The side effect
of this is that the creation qomName which is necessary to be able to
refer to disk frontends when -blockdev is used was skipped when user
aliases are used.
Fix it by deleting the check. Also prevent any potential memory leaks
from calling this function repeatedly by creating the qomName only when
it's not present.
https://bugzilla.redhat.com/show_bug.cgi?id=1741838
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In my recent patches I've introduced
virStoragePoolObjIsStarting() which is then used to protect
storage pool definition when the pool object is locked and
unlocked during long running jobs. Well, my patches did not
anticipate that @obj can be NULL under 'cleanup' label in
storagePoolCreateXML() (for instance when parsing XML fails).
This imperfection is causing libvirtd to crash then.
Fixes: 13284a6b83 storage_driver: Protect pool def during startup and build
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
>From ld(1):
By default all references resolved to a dynamic library record the
library to which they were resolved. At runtime, dyld uses that
information to directly resolve symbols. The alternative is to use the
-flat_namespace option. With flat namespace, the library is not
recorded. At runtime, dyld will search each dynamic library in load
order when resolving symbols. This is slower, but more like how other
operating systems resolve symbols.
That fixes the set of tests that preload a mock library to replace
library symbols:
qemublocktest
qemumonitorjsontest
viriscsitest
virmacmaptest
virnetserverclienttest
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
After my previous patches we have virPCIDeviceBindToStub() and
virPCIDeviceUnbindFromStub() which really do nothing but call
virPCIDeviceBindToStubWithOverride() and
virPCIDeviceUnbindFromStubWithOverride() respectively.
Drop "WithOverride" from the names and drop the thin wrappers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
As stated in 84f9358b18 all kernels that we are interested in
have 'drivers_override'. Drop the other, older style of
overriding PCI device driver - newid.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This function is no longer used after previous commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Now that no one uses KVM style of PCI assignment we can safely
remove 'pci-stub' backend.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The KVM assignment is going to be removed shortly. Don't let the
hostdev module configure it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
After previous commits, the function is not used anymore.
Remove it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
There are two places where we need to create virPCIDevice from
given virDomainHostdevDef. In both places the code is duplicated.
Move them into a single function and call it from those two
places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
KVM style of PCI devices assignment was dropped in kernel in
favor of vfio pci (see kernel commit v4.12-rc1~68^2~65). Since
vfio is around for quite some time now and is far superior
discourage people in using KVM style.
Ideally, I'd make QEMU_CAPS_VFIO_PCI implicitly assumed but turns
out qemu-3.0.0 doesn't support vfio-pci device for RISC-V.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1711789
Starting up or building some types of pools may take a very long
time (e.g. a misconfigured NFS). Holding the pool object locked
throughout the whole time hurts concurrency, e.g. if there's
another thread that is listing all the pools.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In near future the storage pool object lock will be released
during startPool and buildPool callback (in some backends). But
this means that another thread may acquire the pool object lock
and change its definition rendering the former thread access not
only stale definition but also access freed memory
(virStoragePoolObjAssignDef() will free old def when setting a
new one).
One way out of this would be to have the pool appear as active
because our code deals with obj->def and obj->newdef just fine.
But we can't declare a pool as active if it's not started or
still building up. Therefore, have a boolean flag that is very
similar and forces virStoragePoolObjAssignDef() to store new
definition in obj->newdef even for an inactive pool. In turn, we
have to move the definition to correct place when unsetting the
flag. But that's as easy as calling
virStoragePoolUpdateInactive().
Technically speaking, change made to
storageDriverAutostartCallback() is not needed because until
storage driver is initialized no storage API can run therefore
there can't be anyone wanting to change the pool's definition.
But I'm doing the change there for consistency anyways.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If there's a persistent storage and user tries to start a new one
with the same name and UUID (e.g. to test new configuration) it
may happen that upon failure we lose the persistent defintion.
Fortunately, we don't remove it from the disk only from the
internal list of the pools.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This flag can be used to denote that the definition we're trying
to assign to a pool object is live definition and thus the
inactive definition should be saved into ->newDef.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Separate storage pool definition assignment into a function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There will be more boolean information that we want to pass to
this function. Instead of having them in separate arguments per
each one, use @flags.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function is doing much more than plain assigning pool
definition to a pool object. Rename it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There is no need for this function to call
virStoragePoolObjEndAPI(). The object is perfectly usable after
return from this function. In fact, all callers will call
virStoragePoolObjEndAPI() eventually.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function comment mistakenly refers to 'poolptr' when in fact
the variable is named 'objptr'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turns out there's one callback that might remove a storage pool
during its run: storagePoolUpdateAllState() call
storagePoolUpdateStateCallback() which may call
virStoragePoolUpdateInactive() which in turn may call
virStoragePoolObjRemove(). Problem is that the
UpdateStateCallback() sees a storage pool object with just two
references: one for each hash table holding the object. If the
function ends up calling ObjRemove() then upon removing the
object from hash tables those references are gone and thus any
subsequent call touching the object is invalid.
The solution to this problem is to grab reference for the object
we are running iterator with.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fact that we're removing a pool object from the list of pools
doesn't mean we want to unlock it. It violates locking policy
too as object locking and unlocking is not done on the same
level.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It may happen that we leave some XATTRs behind. For instance, on
a sudden power loss, the host just shuts down without calling
restore on domain paths. This creates a problem, because when the
host starts up again, the XATTRs are there but they don't reflect
the true state and this may result in libvirt denying start of a
domain.
To solve this, save a unique timestamp (host boot time) among
with our XATTRs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741140
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This module contains function to get host boot time.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
If user has two domains, each have the same disk (configured for
RW) but each runs with different seclabel then we deny start of
the second domain because in order to do that we would need to
relabel the disk but that would cut the first domain off. Even if
we did not do that, qemu would fail to start because it would be
unable to lock the disk image for the second time. So far, this
behaviour is expected. But what is not expected is that we
increase the refcounter in XATTRs and leave it like that.
What happens is that when the second domain starts,
virSecuritySetRememberedLabel() is called, and since there are
XATTRs from the first domain it increments the refcounter and
returns it (refcounter == 2 at this point). Then callers
(virSecurityDACSetOwnership() and
virSecuritySELinuxSetFileconHelper()) realize that refcounter is
greater than 1 and desired seclabel doesn't match the one the
disk image already has and an error is produced. But the
refcounter is never decremented.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740024
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Simplify the command line formatter by complicating the validator.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Apparently /proc/self is automatically converted to /proc/@{pid}
before checking rules, which makes spelling it out explicitly
redundant.
Suggested-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The function takes raw UUID and formats it into string
representation. However, the comment mistakenly states that the
expected size of raw UUID buffer is VIR_UUID_RAW_LEN bytes. We
don't have such constant since v0.3.2~24. It should have been
VIR_UUID_BUFLEN.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Store the namespace URI as const char*, instead of in a function.
Suggested-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
A wrapper around xmlXPathRegisterNs that will save us
from having to include xpathInternals.h everywhere
we want to use a custom namespace and open-coding
the strings already contained in virXMLNamespace.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
A function to automatically format the xmlns:<prefix>='<uri>'
attribute for per-driver namespaces.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We have hardcoded the namespace prefix in various places:
1) the xmlns string stored in the 'href' function
2) the xmlXPathRegisterNs call in each parser
3) all the parsing and formatting code actually dealing
with these elements
While eliminating the third one is probably a job for an
actual XML-aware formatter, let's store the prefix separately
here in the virXMLNamespace structure so that future patches
can get rid of the first two bullets.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Now that virDomainXMLNamespace matches virXMLNamespace,
we no longer need to keep both around.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
There is no need to copy and paste the same types pointing
to void all over the place.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
There is no need to copy and paste the same types pointing
to void all over the place.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
For various XMLs, we allow a custom namespace for passing unsupported
configurations.
Introduce a single structure to hold all the driver-specific functions
to remove duplication.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In the future we will perform more actions if ns.parse
is present. Decouple the condition from the actual call.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We do not need to pass the root node, since it's already
included in the XPathContext.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Neither the xmlDocPtr nor the root xmlNode (also passed
in the XPathContext) are interesting to the callees.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
After a successful call to libxl_domain_suspend_only(), set domain
state to VIR_DOMAIN_PMSUSPENDED and send lifecycle event.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
A libxl event with shutdown reason LIBXL_SHUTDOWN_REASON_SUSPEND
is sent after a domain is successfully suspended, which could result
from suspending the domain to file (virDomainSave), suspending it to
socket (virDomainMigrate), or suspending it to memory
(virDomainPMSuspendForDuration). Commit d00c77ae changed the event
handler to always set domain state to VIR_DOMAIN_PMSUSPENDED when
LIBXL_SHUTDOWN_REASON_SUSPEND is received. The causes a persistent
domain to show state "pmsuspended" after a successful migrate or save
operation. Revert the commit and ignore the suspend event as before.
This reverts commit d00c77ae45.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
If the first value in cpu.max is "max" return from function.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741837
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Our virStrToLong* helpers converts string to integers where it wraps
strtol standard function. After the conversion happens and there are
some remaining invalid characters our helpers will fail if the second
argument is NULL.
We need to pass pointer to string in cases where there are multiple
values in a single file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741825
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
resctrl object stored in def->resctrls is shared by cachetune and
memorytune. The domain xml configuration is parsed firstly for
cachetune then memorytune, and the resctrl object will not be created
in parsing settings for memorytune once it found sharing exists.
But resctrl is improperly freed when sharing happens.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If LXC is disabled at build time then there is no
libvirt_driver_lxc_impl_la-*.lo to run the 'check-protocol'
against.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Gnulib has added a patch that allows configmake.h to be included
without causing build failures on mingw if <winsock2.h> is later
included (whether directly, or indirectly such as through gnulib's
<unistd.h>).
This reverts commit fed58d83c6 ("build:
Fix checkpoint_conf on mingw"), now that we don't have to worry about
header inclusion ordering issues.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since
commit 432faf259b
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Tue Jul 2 19:49:51 2019 +0200
virCommand: use procfs to learn opened FDs
When spawning a child process, between fork() and exec() we close
all file descriptors and keep only those the caller wants us to
pass onto the child. The problem is how we do that. Currently, we
get the limit of opened files and then iterate through each one
of them and either close() it or make it survive exec(). This
approach is suboptimal (although, not that much in default
configurations where the limit is pretty low - 1024). We have
/proc where we can learn what FDs we hold open and thus we can
selectively close only those.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
v5.5.0-173-g432faf259b
programs using the virCommand APIs on Linux need read access to
/proc/self/fd, or they will fail like
error : virCommandWait:2796 : internal error: Child process
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c
-u libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6) unexpected exit
status 1: libvirt: error : cannot open directory '/proc/self/fd':
Permission denied
virt-aa-helper: error: apparmor_parser exited with error
Update the AppArmor profile for virt-aa-helper so that read access
to the relevant path is granted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way we're processing the return status, using WIFEXITED() and
friends, only works when we have the raw return status; however,
virCommand defaults to processing the return status for us. Call
virCommandRawStatus() before virCommandRun() so that we get the raw
return status and the logic can actually work.
This results in guest startup failures caused by AppArmor issues
being reported much earlier: for example, if virt-aa-helper exits
with an error we're now reporting
error: internal error: cannot load AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
instead of the misleading
error: internal error: Process exited prior to exec: libvirt:
error : unable to set AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
for '/usr/bin/qemu-system-x86_64': No such file or directory
Suggested-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now we're using the virRun() convenience API, but that
doesn't allow the kind of control we want. Use the virCommand
APIs directly instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The nwfilter XML configs are not merely examples, they are data that is
actively shipped and used in production by users.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU-4.1 supports 'Direct Mode' for Hyper-V synthetic timers
(hv-stimer-direct CPU flag): Windows guests can request that timer
expiration notifications are delivered as normal interrupts (and not
VMBus messages). This is used by Hyper-V on KVM.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Support 'Direct Mode' for Hyper-V Synthetic Timers in domain config.
Make it 'stimer' enlightenment option as it is not a separate thing.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The virHostdevPreparePCIDevices() function works in several
steps. In the very first one, it checks if devices we want to
detach from the host are not taken already by some other domain.
However, this piece of code returns different results depending
on the stub driver used (which is not wrong per se, but keep on
reading). If the stub driver is KVM then
virHostdevIsPCINodeDeviceUsed() is called which basically checks
if a PCI device from the detach list is not used by any domain
(including the one we are preparing the device for). If that is
the case, an error is reported ("device in use") and -1 is
returned.
However, that is not what happens if the stub driver is VFIO. If
the stub driver is VFIO, then we iterate over all PCI devices
from the same IOMMU group and check if they are taken by some
other domain (because a PCI device, well IOMMU group, can't be
shared between two or more qemu processes). But we fail to check,
if the device we are trying to detach from the host is not
already taken by a domain. That is, calling
virHostdevPreparePCIDevices() over a hostdev device twice
succeeds the first time and fails too late in the second run
(fortunately, virHostdevResetAllPCIDevices() will throw an error,
but this is already too late because the PCI device in question
was moved to the list of inactive PCI devices and now it appears
in both lists).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
It may happen that there are two domains with the same name in
two separate drivers (e.g. qemu and lxc). That is why for PCI
devices we track both names of driver and domain combination
which has taken the device. However, when we check if given PCI
device is in use (or PCI devices from the same IOMMU group) we
compare only domain name. This means that we can mistakenly claim
device as free to use while in fact it isn't.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
virErrorPreserveLast()/virErrorRestore() (added in commit 8333e7455
back in 2017), do a better better job of saving and restoring the last
libvirt error than virSaveLastError()/virErrorRestore() (they're
simpler, and they also save/restore the system errno).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
During networkPortCreateXML, if networkAllocatePort() failed,
networkReleasePort() would be called, which would (in the case of
network pools of macvtap passthrough devices) attempt to find the
allocated device by comparing port->plug.direct.linkdev to each device
in the pool. Since port->plug.direct.linkdev was still NULL, the
attempted strcmp would result in a SEGV.
Calling networkReleasePort() during error cleanup is something that
should only be done if networkAllocatePort() has already succeeded. It
turns out there is one other possible error exit from
networkPortCreateXML() that happens after networkAllocatePort() has
succeeded, so the code to call networkReleasePort() was just moved
down to there.
Resolves: https://bugzilla.redhat.com/1741390
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit e69444e17 (first appeared in libvirt-5.5.0) added the new value
"VIR_ACCESS_PERM_NETWORK_SEARCH_PORTS" to the virAccessPerNetwork
enum, and also the string "search_ports" to the VIR_ENUM_IMPL() macro
for that enum. Unfortunately, the enum value was added in the middle
of the list, while the string was added to the end of the
VIR_ENUM_IMPL().
This patch corrects that error by moving the new value to the end of
the enum definition, so that the order matches that of the string
list.
Resolves: https://bugzilla.redhat.com/1741428
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we support blockdev for qemuDomainBlockCopy we can allow
copying to remote destinations as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement job handling for the block copy job (drive/blockdev-mirror)
when using -blockdev. In contrast to the previously implemented
blockjobs the block copy job introduces new images to the running qemu
instance, thus requires a bit more handling.
When copying to new images the code now makes use of blockdev-create to
format the images explicitly rather than depending on automagic qemu
behaviour.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU finally exposes an interface which allows us to instruct it to
format or create arbitrary images. This is required for blockdev
integration of block copy and snapshots as we need to pre-format images
prior to use with blockdev-add.
This path introduces job handling and also helpers for formatting and
attaching a whole image described by a virStorageSource.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than copying just the top level image, let's copy the full user
provided backing chain.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only code path which calls the parser with the
VIR_DOMAIN_DEF_PARSE_DISK_SOURCE is from qemuDomainBlockCopy. Since that
code path can properly handle backing chains for the disk and it's
desired to pass the parsed chains to the block copy code remove the
condition which prevents parsing the <backingStore> element.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In commit 3f93884a4d where the job handling of commit jobs with
blockdev was added I've forgot to add a 'break' in the switch fomatting
the status XML. Thankfully this would not be a problem as the cases
where this fell through didn't have any code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The utility of the function is extremely limited as for block copy
we need to register the mirror chain earlier than when it's set with the
disk. This means that it would be open-coded in that case.
Avoid any weird usage and just open-code the only current usage, remove
the function, and reword the docs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 16ca234b56 refactored how the 'shallow' and 'reuse' flags
are accessed but neglected to fix the clearing of 'shallow' in case when
the disk has no backing chain. This means that we'd request a shallow
copy even without backing chain and also a few checks would work wrong.
Fix it by using the extracted variable everywhere.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow reusing original backing chain when doing a shallow copy without
reuse of external image. The existing logic didn't allow it but it will
be possible. Also add a note to explain that logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename qemuDomainObjPrivateXMLFormatBlockjobFormatChain to
qemuDomainObjPrivateXMLFormatBlockjobFormatSource and add a 'chain'
parameter which allows controlling whether the backing chain is
formatted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function ignores all errors from qemuStorageLimitsRefresh by calling
virResetLastError. This still logs them. Since qemuStorageLimitsRefresh
allows suppressing some, do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuStorageLimitsRefresh uses qemuDomainStorageOpenStat internally and
there are callers which don't care about the error. Propagate the
skipInaccessible flag so that we can log less errors.
Callers currently don't care about the return value change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the callers of qemuDomainStorageUpdatePhysical care about
errors.
Use the new flag for qemuDomainStorageOpenStat which suppresses some
errors and move the reset of the rest of the uncommon errors into this
function. Document what is happening in a comment for the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virStorageSourceUpdatePhysicalSize is called only from
qemuDomainStorageUpdatePhysical and all callers of it reset the libvirt
error if -1 is returned.
Don't bother setting the error in the first place.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some callers of this function actually don't care about errors and reset
it. The message is still logged which might irritate users in this case.
Add a boolean flag which will do few checks whether it actually makes
sense to even try opening the storage file. For local files we check
whether it exists and for remote files we at first see whether we even
have a storage driver backend for it in the first place before trying to
open it.
Other problems will still report errors but these are the most common
scenarios which can happen here.
This patch changes the return value of the function so that the caller
is able to differentiate the possibilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function will be reused in the qemu snapshot code. The argument is
turned into const similarly to the other virStorageFileSupports*
functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the nbd export name contains a colon, our parser would not parse it
properly as we split the string by colons. Modify the code to look up
the exportname and copy any trailing characters as the export name is
supposed to be at the end of the string.
https://bugzilla.redhat.com/show_bug.cgi?id=1733044
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The parent bridge configuration of the current device
should be read and reset, instead of reading the current
device configuration.
Signed-off-by: He Xin <hexin15@baidu.com>
Signed-off-by: Liu Qi <liuqi16@baidu.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since users can enable/disable drivers at compile time, it may
happen that @drivers array is in fact empty (in both its
occurrences within the function). This means that
ARRAY_CARDINALITY() returns 0UL which makes gcc unhappy because
of loop condition:
i < ARRAY_CARDINALITY(drivers)
GCC complains that @i is unsigned and comparing an unsigned value
against 0 is always false. However, changing the type of @i to
ssize_t is not enough, because compiler still sees the unsigned
zero. The solution is to typecast the ARRAY_CARDINALITY().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Introduced in commit 4a6ee53581.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
(cherry picked from commit df1b5cf02e)
Reintroduced-by: fb275b7673
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Add virStorageFileSupportsCreate which allows silent check whether
virStorageFileCreate is implemented.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modify the return value so that callers don't have to repeat logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This helper extracts common lifecycle action code from both
testDomainShutdownFlags and testDomainReboot.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
All the callers left require virPCIDeviceConfigOpen to be fatal
and only use read-only access to the config file.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For callers that only need read-only access and don't want
an error reported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Only a handful of function need write access to the PCI config
space. Create a wrapper function for those so that we can
open it read only by default.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As a side effect, this also silences the possible:
internal error: Unable to get DBus system bus connection:
Failed to connect to socket /run/dbus/system_bus_socket:
No such file or directory
error, since we check upfront whether dbus is available.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Look up the binary name upfront to avoid the error:
Cannot find 'pm-is-supported' in path: No such file or directory
In that case, we just assume nodesuspend is not available.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Get rid of the ret variable as well as the cleanup label.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
When QEMU supports flushing caches at the end of migration, we can
safely allow migration even if disk/driver/@cache is not none nor
directsync.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-By: Peter Krempa <pkrempa@redhat.com>
QEMU 4.0.0 and newer automatically drops caches at the end of migration.
Let's check for this capability so that we can allow migration when disk
cache is turned on.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-By: Peter Krempa <pkrempa@redhat.com>
The original message was logically incorrect: cache != none or cache !=
directsync is always true. But even replacing "or" with "and" doesn't
make it more readable for humans.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-By: Peter Krempa <pkrempa@redhat.com>
In the first stage of incoming migration (qemuMigrationDstPrepareAny) we
call qemuMigrationEatCookie when there's no vm object created yet and
thus we don't have any private data to pass.
Broken by me in commit v5.6.0-109-gbf15b145ec.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This reverts commit f38d553e2d.
Gnulib's make coverage (or init-coverage, build-coverage, gen-coverage)
is not a 1-1 replacement for the original configure option. Our old
--enable-test-coverage seems to be close to gnulib's make build-coverage
except gnulib runs lcov in that phase and the build actually fails for
me even before lcov is run. And since we want to be able to just build
libvirt without running lcov, I suggest reverting to our own
implementation.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-By: Eric Blake <eblake@redhat.com>
Back in July 2010, commit 6ea90b84 (meant to resolve
https://bugzilla.redhat.com/571991 ) added code to set the MAC address
of any tap device to the associated guest interface's MAC, but with
the first byte replaced with 0xFE. This was done in order to assure
that
1) the tap MAC and guest interface MAC were different (otherwise L2
forwarding through the tap would not work, and the kernel would
repeatedly issue a warning stating as much).
2) any bridge device that had one of these taps attached would *not*
take on the MAC of the tap (leading to network instability as
guests started and stopped)
A couple years later, https://bugzilla.redhat.com/798467 was filed,
complaining that a user could configure a tap-based guest interface to
have a MAC address that itself had a first byte of 0xFE, silently
(other than the kernel warning messages) resulting in a non-working
configuration. This was fixed by commit 5d571045, which logged an
error and failed the guest start / interface attach if the MAC's first
byte was 0xFE.
Although this restriction only reduces the potential pool of MAC
addresses from 2^46 (last two bits of byte 1 must be set to 10) by
2^32 (still 4 orders of magnitude larger than the entire IPv4 address
space), it also means that management software that autogenerates MAC
addresses must have special code to avoid an 0xFE prefix. Now after 7
years, someone has noticed this restriction and requested that we
remove it.
So instead of failing when 0xFE is found as the first byte, this patch
removes the restriction by just replacing the first byte in the tap
device MAC with 0xFA if the first byte in the guest interface is
0xFE. 0xFA is the next-highest value that still has 10 as the lowest
two bits, and still
2) meets the requirement of "tap MAC must be different from guest
interface MAC", and
3) is high enough that there should never be an issue of the attached
bridge device taking on the MAC of the tap.
The result is that *any* MAC can be chosen by management software
(although it would still not work correctly if a multicast MAC (lowest
bit of first byte set to 1) was chosen), but that's a different
issue).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com
QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint")
This patch adds a new KVM feature 'hint-dedicated' to set this performance
hint for KVM guests. The feature is off by default.
To enable this hint and have libvirt add "-cpu host,kvm-hint-dedicated=on"
to the QEMU command line, the following XML code needs to be added to the
guest's domain description in conjunction with CPU mode='host-passthrough'.
<features>
<kvm>
<hint-dedicated state='on'/>
</kvm>
</features>
...
<cpu mode='host-passthrough ... />
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The various distros have the following libxml2 vesions:
CentOS 7: 2.9.1
Debian Stretch: 2.9.4
FreeBSD Ports: 2.9.9
Ubuntu 16.04 LTS: 2.9.3
Based on this sampling, we can reasonably bump libxml2 min
version to 2.9.1
The 'query_raw' struct field was added in version 2.6.28,
so can be assumed to exist.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU shows a warning message if partial NUMA mapping is set. This patch
adds a warning message in libvirt when editing the XML. It must be an
error in future, when QEMU remove this ability.
Signed-off-by: Maxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically URIs handled by the remote driver will always connect to
the libvirtd UNIX socket. There will now be one daemon per driver, and
each of these has its own UNIX sockets to connect to.
It will still be possible to run the traditional monolithic libvirtd
though, which will have the original UNIX socket path.
In addition there is a virproxyd daemon that doesn't run any drivers,
but provides proxying for clients accessing libvirt over IP sockets, or
tunnelling to the legacy libvirtd UNIX socket path.
Finally when running inside a daemon, the remote driver must not reject
connections unconditionally. For example, the QEMU driver needs to be
able to connect to the network driver. The remote driver must thus be
willing to handle connections even when inside the daemon, provided no
local driver is registered.
This refactoring enables the remote driver to be able to connect to the
per-driver daemons. The URI parameter "mode" accepts the values "auto",
"direct" and "legacy" to control which daemons are connected to.
The client side libvirt.conf config file also supports a "remote_mode"
setting which is used if the URI parameter is not set.
If neither the config file or URI parameter set a mode, then "auto"
is used, whereby the client looks to see which sockets actually exist
right now.
The remote driver will only ever spawn the per-driver daemons, or
the legacy libvirtd. It won't ever try to spawn virtproxyd, as
that is only there for IP based connectivity, or for access from
legacy remote clients.
If connecting to a remote host over any kind of ssh tunnel, for now we
must assume only the legacy socket exists. A future patch will introduce
a netcat replacement that is tailored for libvirt to make remote
tunnelling easier.
The configure arg '--with-remote-default-mode=legacy|direct' allows
packagers to set a default at build time. If not given, it will default
to legacy mode.
Eventually the default will switch to direct mode. Distros can choose
to do the switch earlier if desired. The main blocker is testing and
suitable SELinux/AppArmor policies.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ssh, libssh, libssh2 & unix transports all need to use a UNIX socket
path, and duplicate some of the same logic for error checking. Pull this
out into a separate method to increase code sharing.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of open-coding a string -> enum conversion, use the enum helpers
for the remote driver transport. The old code uses STRCASEEQ, so we must
force the URI transport to lowercase for sake of back-compatibility.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtproxyd daemon is merely responsible for forwarding RPC calls to
one of the other per-driver daemons. As such, it does not have any
drivers loaded and so regular auto-probing logic will not work. We need
it to be able to handle NULL URIs though, so must implement some kind of
alternative probing logic.
When running as root this is quite crude. If a per-driver daemon is
running, its UNIX socket will exist and we can assume it will accept
connections. If the per-driver daemon is not running, but socket
autostart is enabled, we again just assume it will accept connections.
The is not great, however, because a default install may well have
all sockets available for activation. IOW, the virtxend socket may
exist, despite the fact that the libxl driver will not actually work.
When running as non-root this is slightly easier as we only have two
drivers, QEMU and VirtualBox. These daemons will likely not be running
and socket activation won't be used either, as libvirt spawns the
daemon on demand. So we just check whether the daemon actually is
installed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the client has a connection to one of the hypervisor specific
daemons (eg virtqemud), the app may still expect to use the secondary
driver APIs (storage, network, etc). None of these will be registered in
the hypervisor daemon, so we must explicitly open a connection to each
of the daemons for the secondary drivers we need.
We don't want to open these secondary driver connections at the same
time as the primary connection is opened though. That would mean that
establishing a connection to virtqemud would immediately trigger
activation of virtnetworkd, virnwfilterd, etc despite that that these
drivers may never be used by the app.
Thus we only open the secondary driver connections at time of first use
by an API call.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the event (un)registration methods are invoked while no connection is
open, they jump to a cleanup block which unlocks a mutex which is not
currently locked.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The client parameter is always used to get access to the private data
struct.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The admin client now supports addressing the per-driver daemons using
the obvious URI schemes for each daemon. eg virtqemud:///system
virtqemud:///session, etc.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvzd daemon will be responsible for providing the vz API
driver functionality. The vz driver is still loaded by the main
libvirtd daemon at this stage, so virtvzd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtbhyved daemon will be responsible for providing the bhyve API
driver functionality. The bhyve driver is still loaded by the main
libvirtd daemon at this stage, so virtbhyved must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvboxd daemon will be responsible for providing the vbox API
driver functionality. The vbox driver is still loaded by the main
libvirtd daemon at this stage, so virtvboxd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtlxcd daemon will be responsible for providing the lxc API
driver functionality. The lxc driver is still loaded by the main
libvirtd daemon at this stage, so virtlxcd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtqemud daemon will be responsible for providing the qemu API
driver functionality. The qemu driver is still loaded by the main
libvirtd daemon at this stage, so virtqemud must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtxend daemon will be responsible for providing the libxl API
driver functionality. The libxl driver is still loaded by the main
libvirtd daemon at this stage, so virtxend must not be running at
the same time.
This naming is slightly different than other drivers. With the libxl
driver, the user still has a 'xen:///system' URI, and we provide it
in a libvirt-daemon-xen RPM, which pulls in a
libvirt-daemon-driver-libxl RPM.
Arguably we could rename the libxl driver to "xen" since it is the
only xen driver we have these days, and that matches how we expose it
to users in the URI naming.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnwfilterd daemon will be responsible for providing the nwfilter API
driver functionality. The nwfilter driver is still loaded by the main
libvirtd daemon at this stage, so virtnwfilterd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnodedevd daemon will be responsible for providing the nodedev API
driver functionality. The nodedev driver is still loaded by the main
libvirtd daemon at this stage, so virtnodedevd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtstoraged daemon will be responsible for providing the storage API
driver functionality. The storage driver is still loaded by the main
libvirtd daemon at this stage, so virtstoraged must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtinterfaced daemon will be responsible for providing the interface API
driver functionality. The interface driver is still loaded by the main
libvirtd daemon at this stage, so virtinterfaced must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnetworkd daemon will be responsible for providing the network API
driver functionality. The network driver is still loaded by the main
libvirtd daemon at this stage, so virtnetworkd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.
In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.
We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.
It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.
Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.
Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).
We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages
- We can make virtproxyd and the virtXXXd per-driver daemons all
have "Conflicts: libvirtd.service" in their systemd unit files.
This will guarantee that libvirtd is never started at the same
time, as this would result in two daemons running the same driver.
Fortunately drivers use locking to protect themselves, but it is
better to avoid starting a daemon we know will conflict.
- It allows us to break CLI compat to remove the --listen parameter.
Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
will default to zero. Either TLS or TCP can be enabled exclusively
though virtd.conf without requiring the extra step of adding --listen.
- It allows us to set a strict SELinux policy over virtproxyd. For
back compat the libvirtd policy must continue to allow all drivers
to run. We can't easily give a second policy to libvirtd which
locks it down. By introducing a new virtproxyd we can set a strict
policy for that daemon only.
- It gets rid of the weird naming of having a daemon with "lib" in
its name. Now all normal daemons libvirt ships will have "virt"
as their prefix not "libvirt".
- Distros can more easily choose their upgrade path. They can
ship both sets of daemons in their packages, and choose to
either enable libvirtd, or enable the per-driver daemons and
virtproxyd out of the box. Users can easily override this if
desired by just tweaking which systemd units are active.
After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.
The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.
The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.
The aggressive option is to disable libvirtd if already running
and activate all the new daemons.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When running in libvirtd, we are happy for any of the drivers to simply
skip their initialization in virStateInitialize, as other drivers are
still potentially useful.
When running in per-driver daemons though, we want the daemon to abort
startup if the driver cannot initialize itself, as the daemon will be
useless without it.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
.in suffix.
This won't work in future when a single .in unit file can be used to
generate multiple different units.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd socket unit files with other daemons by
making various parts of their config conditionally defined by the make
rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The make rules for the systemd socket unit files are all essentially
identical and can be collapsed into a single generic rule. The service
unit file rule can be simplified too.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Substitute in the @sysconfigdir@ value instead of /etc.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The same make variables will be useful for building both libvirtd and
the split daemons, so refactor & rename variables to facilitate reuse.
Automake gets annoyed if you define a variable ending LDFLAGS:
src/remote/Makefile.inc.am:53: warning: variable 'REMOTE_DAEMON_LDFLAGS' is defined but no program or
src/remote/Makefile.inc.am:53: library has 'REMOTE_DAEMON' as canonical name (possible typo)
So we trick it by using an LD_FLAGS or LD_ADD suffix instead.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
GNULIB sets $(LIBSOCKET) on mingw to pull in the windows socket
APIs. This is trivially not required, since we don't build libvirtd
on mingw.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd augeas defintions with other daemons by
making the config parameters for IP sockets conditionally defined by
the make rules.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd config to create other daemons by making
the config parameters for IP sockets conditionally defined by the make
rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using @VARNAME@ is a normal style of automake, so lets match that.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the use of IP sockets conditionally defined by the make rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the driver(s) to load conditionally defined by the make rules.
If nothing is set, all drivers will be loaded, ignoring any missing ones
as historically done.
If MODULE_NAME is set only one driver will be loaded and that one must
succeed.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the daemon name conditionally defined by the make rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The remote daemon tries to print out its help text in a couple of giant
blocks of text. This has already lead to duplication of the text for the
privileged vs unprivileged execution mode. With the introduction of more
daemons, this text is going to be duplicated many more times with small
variations. This is very unfriendly to translators as they have to
translate approximately the same text many times with small tweaks.
Splitting the text up into individual strings to print means that each
piece will only need translating once. It also gets rid of all the
layout information from the translated strings, so avoids the problem of
translators breaking formatting by mistake.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of adding generated config files to CLEANFILES and BUILT_SOURCES
in each makefile, add them all at once.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of each subdir containing its own custom rule for checking the
augeas tests, use common rule for all.
The new rule searches both src + build dirs for include files, since
some augeas files will be auto-generated very shortly.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current make rules are inconsistent about which directory the
augeas test files are created in. Put them all in the same dir as
their source.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We already have a variable that lists all augeas test files, so we can
add everything to CLEANFILES at once.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The augeas-gentest.pl program merges a config file into a augeas
file, saving the output to a new file. It is going to be useful
to further process the output file, and it would be easier if this can
be done with a pipeline, so change augeas-gentest.pl to write to stdout
instead of a file.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Each public API is required to log all arguments it was called
with. Except, there are some missing. Fix them.
Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Redefining a domain via virDomainDefineXML should not give different results
based on an already existing definition.
Also, there's a crasher somewhere in the code:
https://bugzilla.redhat.com/show_bug.cgi?id=1739338
This reverts commit 94b3aa55f8
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since its introduction in commit
8737578d11, the TPM version format is
"2.0" and not "2".
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDeviceDefPostParse callback requires qemuCaps, we need
to make sure it gets the capabilities stored in the domain's private
data if the domain is running. Passing NULL may cause QEMU capabilities
probing to be triggered in case QEMU binary changed in the meantime.
When this happens while a running domain object is locked, QMP event
delivered to the domain before QEMU capabilities probing finishes will
deadlock the event loop.
QEMU capabilities lookup (via domainPostParseDataAlloc callback) is
hidden inside virDomainDeviceDefPostParseOne with no way to pass
qemuCaps to virDomainDeviceDef* functions. This patch fixes all
remaining paths leading to virDomainDeviceDefPostParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
Several general snapshot and checkpoint APIs were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefParseNode.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to virDomainDefPostParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
Several general functions from domain_conf.c were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefCopy to do the
right thing.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuMigrationCookieXMLParse.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to virDomainDefParseString.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuMigrationAnyPrepareDef.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainSaveImageOpen.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainDefFormatBufInternal.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.
This patch fixes all paths leading to qemuDomainDefCopy.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the correct enum constant when validating vlan usage.
This fixes a merge error in
commit 6cb0ec48bd
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Mon Sep 3 17:34:22 2018 +0100
network: convert networkAllocateActualDevice to virNetworkPortDef
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Requires adjustments to use verify_expr() which replaces
verify_true(), and to disable the new syntax check
'sc_prohibit_gnu_make_extensions' since we require GNU make.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit fed58d83 was a hack to fix a mingw build failure due to header
inclusion order resulting in a clash over the use of DATADIR,
repeating a trick made several other times in the past. Better is to
revert that, and instead use pragmas to avoid the clash in the first
place, regardless of header ordering, solving it for everyone.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the code does not refer to any libvirt headers,
except internal.h macros, it does not need to link to
any libvirt code, nor gnulib either. The only thing it
needs is yajl.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Thus we only need one API for env passthrough in virCommand.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that none of the libvirt.so code will ever run in a setuid
context, we can remove the virIsSUID() method. The global
initializer function can just inline the check itself. The new
inlined check is slightly stronger as it also looks for a
setgid situation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt-login-shell setuid program is now a tiny piece of code
that only uses standard libc functions, and santizes the execution
environment before invoking the real virt-login-shell-helper.
The latter is thus able to use the normal libvirt.so build,
allowing us to delete the special cut down setuid library build.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If virQEMUDriverGetCapabilities returns NULL, then a subsequent
deref of @caps would cause an error, so we just return failure.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The previous bump to 4.4 was done in:
commit 24241c236e
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Jul 5 10:35:32 2017 +0100
Require use of GCC 4.4 or CLang compilers
with 4.4 picked due to RHEL-6. Since we dropped RHEL-6, the
next oldest distro is RHEL-7 (4.8.5), and thus we pick 4.8
as the new min.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Until now, testDomainGetTime would always return the same fixed values
everytime it was called. By using domain-private data we can make this
API return the values previously set with testDomainSetTime, or use the
same old fixed values in case testDomainSetTime hasn't been called at all.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qemu and vz implementations don't emit any signals when this API is
called, so we can do the same here for now and succeed by doing nothing.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qemu driver already does some <rng> model validation, based on
qemuCaps. However, the logic for exposing <rng> model values in domcaps
is basically identical. This drops the qemuCaps checking and compares
against the domCaps data directly.
This approach makes it basically impossible to add a new <rng> model to
the qemu driver without extending domcaps. The validation can also
be shared with other drivers eventually.
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fill in virDomainCaps at Validate time and use it to call
virDomainCapsDeviceDefValidate
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is an entrypoint to validate a virDomainDeviceDef against
values filled into virDomainCaps.
Currently it's just a stub
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
qemuCaps is tied to a binary on disk. domCaps is tied to a combo
of binary+machine+arch+virttype values. For the qemu driver this almost
entirely translates to a permutation of qemuCaps though
Upcoming patches want to use the domCaps data store at XML validate
time, but we need to cache the data so we aren't repeatedly
regenerating it.
Add a domCapsCache hash table to qemuCaps. This ensures that the domCaps
cache is blown away whenever qemuCaps needs to be regenerated. Similarly
when qemuCaps is invalidated, the next call to virQEMUCapsCacheLookup
will unref qemuCaps and free our cache as well.
Adjust virQEMUDriverGetDomainCapabilities to search the cache and add
to it if we don't find a hit.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For now it's just a helper for building a qemu virDomainCapsPtr,
used in qemuConnectGetDomainCapabilities
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The model logic is taken from qemuDomainRNGDefValidate
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This way it is obvious when adding a new resource control type
that stats helper func needs to be updated too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the host doesn't have resctrl then the monitor is going to be
NULL and we must avoid dereferencing it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capabilities object must be unrefed when no longer needed.
Use VIR_AUTOUNREF() for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Current code doesn't allow us to add sub-features as we always print the
closing '/>'. As a preparatory change to implementing 'direct' sub-feature
for 'stimer' feature switch to printing closing tag individually.
No functional change.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Some Hyper-V features (like the upcoming Direct Synthetic timers) are
announced by feature bits in Edx but KVM_FEATURE_DEF() supports only Eax.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
I find this function more readable if checks for passed storage
source are done first and backing chain is done last. Mixing them
together does not hurt, but is less readable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
This function does not change any of the passed addresses. It
just reads them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
This function does not change any of the passed addresses. It
just reads them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
On success update the domain-private data. Consider / and /boot to be
the only mountpoints avaiable in order to be consistent with the other
FS-related calls.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
vm-specific data can be used by APIs that need to preserve some state
between calls
Some of them are:
- FS-related APIs for remembering which mountpoints are frozen
- virDomainSetTime / virDomainGetTime for maintaining time information
- virDomainSetIOThreadParams for storing the I/O thread parameters
- virDomainManagedSaveDefineXML for internally storing the VM definition
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The main value here is the current balloon value which taken from the
config. All the other values (except for period) are derived by 2^n
division so that compiler prefers bitwise operations. Period value was
kept fixed in order to produce predictable results in a test environment.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This should just forward the call to testDomainCreateXML since we
can't do anything with the provided file descriptors in the test driver.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
This should just forward the call to testDomainCreateWithFlags since we
can't do anything with the provided file descriptors in the test driver.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
The xencommons service provides all the essential services such as
xenstored, xenconsoled, etc. needed by the libvirt Xen driver, so
libvirtd should be started after xencommons.
The xendomains service uses Xen's xl tool to operate on any domains it
finds running, even those managed by libvirt. Add a conflicts on the
xendomains service to ensure it is not enabled when libvirtd is enabled.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This code that executes virPCIDeviceReattach in all
virPCIDevicePtr objects of a given virPCIDeviceListPtr
list is replicated twice in the code. Putting it in a helper
function helps with readability.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virHostdevReattachPCIDevice() is a static that simply does
a wait loop with virPCIDeviceWaitForCleanup() before
calling virPCIDeviceReattach().
This loop traces back to commit d1e5676c0d, aiming to
solve a race condition between Libvirt returning the
device back to the host and QEMU trying to access it in
the meantime, which resulted in QEMU exiting on error
and killing the guest. This happens because device_del
is asynchronous, returning OK even if the guest didn't
release the device. Commit 01abc8a1b8 moved this code
to qemu_hostdev.c, 82e8dd4cf8 added the pci-stub conditional
for the loop, 899b261127 moved the code to virhostdev.c
where it stood until now.
The intent of this wait loop is still valid: device_del
is still not bullet proof into preventing the conditions
that commit d1e5676c0d aimed to fix, especially when considering
all the architectures we must support. However, this loop
is executed only in virHostdevReattachPCIDevice(), leaving
every other virPCIDeviceReattach() call prone to that error.
Let's move the wait loop code to virPCIDeviceReattach(). This
will:
- make every reattach call safe from this race condition
with the pci-stub;
- allow for a bit of code cleanup (virHostdevReattachPCIDevice()
can be erased, and virHostdevReAttachPCIDevices() can use
virPCIDeviceReattach() directly);
- make it easier to understand the overall reattach mechanisms in
Libvirt, without the risk of a newcomer wondering why reattach
is done slightly different in some instances.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This code that executes virPCIDeviceReset in all virPCIDevicePtr
objects of a given virPCIDeviceListPtr list is replicated twice
in the code. Putting it in a helper function helps with
readability.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There is no restriction on maximum value of PCI domain. In fact,
Linux kernel uses plain atomic inc when assigning PCI domains:
drivers/pci/pci.c:static int pci_get_new_domain_nr(void)
drivers/pci/pci.c-{
drivers/pci/pci.c- return atomic_inc_return(&__domain_nr);
drivers/pci/pci.c-}
Of course, this function is called only if kernel was compiled
without PCI domain support or ACPI did not provide PCI domain.
However, QEMU still has the same restriction as us: in
set_pci_host_devaddr() QEMU checks if domain isn't greater than
0xffff. But one can argue that that's a QEMU limitation. We still
want to be able to cope with other hypervisors that don't have
this limitation (possibly).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, the way we format PCI address is using printf-s
precision, e.g. "%.4x". This works if we don't want to print any
value outside of bounds (which is usually the case). However,
turns out, PCI domain can be 0x10000 which doesn't work well with
our format strings. However, if we change the format string to
"%04x" then we still pad small values with zeroes but also we are
able to print values that are larger than four digits. In fact,
this format string used by kernel to print a PCI address:
"%04x:%02x:%02x.%d"
The other three format strings (for bus, device and function) are
changed too, so that we use the same format string as kernel.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The format string for a PCI address is copied over and over
again, often with slight adjustments. Introduce global
VIR_PCI_DEVICE_ADDRESS_FMT macro that holds the formatting string
and use it wherever possible.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In near future, the length restriction of PCI domain is going to
be lifted. This means that our assumption that PCI address is 13
bytes long is no longer true. We can avoid this problem by making
@name dynamically allocated and thus not bother with actual
length of stringified PCI address.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function declares @ret variable and then uses
VIR_STEAL_PTR() to avoid freeing temporary variable @dev which is
constructed. Well, as of 267f1e6da5 we have VIR_RETURN_PTR()
macro so that we can avoid this pattern.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While it's true that older QEMUs were not able to deal with PCI
domains, we don't support those versions anymore (see
4a42ece13a). Therefore it is safe to always format fully
expanded PCI address. Format PCI domain always as it will
simplify next commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A new algorithm for detecting the vcpus and monitor type conflicts
between new monitor an existing allocation and monitor groups.
After refactoring, since we are verifying both @vcpus and monitor
type @tag at the same time, the validating function name has been
renamed from virDomainResctrlMonValidateVcpus to
virDomainResctrlValidateMonitor.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Export virResctrlMonitorGetStats and make
virResctrlMonitorGetCacheOccupancy obsoleted.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor 'virResctrlMonitorStats' to track multiple statistical
records.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor and rename 'virResctrlMonitorFreeStats' to
'virResctrlMonitorStatsFree' to free one
'virResctrlMonitorStatsPtr' object.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'virResctrlAllocIsEmpty' checks if cache allocation or memory
bandwidth allocation settings are specified in configuration
file. It is not proper to be used in checking memory bandwidth
allocation is specified in XML settings because this function
could not distinguish memory bandwidth allocations from cache
allocations.
Here using the local variable @n, which indicates the cache
allocation groups or memory bandwidth groups depending on the
context it is in, to decide if append a new @resctrl object.
If @n is zero and no monitors groups specified in XML, then
we should not append a new @resctrl object to @def->resctrls.
This kind of replacement is also more efficient and avoiding
a long function calling path.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Let 'virDomainResctrlVcpuMatch' to retrieve a pointer of
virDomainResctrlDefPtr in its third parameter instead
of virResctrlAllocPtr, if @vcpus is matched with the vcpus
of some resctrl allocation in list of @def->resctrls.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Creating object and judging if it is successfully created in fewer
lines.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
code cleanup for 'virDomainCachetuneDefParse' and
'virDomainMemorytuneDefParse'.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'default monitor of an allocation' is defined as the resctrl
monitor group that created along with an resctrl allocation,
which is created by resctrl file system. If the monitor group
specified in domain configuration file is happened to be a
default monitor group of an allocation, then it is not necessary
to create monitor group since it is already created. But if
an monitor group is not an allocation default group, you
should create the group under folder
'/sys/fs/resctrl/mon_groups' and fill the vcpu PIDs to 'tasks'
file.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Fortunately, the code that handles metadata getting or setting is
driver agnostic, so all that is needed from individual hypervisor
drivers is to call the right functions.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1732306
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
I messed up formatting during conflict resolution across rebasing
while preparing my checkpoint patches :)
Signed-off-by: Eric Blake <eblake@redhat.com>
hv-spinlocks is not a CPUID feature and should not be checked as such.
While starting a domain with hv-spinlocks enabled, we would report a
warning about unsupported hyperv spinlocks feature even though it was
set properly.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
CI flagged a failing mingw build, due to:
In file included from ../../src/conf/checkpoint_conf.c:24:
../gnulib/lib/configmake.h:8:17: error: expected identifier or '(' before string constant
8 | #define DATADIR "/usr/i686-w64-mingw32/sys-root/mingw/share"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As previously learned in commits bd205a90 and 976abdf6, gnulib's
configmake.h header does #define DATADIR "string...", while mingw's
<winsock2.h> expects to declare a type named DATADIR. As long as the
mingw system header is included first before configmake.h, the two
uses do not conflict, but until gnulib is patched to make configmake.h
automatically work around the issue, our immediate fix is the
workaround of rearranging our include order to insure no conflict.
Copy the paradigm used in domain_conf.c of using <unistd.h> to trigger
the indirect inclusion of <winsock2.h> on mingw.
Fixes: 1a4df34a
Signed-off-by: Eric Blake <eblake@redhat.com>
Turning a NULL URI instead the empty string is very misleading when
reading the debug logs as the distinction between the two is
functionally important.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Originally the names of the KVM CPU features were only used internally
for looking up their CPUID bits. So we used "__kvm_" prefix for them to
make sure the names do not collide with normal CPU features stored in
our CPU map.
But with QEMU 4.1 we check which features were enabled or disabled by a
freshly started QEMU process using their names rather than their CPUID
bits (mostly because of MSR features). Thus we need to change our made
up internal names into the actual names used by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Most of the internally defined KVM CPUID features are not actually used
by libvirt. The QEMU driver may enable or disable them on the command
line, but we don't check for the associated CPU properties or CPUID
bits. They would be useless with QEMU 4.1 anyway since their names were
only remotely similar to the actual feature names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All the features are hyperv features even though they are provided by
KVM with QEMU. The "KVM" part in the macro names does not make a lot of
sense.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with QEMU 4.1, we're using the canonical feature names on the
command line and avoid aliases to prepare for possible deprecation of
all aliases in QEMU. But we do so only for features from our CPU map,
hyperv features defined in the code were unchanged and this patch fixes
it. Some features use "hv-" prefix unconditionally because they were
introduced recently enough to always support spelling with a dash.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally the names of the hyperv CPU features were only used
internally for looking up their CPUID bits. So we used "__kvm_hv_"
prefix for them to make sure the names do not collide with normal CPU
features stored in our CPU map.
But with QEMU 4.1 we check which features were enabled or disabled by a
freshly started QEMU process using their names rather than their CPUID
bits (mostly because of MSR features). Thus we need to change our made
up internal names into the actual names used by QEMU. Most of the names
are only used with QEMU 4.1 and newer and the reset was introduced with
QEMU recently enough to already support spelling with "-". Thus we don't
need to define them as "hv_*" with a translation to "hv-*" for new QEMU.
Without this patch libvirt would mistakenly report all hyperv features
as unavailable and refuse to start any domain using them with QEMU 4.1.
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Earlier patches mentioned that the initial implementation will prevent
snapshots and checkpoints from being used on the same domain at once.
However, the actual restriction is done in this separate patch to make
it easier to lift that restriction via a revert, when we are finally
ready to tackle that integration in the future.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Time to actually issue the QMP transactions that create and delete
persistent checkpoints, resolving TODOs intentionally left earlier in
the series. For create, we only need one transaction: inside, we
visit all disks affected by the checkpoint, and create a new enabled
bitmap, as well as disabling the bitmap of the first ancestor
checkpoint (if any) that also had a bitmap. For deletion, we need
multiple QMP calls: for each disk, if there is an ancestor checkpoint
with a bitmap, then the bitmap must be merged (including activating
the ancestor bitmap if the leaf node changes), all before deleting the
bitmap from the checkpoint being removed.
Signed-off-by: Eric Blake <eblake@redhat.com>
Qemu bitmap operations require knowing the node name associated with
the format layer (the qcow2 file); as upcoming patches will be
grabbing that information frequently, make a helper function to access
it.
Another potential benefit of this function is that we have a single
place where we could insert a QMP node-name scraping call if we don't
currently know the node name, when -blockdev is not supported;
however, the goal is that we hopefully don't ever have to do that
because we instead scrape node names only at the point where they
change.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A lot of this work heavily copies from the existing snapshot APIs.
What's more, this patch is (intentionally) very similar to the
checkpoint code just added in the test driver, to the point that qemu
checkpoints are not fully usable in this patch, but it at least
bisects and builds cleanly. The separation between patches is done
because the grunt work of saving and restoring XML and tracking
relations between checkpoints is common to the test driver, while the
later patch adding integration with QMP is specific to qemu.
Also note that the interlocking to prevent checkpoints and snapshots
from existing at the same time will be a separate patch, to make it
easier to revert that restriction when we finally round out the design
for supporting interaction between the two concepts.
Signed-off-by: Eric Blake <eblake@redhat.com>
This is similar to the existing directory for snapshots; the domain
will save one xml file per checkpoint, for reloading on the next
libvirtd restart. Fortunately, since checkpoints mandate RNG
validation, we are assured that the checkpoint name will be usable as
a file name (no abuse of '../escape' as a checkpoint name, for
example).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce the handler for finalizing a block commit and active bloc
commit job which will allow to use it with blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce the handler for finalizing a block pull job which will allow
to use it with blockdev.
This patch also contains some additional machinery which is required to
store all the relevant job data in the status XML which will also be
reused with other block job types.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In case of an incoming migration we do not need to run swtpm_setup
with all the parameters but only want to get the benefit of it
creating a TPM state file for us that we can then label with an
SELinux label. The actual state will be overwritten by the in-
coming state. So we have to pass an indicator for incomingMigration
all the way to the command line parameter generation for swtpm_setup.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
A lot of this work heavily copies from the existing snapshot APIs.
The test driver doesn't really have to do anything more than just
expose an interface into libvirt metadata, making it possible to test
saving and restoring XML, and tracking relations between multiple
checkpoints.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The remote code generator had to be taught about the new
virDomainCheckpointPtr type, at which point the remote driver code for
checkpoints can be generated.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Creating a checkpoint does not modify guest-visible state,
but does modify host resources. Rather than reuse existing
domain:write, domain:block_write, or domain:snapshot access
controls, it seems better to introduce a new access control
specific to tasks related to checkpoints and incremental
backups of guest disk state.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Wire up the use of a checkpoint list into each domain, similar to the
existing snapshot list. This includes adding a function for checking
that a redefine operation fits in with the existing list, as well as
various filtering capabilities over the list contents.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Create a new file for managing a list of checkpoint objects, borrowing
heavily from existing virDomainSnapshotObjList paradigms.
Note that while snapshots definitely have a use case for multiple
children to a single parent (create a base snapshot, create a child
snapshot, revert to the base, then create another child snapshot),
it's harder to predict how checkpoints will play out with reverting to
prior points in time. Thus, in initial use, given a list of
checkpoints, you never have more than one child, and we can treat the
most-recent leaf node as the parent of the next node creation, without
having to expose a notion of a current node in XML or public API.
However, as the snapshot machinery is already generic, it is easier to
reuse the generic machinery that tracks relations between domain
moments than it is to open-code a new list-management scheme just for
checkpoints (hence, we still have internal functions related to a
current checkpoint, even though that has no observable effect
externally, as well as the addition of a function to easily find the
lone leaf in the list to use as the current checkpoint).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a new file checkpoint_conf.c that performs the translation to and
from new XML describing a checkpoint. The code shares a common base
class with snapshots, since a checkpoint similarly represents the
domain state at a moment in time. Add some basic testing of round trip
XML handling through the new code.
Of note - this code intentionally differs from snapshots in that XML
schema validation is unconditional, rather than based on a public API
flag. We have many existing interfaces that still need to add a flag
for opt-in schema validation, but those interfaces have existing
clients that may not have been producing strictly-compliant XML, or we
may still uncover bugs where our RNG grammar is inconsistent with our
code (where omitting the opt-in flag allows existing apps to keep
working while waiting for an RNG patch). But since checkpoints are
brand-new, it's easier to ensure the code matches the schema by always
using the schema. If needed, a later patch could extend the API and
add a flag to turn on to request schema validation, rather than having
it forced (possibly just the validation of the <domain> sub-element
during REDEFINE) - but if a user encounters XML that looks like it
should be good but fails to validate with our RNG schema, they would
either have to upgrade to a new libvirt that adds the new flag, or
upgrade to a new libvirt that fixes the RNG schema, which implies
adding such a flag won't help much.
Also, the redefine flag requires the <domain> sub-element to be
present, rather than catering to historical back-compat to older
versions.
Signed-off-by: Eric Blake <eblake@redhat.com>
Introduce a bunch of new public APIs related to backup checkpoints.
Checkpoints are modeled heavily after virDomainSnapshotPtr (both
represent a point in time of the guest), although a snapshot exists
with the intent of rolling back to that state, while a checkpoint
exists to make it possible to create an incremental backup at a later
time. We may have a future hypervisor that can completely manage
checkpoints without libvirt metadata, but the first two planned
hypervisors (qemu and test) both always use libvirt for tracking
metadata relations between checkpoints, so for now, I've deferred
the counterpart of virDomainSnapshotHasMetadata for a separate
API addition at a later date if there is ever a need for it.
Note that until we allow snapshots and checkpoints to exist
simultaneously on the same domain (although the actual prevention of
this will be in a separate patch for the sake of an easier revert down
the road), that it is not possible to branch out to create more than
one checkpoint child to a given parent, although it may become
possible later when we revert to a snapshot that coincides with a
checkpoint. This also means that for now, the decision of which
checkpoint becomes the parent of a newly created one is the only
checkpoint with no child (so while there are APIs for dealing with a
current snapshot, we do not need those for checkpoints). We may end
up exposing a notion of a current checkpoint later, but it's easier to
add stuff when proven needed than to blindly support it now and wish
we hadn't exposed it.
The following map shows the API relations to snapshots, with new APIs
on the right:
Operate on a domain object to create/redefine a child:
virDomainSnapshotCreateXML virDomainCheckpointCreateXML
Operate on a child object for lifetime management:
virDomainSnapshotDelete virDomainCheckpointDelete
virDomainSnapshotFree virDomainCheckpointFree
virDomainSnapshotRef virDomainCheckpointRef
Operate on a child object to learn more about it:
virDomainSnapshotGetXMLDesc virDomainCheckpointGetXMLDesc
virDomainSnapshotGetConnect virDomainCheckpointGetConnect
virDomainSnapshotGetDomain virDomainCheckpointGetDomain
virDomainSnapshotGetName virDomainCheckpiontGetName
virDomainSnapshotGetParent virDomainCheckpiontGetParent
virDomainSnapshotHasMetadata (deferred for later)
virDomainSnapshotIsCurrent (no counterpart, see note above)
Operate on a domain object to list all children:
virDomainSnapshotNum (no counterparts, these are the old
virDomainSnapshotListNames racy interfaces)
virDomainSnapshotListAllSnapshots virDomainListAllCheckpoints
Operate on a child object to list descendents:
virDomainSnapshotNumChildren (no counterparts, these are the old
virDomainSnapshotListChildrenNames racy interfaces)
virDomainSnapshotListAllChildren virDomainCheckpointListAllChildren
Operate on a domain to locate a particular child:
virDomainSnapshotLookupByName virDomainCheckpointLookupByName
virDomainSnapshotCurrent (no counterpart, see note above)
virDomainHasCurrentSnapshot (no counterpart, old racy interface)
Operate on a snapshot to roll back to earlier state:
virDomainSnapshotRevert (no counterpart, instead checkpoints
are used in incremental backups via
XML to virDomainBackupBegin)
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If we are using -blockdev, then node names are always available
(because we set them). But when not using it, we have to scrape node
names from QMP, and want to do so as infrequently as possible. We
were scraping node names after reconnecting a new libvirtd to an
existing guest (see qemuProcessReconnect), and after any block job
that may have changed the set of node names we care about (legacy
block jobs), but forgot to scrape the names when first starting a
guest. Do so now in order to allow the checkpoint code to always have
access to a node name without having to repeat a node name scrape
itself.
Future patches may need to clean up qemuDomainSetBlockThreshold (if
node names are always available, then it doesn't need to repeat a
scrape) and/or hotplug and media changes (if the addition of new nodes
can result in a null node name, then scraping at that point in time
would be appropriate). But for now, this patch addresses only the
most common instance of a missing node name.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since we are checking the 2nd parameter in the function for NULL,
we need to remove ATTRIBUTE_NONNULL(2) from the prototype.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-5-stefanb@linux.vnet.ibm.com>
Remove the ATTRIBUTE_NONNULL(1) from virCommandSetSendBuffer()
prototype since we are checking for '!cmd' and move the initialization
if 'i' after the test for '!cmd'.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-4-stefanb@linux.vnet.ibm.com>
Use the existing variables rather then calling virTPMSwtpmXYZ().
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-2-stefanb@linux.vnet.ibm.com>
Create an empty log file if the log file was removed, otherwise the
transaction to set the security labels on the file will fail.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190726210706.24440-3-stefanb@linux.ibm.com>
Set the transactionStarted to false if the commit failed. If this is not
done, then the failure path will report 'no transaction is set' and hide
more useful error reports.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190726210706.24440-2-stefanb@linux.ibm.com>
Starting with QEMU 4.1 qemuMonitorCPUModelInfo structure in virQEMUCaps
stores only canonical feature names which may differ from the name used
by libvirt. We need translate these canonical names into libvirt names
for further consumption.
This fixes a bug in qemuConnectBaselineHypervisorCPU which would remove
all features for which libvirt's spelling differs from the QEMU's
preferred name. For example, the following result of
qemuConnectBaselineHypervisorCPU on my host with QEMU 4.1 is wrong:
<cpu mode='custom' match='exact'>
<model fallback='forbid'>Skylake-Client</model>
<vendor>Intel</vendor>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='clflushopt'/>
<feature policy='require' name='umip'/>
<feature policy='require' name='arch-capabilities'/>
<feature policy='require' name='xsaves'/>
<feature policy='require' name='pdpe1gb'/>
<feature policy='require' name='invtsc'/>
<feature policy='disable' name='pclmuldq'/>
<feature policy='disable' name='lahf_lm'/>
</cpu>
The 'pclmuldq' and 'lahf_lm' should not be disabled in the baseline CPU
as they are supported by QEMU on this host.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since swtpm does not support getting started without password
once it was created with encryption enabled, we don't allow
encryption to be removed. Similarly, we do not allow encryption
to be added once swtpm has run. We also prevent chaning the type
of the TPM backend since the encrypted state is still around and
the next time one was to switch back to the emulator backend
and forgot the encryption the TPM would not work.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This patch now passes the passphrase as a migration key to swtpm.
This now encrypts the state of the TPM while a VM is migrated between
hosts or when suspended into a file. Since the migration key secret
is the same as the state encryption secret, this now requires that
the migration destination host has the same secret value.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Allow vTPM state encryption when swtpm_setup and swtpm support
passing a passphrase using a file descriptor.
This patch enables the encryption of the vTPM state only. It does
not encrypt the state during migration, so the destination secret
does not need to have the same password at this point.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Extend virCommandProcessIO to include the send buffers in the poll
loop.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Mark a virCommand's inpipe (write-end of pipe) as non-blocking so that it
will never block when we were to try to write too many bytes to it while
it doesn't have the capacity to hold them.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the struct pollfd *fds to be allocated rather than residing
on the stack. This prepares it for the next patch where the size of
the array of fds becomes dynamic.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Implement virCommandSetSendBuffer() that allows the caller to pass a
file descriptor and buffer to virCommand. virCommand will write the
buffer into the file descriptor. That file descriptor could be the
write end of a pipe or one of the file descriptors of a socketpair.
The other file descriptor should be passed to the launched process to
read the data from.
Only implement the function to allocate memory for send buffers
and to free them later on.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Run 'swtpm socket --print-capabilities' and
'swtpm_setup --print-capabilities' to get the JSON object of the
features the programs are supporting and parse them into a bitmap.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Check whether previously found executables were updated and if
so look for them again. This helps to use updated features of
swtpm and its tools upon updating them.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Refactor virTPMEmulatorInit to use a loop with parameters. This allows
for easier extension later on.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Move qemuTPMEmulatorInit to virTPMEmulatorInit in virtpm.c and introduce
a few functions to query the executables needed for virCommands.
Add locking to protect the tool paths and return a copy of the tool paths
to callers wanting to access them so that we can run the initialization
function multiples time later on and detect when the executable gets updated.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Extend the TPM device XML parser and XML generator with emulator
state encryption support.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add support for usage type vTPM to secret.
Extend the schema for the Secret to support the vTPM usage type
and add a test case for parsing the Secret with usage type vTPM.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When using the ENUM macros, the compiler guards that the declaration
and implementation are in sync.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
qemuBlockJobRewriteConfigDiskSource rewrites the disk source only
according to the 'target'. This means that if someone would change the
inactive config of the VM to refer to a different disk a block job would
rewrite it when finishing a job which modifies the disk source.
Make sure that this does not happen by verifying that the source of the
config disk is the same.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
Since we copy everything from the original storage source including some
runtime data which are not relevant for the config we should clear them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
Both active block commit and block copy modify the disk source of the
active definition and thus also must modify the corresponding inactive
definition source so that the VM starts up later. This is currently
implemented in the legacy block job handler but the logic will be useful
also for the new handlers. Split it out which also simplifies it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
The <mirror> subelement is used in two ways: in a commit job to point to
existing storage, and in a block-copy job to point to additional
storage. We need a way to track only the distinct storage.
This patch introduces qemuBlockJobDiskRegisterMirror which registers the
mirror chain separately only for jobs which require it. This also comes
with remembering that in the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
Commit c412383796 used a value from wrong enum when setting the disk's
mirrorState variable. This meant that a 'READY' job would show up as
'PIVOTING'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Eric Blake <eblake@redhat.com>
When returning to asynchronous block job handling the flag which
determines the handling method should be reset prior to flushing
outstanding events. If there's an event to process the handler may
invoke the monitor and another event may be received. We'd not process
that one. Reset the flag earlier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainSnapshotDiskDataCollect copies the source of the disk from the
live config into the inactive config. Move this operation earlier so
that if we initialize it for use for the particular instance the
run-time-only data is not copied.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In case when the backing store can be represented with something
simpler such as a URI we can use it rather than falling back to the
json: pseudo-protocol.
In cases when it's not worth it (e.g. with the old ugly NBD or RBD
strings) let's switch to json.
The function is exported as we'll need it when overwriting the ugly
strings qemu would come up with during blockjobs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The block commit API checked 'disk->src->path' to see whether there
is a reasonable disk source to be committed. As the top image can be
e.g. backed by NBD the check is not good enough. Replace it by
virStorageSourceIsEmpty.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For the modern use cases we are going to use 'blockdev-snapshot' instead
of 'blockdev-snapshot-sync'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuBuildStorageSourceChainAttachPrepareBlockdev prepares the full
backing chain for attachment via blockdev. For snapshots we'll need to
prepare one image only as it needs to be plugged on top of the existing
chain.
This patch introduces qemuBuildStorageSourceChainAttachPrepareBlockdevTop
which prepares only @top similarly to the original function by splitting
out the functionality into an internal function so that the API does not
change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In commit 042c95bd19 qemuBuildStorageSourceChainAttachPrepareBlockdev
was added but the comment for the function mentions
qemuBuildStorageSourceChainAttachPrepareDrive. Fix the mistake.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we track the job separately we watch only for the abort of the
one single block job so the comment is no longer accurate. Also
describing asynchronous operation is not really necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With -blockdev:
- we track the job and check it after restart
- have the ability to ask qemu to persist it to collect result
- have the ability to report errors.
This solves all points the comment outlined so remove it. Also all jobs
handle the disk state modification along with the event so there's
nothing special the comment says.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use job-complete/job-abort instead of the blockjob-* variants for
blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the error message is now available and we know whether the job failed
we can report an error straight away rather than having the user check
the event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Set the correct job states after the operation is requested in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When initiating a pivot or abort of a block job we need to track which
one was initiated. Currently it was done via data stashed in
virDomainDiskDef. Add possibility to track this also together with the
job itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Do decisions based on the configuration of the job rather than the data
stored with the disk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the stored job name rather than passing in the disk alias when
referring to the job which allows the same code to work also when
-blockdev will be used.
Note that this API does not require the change to use 'query-job' as it
will ever only work with blockjobs bound to disks due to the arguments
which allow only referring to a disk. For the disk-less jobs we'll need
to add a separate API later.
The change to qemuMonitorGetBlockJobInfo is required as the API was
stripping the 'drive-' prefix when returning the data which is not
desired any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cgroups v2 when a new group is created by default no controller is
enabled so the detection code will not detect any controllers.
When enabling the controllers we should also store them for the group.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
When creating new group for cgroups v2 the we cannot check
cgroups.controllers for that cgroup because the directory is created
later. In that case we should check cgroups.subtree_control of parent
group to get list of controllers enabled for child cgroups.
In order to achieve that we will prefer the parent group if it exists,
the current group will be used only for root group.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
When commit 6ac402c456 added the API whenever VIR_DOMAIN_MEM_MAXIMUM
was passed the code always checked whether the domain was active and
therefore failed with an error even though only a config change was
requested. Fix the issue by replacing virDomainObjGetOneDef with
virDomainObjGetOneDefState which tells us what definition we're
performing the change on.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Commit d5572f62e3 forgot to add maxthreads to the non-Linux definition
of the function, thus breaking the MinGW build.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Any message that is easy to trigger (as evidenced by the testsuite
update) should not use 'internal error' as its category.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
virDomainSnapshotFindByName(list, NULL) should return NULL, rather
than the internal-use-only metaroot. Most existing callers pass in a
non-NULL name; the few external callers that don't are immediately
calling virDomainMomentSetParent (which indeed needs the metaroot
rather than NULL if the parent name is NULL); but as the leaky
abstraction is ugly, it is worth instead making
virDomainMomentSetParent static and adding a new function for
resolving the parent link of a brand new moment within its list. The
existing external uses of virDomainMomentSetParent always succeed
(either the new moment has parent_name of NULL to become a new root,
or has parent_name set to a strdup of the previous current moment);
hence, our new function does not need a return value (but it still has
a VIR_WARN in case future uses break our assumptions about failure
being impossible).
Missed when commit 02c4e24d refactored things to attempt to remove
direct metaroot manipulations out of the qemu and test drivers into
internal-only details, and made more obvious when commit dc8d3dc6
factored it out into a separate file.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Some VM configurations may result in a large number of threads created by
the associated qemu process which can exceed the system default limit. The
maximum number of threads allowed per process is controlled by the pids
cgroup controller and is set to 16k when creating VMs with systemd's
machined service. The maximum number of threads per process is recorded
in the pids.max file under the machine's pids controller cgroup hierarchy,
e.g.
$cgrp-mnt/pids/machine.slice/machine-qemu\\x2d1\\x2dtest.scope/pids.max
Maximum threads per process is controlled with the TasksMax property of
the systemd scope for the machine. This patch adds an option to qemu.conf
which can be used to override the maximum number of threads allowed per
qemu process. If the value of option is greater than zero, it will be set
in the TasksMax property of the machine's scope after creating the machine.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Update the current or max memory, on the persistent or live definition
depending on the flags which are currently ignored.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Make the test driver only support the VIR_TYPED_PARAM_STRING flag for
now.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Avoid the chance that sysconf(_SC_OPEN_MAX) returns -1 and thus
would cause virBitmapNew would attempt to allocate a very large
bitmap.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
It's already dereffed in the initialization and shouldn't be NULL
unless virJSONValueArraySize after a virJSONValueObjectGetArray
could return a NULL data entry.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
Report in logs when we don't find existing block job data and create it
just to handle the job.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While this function does start a block job in case when we'd not be able
to get our internal data for it, the handler sets the job state to
QEMU_BLOCKJOB_STATE_RUNNING anyways, thus qemuBlockJobStartupFinalize
would just unref the job.
Since the other usage of qemuBlockJobStartupFinalize in the other part
of the event handler was a bug replace this one anyways even if it would
not cause problems.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The block job event handler qemuProcessHandleBlockJob looks at the block
job data to see whether the job requires synchronous handling. Since the
block job event may arrive before we continue the job handling (if the
job has no data to copy) we could hit the state when the job is still
set as QEMU_BLOCKJOB_STATE_NEW (as we move it to the
QEMU_BLOCKJOB_STATE_RUNNING state only after returning from monitor).
If the event handler uses qemuBlockJobStartupFinalize it would
unregister and free the job. Thankfully this is not a big problem for
legacy blockjobs as we don't need much data for them but since we'd
re-instantiate the job data structure we'd report wrong job type for
active commit as qemu reports it as a regular commit job.
Fix it by not using qemuBlockJobStartupFinalize function in
qemuProcessHandleBlockJob as it is not starting the job anyways.
https://bugzilla.redhat.com/show_bug.cgi?id=1721375
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virCgroupRemove return -1 when removing cgroup failed.
But there are retry code to remove cgroup in QemuProcessStop:
retry:
if ((ret = qemuRemoveCgroup(vm)) < 0) {
if (ret == -EBUSY && (retries++ < 5)) {
usleep(200*1000);
goto retry;
}
VIR_WARN("Failed to remove cgroup for %s",
vm->def->name);
}
The return value of qemuRemoveCgroup will never be equal to "-EBUSY",
so change the return value of virCgroupRemove if failed.
Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Shutting down the daemon after 30 seconds of being idle is a little bit
too aggressive. Especially when using 'virsh' in single-shot mode, as
opposed to interactive shell mode, it would not be unusual to have
more than 30 seconds between commands. This will lead to the daemon
shutting down and starting up between a series of commands.
Increasing the shutdown timer to 2 minutes will make it less likely that
the daemon will shutdown while the user is in the middle of a series of
commands.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of having each caller pass in the desired logfile name, pass in
the binary name instead. The logging code can then just derive a logfile
name by appending ".log".
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This adds detection of a Quobyte as a shared file system for live
migration.
Signed-off-by: Silvan Kaiser <silvan@quobyte.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have two functions: virPCIDeviceAddressIsEqual() defined only
on Linux and virPCIDeviceAddressEqual() defined everywhere. And
both of them do the same. Drop the former in favour of the
latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Commit 5ff46aaa7f added a new parameter but neglected to fix the NONNULL
declarations.
Reported-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When removing the disk fronted while any block job is still active we
need to transfer the ownership of the backing chain to the job itself as
the job still holds the reference to the chain members and thus attempts
to remove them would fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when the disk frontend was unplugged while a blockjob was
running the blockjob inherits the backing chain. When the blockjob is
then terminated we need to unplug the chain as it will not be used any
more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The PR manager is a property of the format layer in qemu so we need to
be able to track it also in the chains of orphaned block jobs.
Add a helper for qemu to look also into the blockjob state.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the guest unplugs the disk frontend libvirt is responsible for
deleting the backend. Since a blockjob may still have a reference to the
backing chain when it is running we'll have to store the metadata for
the unplugged disk for future reference.
This patch adds 'chain' and 'mirrorChain' fields to 'qemuBlockJobData'
to keep them around with the job along with status XML machinery and
tests. Later patches will then add code to change the ownership of the
chain when unplugging the disk backend.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Refresh the state of the jobs and process any events that might have
happened while libvirt was not running.
The job state processing requires some care to figure out if a job
needs to be bumped.
For any invalid job try doing our best to cancel it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the infrastructure to handle block job events in the -blockdev era.
Some complexity is required as qemu does not bother to notify whether
the job was concluded successfully or failed. Thus it's necessary to
re-query the monitor.
To minimize the possibility of stuck jobs save the state into the XML
prior to handling everything so that the reconnect code can potentially
continue with the cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for handling the event either synchronously or
asynchronously using the event thread.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With blockdev we'll need to use the JOB_STATUS_CHANGE so gate the old
events by the blockdev capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This new state is entered when qemu finished the job but libvirt does
not know whether it was successful or not.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the blockjob handling code deals with the status XML we don't
need to save it explicitly when starting blockjobs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that block job data is stored in the status XML portion we need to
make sure that everything which changes the state also saves the status
XML. The job registering function is used while parsing the status XML
so in that case we need to skip the XML saving.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to store the block job state in the status XML so that we can
properly recover any data when reconnecting after startup and also in
the end to be able to do any transition of the backing chain that
happened while libvirt was not connected to the monitor.
First step is to note the name, type, state and corresponding disk into
the status XML.
We also need to make sure that a broken blockjob does not make libvirt
lose the VM, thus many of the errors just mark the job as invalid.
Later on we'll cancel all invalid jobs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The job data saved in the XML may be partially invalid e.g. if something
is missing. To prevent losing a domain with such a job add a flag to the
job data so that job APIs can ignore such a job and we can just cancel
it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When parsing the status XML we need to register all existing jobs.
Export the functions so that they are usable in other modules.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Later on we'll format these values into the status XML so the from/to
string functions will come handy. The implementation also notes that
these will be used in the status XML to avoid somebody changing the
values.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the job structure to the table when instantiating a new job and
remove it when it terminates/fails.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Block jobs currently belong to disks only so we can look up the block
job data for them in the corresponding disks. This won't be the case
when using blockdev as certain jobs don't even correspond to a disk and
most of them can run on a part of the backing chain.
Add a global table of blockjobs which can be used to look up the data
for the blockjobs when the job events need to be processed.
The table is a hash table organized by job name and has a reference to
the job. New and running jobs will later be added to this table.
Reference counting will allow to reap job state for synchronous callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The legacy job handler does not look at the old job state so we can
update it earlier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's no need to do it if the job is not completed. The new helper
allows to do this with much less hassle in the correct place.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename and move qemuBlockJobTerminate to qemuBlockJobUnregister and
separate bits from qemuBlockJobDiskNew which register the job with the
disk. This creates an unified interface for other APIs to use.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to qemuDomainSaveStatus add a helper to save the config XML
named qemuDomainSaveConfig.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename qemuDomainObjSaveJob and create a wrapper for it which does not
require 'driver' to be passed and export it so that other palces can
easily save the status XML without having to invoke virDomainSaveStatus
which has unpleasing parameters.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Tests will need to parse such a definition so it also needs to be freed.
Provide a function for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU allows us to create storage on certain network protocols which
allow image creation through their API. Wire up the generator for using
it with libvirt as well as for local files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'blockdev-add' allows us to use qemu to format images to our desired
format. This patch implements helpers which convert a
virStorageSourcePtr into JSON objects describing the required
configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow using -blockdev with blockjobs QEMU needs to reopen files in
read-write mode when modifying the backing chain. To achieve this we
need to use 'auto-read-only' for the backing files rather than the
normal 'read-only' property. That way qemu knows that the files need to
be reopened.
Note that the format drivers (e.g. qcow2) are still opened with the
read-only property enabled when being a member of the backing chain
since they are supposed to be immutable unless a block job is started.
QEMU v4.0 (since commit 23dece19da4) allows also dynamic behaviour for
auto-read-only which allows us to use sVirt as we only grant write
permissions to files when doing a blockjob.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow reusing the formatters in the code for creating JSON properties
for 'blockdev-create' we need to create everything except the 'driver'
attribute.
Use the new helper virJSONValueObjectPrependString to put the driver at
the same place so that we don't change any output.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt treats the JSON objects as lists thus the values appear in the
order they were added. To avoid too much changes introduce a helper
which allows to prepend a string which will allow to keep certain
outputs in order.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When formatting new qcow2 images we need to provide the backing store
string which should not contain any authentication or irrelevant data.
Add a flag for qemuBlockStorageSourceGetBackendProps which allows to
skip the irrelevant data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'blockdev-create' starts a job which creates a storage volume using
the given protocol or formats an existing (added) volume with one of the
supported storage formats.
This patch adds the monitor interaction bits.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This new event is a superset of the BLOCK_JOB* events and also covers
jobs which don't bind to a VM disk.
In this patch the monitor part is implemented.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This belongs to the new job management API which can manage also
non-block based jobs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This belongs to the new job management API which can manage also
non-block based jobs. Since we'll need to be able to attempt to cancel
jobs which potentially were not started (during reconnect) the 'quiet'
flag allows to suppress errors reported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This belongs to the new job management API for generic jobs.
The dismiss command is meant to remove a concluded job after we were
able to get the final status.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow using the delayed dismiss of the job so that we can reap the state
even if libvirtd was not running when qemu emitted the job completion
event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow using the node name to specify the base and top of the 'commit'
operation, allow specifying explicit job name and add support for
delayed dismiss of the job so that we can reap the state even if
libvirtd was not running when qemu emitted the job completion event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow using the node name to specify the base of the 'stream' operation,
allow specifying explicit job name and add support for delayed dismiss
of the job so that we can reap the state even if libvirtd was not
running when qemu emitted the job completion event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When querying storage metadata after a block job we re-run
virStorageFileGetMetadata on the top level storage file. This means that
the workers (virStorageFileGetMetadataInternal) must not overwrite any
pointers without freeing them.
This was not considered for src->compat and src->features. Fix it and
add a comment mentioning that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function does not do any cleanup, so replace the 'cleanup' label
with return of -1 and the 'done' label with return of 0.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since fb9f6ce625 we are including a libxml header file in the
network driver but never link with it. This hasn't caused an
immediate problem because in the end the network driver links
with libvirt.la. But apparently, it's causing a build issue on
old Ubuntu.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If there are two paths on the list that are the same we need to
lock it only once. Because when we try to lock it the second time
then open() fails. And if it didn't, locking it the second time
would fail for sure. After all, it is sufficient to lock all
paths just once satisfy the caller.
Reported-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Document why we need to sort paths while it's still fresh in my
memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This commit is similar with 596aa144. It fixes an uninitialized
variable to avoid garbage value. This case, it uses time 't' 0 if
an error occurs with virTimeMillisNowRaw.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pass an xmlopt argument through all the needed network conf
functions, like is done for domain XML handling. No functional
change for now
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Just a stub for now that is unused. Add init+cleanup plumbing and
demostrate it in bridge_driver.c
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Having a translation enum full of empty strings seems excessive.
Now that the validiation is performed in qemuDomainDeviceDefValidateFS,
remove it completely and open-code the two allowed cases.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Introduce two separate variables instead of reusing the same one
for clarity.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
This function iterates over all filesystems, not just -fsdevs.
Rename it to free the name for a function that actually builds fsdevs.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
When spawning a child process, between fork() and exec() we close
all file descriptors and keep only those the caller wants us to
pass onto the child. The problem is how we do that. Currently, we
get the limit of opened files and then iterate through each one
of them and either close() it or make it survive exec(). This
approach is suboptimal (although, not that much in default
configurations where the limit is pretty low - 1024). We have
/proc where we can learn what FDs we hold open and thus we can
selectively close only those.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
I will optimize this code a bit in the next commit. But for that
it is better if the code lives in a separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Test if our parsing of interface stats as returned by ovs-vsctl
works as expected. To achieve this without having to mock
virCommand* I'm separating parsing of stats into a separate
function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We run 'ovs-vsctl' nine times (first to find if interface is
there and then eight times = for each stats member separately).
This is very inefficient. I've found a way to run it once and
with a bit of help from virJSON module we can parse out stats
we need.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Typo meant we use 'nodedev' instead of 'interface'. This doesn't hurt
libvirtd because if a process tries to acquire a lock it already holds
it will succeed. It fails when nodedev & interface drivers are in
separate daemons though.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the drivers acquire their pidfile lock we don't want to wait if the
lock is already held. We need the driver to immediately report error,
causing the daemon to exit.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
VHD images can be used as any other, so we should add them to the list
of types that virt-aa-helper can read when creating the per-guest rules
for backing files.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
When validating a domain among all the checks there are two that
concern VIR_DOMAIN_LOADER_TYPE_PFLASH specifically. The first
check ensures that on x86 ACPI is enabled when UEFI is requested,
the second ensures that UEFI is used when ACPI is requested on
aarch64. However, check for UEFI is done by plain comparison of
def->os.loader->type which is insufficient because we have
def->os.firmware too.
NB, this wouldn't be a problem for active domain, because on
startup process def->os.loader->type gets filled by
qemuFirmwareEnableFeatures(), but that's not the case for
inactive domains.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1729604
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Split up the addition of a storage source into the following sub-steps:
1) storage access dependencies (TLS transport, persistent reservation)
2) storage acccess node (file/gluster/nbd...)
3) format driver dependencies (encryption secret)
4) format driver node (qcow2, raw, ...)
The functions split out will be later reused when implementing support
for 'blockdev-create' as we'll need the dependencies plugged in first,
then blockdev-create will be called and after that successfully finishes
blockdev-add will be added.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add separate booleans for extracting VIR_DOMAIN_BLOCK_COPY_REUSE_EXT and
VIR_DOMAIN_BLOCK_COPY_SHALLOW from '@flags' and also change 'reuse' into
'existing'.
qemuMonitorDriveMirror requires the unmodified state of the flags to
pass to qemu and also we use the value a few times internally. Extract
it separately now.
The 'reuse' flag did not indicate reusing of the file as much as the
fact that the storage is existing and thus should not be created, so
modify the name to reflect this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With -blockdev it will be possible that a block job loses the disk that
was used to start it to a guest-initiated hot-unplug. Don't emit the
block job events in that case as we can't report the top level source or
disk target for an unplugged (and potentially replugged with different
source) disk.
Eventually when we add machinery for tracking jobs globally for a VM the
event will be reinstated via the domain job event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
job->newstate is now used internally all the time so there's no need to
clear it as it already has correct value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update schema and configuration to allow specifying new video type of
'bochs'. Add implementation and tests for qemu.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Check whether qemu supports the bochs-display device and set a
capability. Update tests.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Add pool list type flag VIR_CONNECT_LIST_STORAGE_POOLS_ISCSI_DIRECT,
which was forgotten when introducing iscsi-direct pool at f0bf1be3.
https://bugzilla.redhat.com/show_bug.cgi?id=1726609
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The code to check whether a redefined snapshot/checkpoint XML is
attempting to create a cycle in the list of moments is lengthy, and
common between the two types of list. Therefore, it belongs in the
shared base file.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The use of the virNetServerAutoShutdownFunc typedef was removed in
commit 79b8a56995
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Oct 31 19:03:55 2012 +0000
Replace polling for active VMs with signalling by drivers
This unused typedef was then copied into the virNetDaemon object
when that was split off from virNetServer, resulting in a typedef
virNetDaemonAutoShutdownFunc that has never been needed.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The new systemd activation APIs mean there is no longer a need to get
the UNIX socket path associated with a plain FD.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virGetListenFDs method no longer needs to be called directly, so it
can be a static function internal to the systemd code.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using the new system activation APIs allows for simpler code setting up
the network services.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using the new system activation APIs allows for simpler code setting up
the network services.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The only use of this code was removed by:
commit be78814ae0
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Apr 2 14:41:17 2015 +0200
virNetSocketNewConnectUNIX: Use flocks when spawning a daemon
less than a year after it was first introduced in
commit 1b807f92db
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Wed Jul 16 08:00:19 2014 +0200
rpc: pass listen FD to the daemon being started
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Certain libvirtd.conf settings are not honoured when using systemd
socket activation.
Certain systemd unit file settings must match those defined in
libvirtd.conf for systemd socket activation to work with systemd
version < 227, otherwise libvirtd cannot determine which inherited
FD to use for which service.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since we have socket activation available now, we can let the system
libvirtd exit when it is idle. This allows it to still do autostart
when the host boots up, but when nothing was started it will quickly
exit again until some mgmt app connects to the socket.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We don't do socket activation of libvirtd, since we need to
unconditionally start libvirtd in order to perform autostart. This
doesn't mean we can't have systemd socket units. Some use cases will
not need libvirt's autostart & are thus free to use activation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetServerServiceNewFDOrUNIX method cannot be correctly used when
dealing with systemd activation of a service which can receive more than
one socket FD as there is not guaranteed ordering of FDs.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current libvirtd code for systemd socket activation assumes socket
FDs are passed in the order unix-rw, unix-ro, unix-admin. There is in
fact no ordering guarantee made by systemd. Applications are expected
to check the address or name associated with each FD to figure out its
identity.
This rewrites libvirtd to make use of the new systemd activation APIs
to make it robust wrt socket ordering changes.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently code has to first create the service and then separately
register it with the server. If the socket associated with a particular
service is not passed from systemd we want to skip creating the service
altogether. This means we can't put the systemd activation logic into
the constructors for virNetServerService.
This patch thus creates some helper methods against virNetServer which
combine systemd activation, service creation and service registration
into one single operation. This operation is automatically a no-op if
systemd activation is present and no sockets were passed in.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the socket code will unlink any UNIX socket path which is
associated with a server socket. This is not fine grained enough, as we
need to avoid unlinking server sockets we were passed by systemd.
To deal with this we must explicitly track whether each socket needs to
be unlinked when closed, separately of the client vs server state.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetServerServiceNewFD API only accepts a single FD, but it is
easily changed to allow for an array of FDs to be passed in.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a virNetServerServiceNewSocket API that allows the various
constructors to share more code.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When receiving multiple FDs from systemd during service activation it is
neccessary to identify which purpose each FD is used for. While this
could be inferred by looking for the specific IP ports or UNIX socket
paths, this requires the systemd config to always match what is expected
by the code. Using systemd FD names we can remove this restriction and
simply identify FDs based on an arbitrary name.
The FD names are passed by systemd in the LISTEN_FDNAMES env variable
which is populated with the socket unit file names, unless overriden
by using the FileDescriptorName setting.
This is supported since the system 227 release and unfortunately RHEL7
lacks this version. Thus the code has some back compat support whereby
we look at the TCP ports or the UNIX socket paths to identify what
socket maps to which name. This back compat code is written such that
is it easly deleted when we are able to mandate newer systemd.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the service passed to getaddrinfo is NULL the kernel will choose a
free port to bind to. In a dual stack though we will get separate
sockets for IPv4 and IPv6 and we need them to bind to the same port
number. Thus once the kerel has auto-selected a port for the first
socket, we must disable auto-select for subsequent IP sockets and force
reuse of the first port.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 035db37394
Even though we only allow using RBD with raw volumes,
removing the options and the default format causes our
parser not to fill out the volume format and the backend code
rejects creating a non-raw volume.
Re-introduce the volume options to fix volume creation while
erroring out on requests to use non-raw formats.
https://bugzilla.redhat.com/show_bug.cgi?id=1724065
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If there are more than 16 images, the memory allocated in images
might be leaked on subsequent execution(s).
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In preparation for adding the bochs display device, refactor the logic
so that each branch handles a single device type and checks its
parameters within that branch. In this case VGA and VMVGA are still
grouped into the same branch since they share device-specific parameter
names.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The cleanup label in virNetworkObjDeletePort() function serves no
purpose. Drop it and thus simplify the function a bit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The cleanup label in virNetworkObjAddPort() function serves no
purpose. Drop it and thus simplify the function a bit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The virNetworkObjGetPortStatusDir() function allocates a memory
to construct a path. None of the callers free it leading to a
memleak.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The virtlogd config is set to rollover logs every 2 MB.
Normally a logrotate config file is also installed to handle cases where
virtlogd is disabled. This is set to rollover weekly with no size
constraint.
As a result logrotate can interfere with virtlogd's, rolling over files
that virtlogd has already taken care of.
This changes logrotate configs to rollover based on a max size
constraint of 2 MB + 1 byte. When virtlogd is running the log files will
never get this large, making logrotate a no-op.
If the user changes the size in virtlogd's config to something larger,
they are responsible for also changing the logrotate config suitably.
The LXC/libxl drivers don't use virtlogd, but there logrotate config is
altered to match the QEMU driver config, for the sake of consistency.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Way back in the past, the "no_tty=1" option was added for the remote
driver to disable local password prompting by disabling use of the local
tty:
commit b32f429849
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Sep 21 20:17:09 2007 +0000
Added a no_tty param to remote URIs to stop SSH prompting for password
This was done by adding "-T -o BatchMode=yes -e none" args to ssh. This
achieved the desired results but is none the less semantically flawed
because it is mixing up config parameters for the local tty vs the
remote tty.
The "-T" arg stops allocation of a TTY on the remote host. This is good
for all libvirt SSH tunnels as we never require a TTY for our usage
model, so we should have just passed this unconditionally.
The "-e none" option disables the escape character for sessions with a
TTY. If we pass "-T" this is not required, but it also not harmful to
add it, so we should just pass it unconditionally too.
Only the "-o BatchMode=yes" option is related to disabling local
password prompts and thus needs control via the no_tty URI param.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
For quite some time now it is impossible to connect to a domain
using a HMP monitor, so there is no point in formatting it in the status
XML.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The getservent() APIs are not re-entrant safe so cannot be used in any
threaded program. Add a wrapper around getaddrinfo() for resolving the
service names to a port number.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It doesn't make sense to have the admin socket active if the main
socket is not running, so bind their lifecycle together.
This ensures that if primary socket is stopped, the corresponding
admin socket is also stopped.
In the reverse, starting the admin socket will also automatically
start the primary socket.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/bhyve/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/bhyve/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/vz/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/vz/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/lxc/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/lxc/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/libxl/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/libxl/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
No supported build targets for libvirt still ship xend, so there is no
need for the libxl driver to check for it anymore.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/nwfilter/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/nwfilter/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/interface/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/interface/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/nodedev/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/nodedev/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/storage/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/storage/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/network/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/network/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/secrets/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/secrets/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.
In privileged libvirtd this ends up locking
/var/run/libvirt/qemu/driver.pid
In unprivileged libvirtd this ends up locking
/run/user/$UID/libvirt/qemu/run/driver.pid
NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We've been doing a terrible job of performing XML validation in our
various API that parse XML with a corresponding schema (we started
with domains back in commit dd69a14f, v1.2.12, but didn't catch all
domain-related APIs, didn't document the use of the flag, and didn't
cover other XML). New APIs (like checkpoints) should do the validation
unconditionally, but it doesn't hurt to continue retrofitting existing
APIs to at least allow the option.
While there are many APIs that could be improved, this patch focuses
on wiring up a new snapshot XML creation flag through all the
hypervisors that support snapshots, as well as exposing it in 'virsh
snapshot-create'. For 'virsh snapshot-create-as', we blindly set the
flag without a command-line option, since the XML we create from the
command line should generally always comply (note that validation
might cause failures where it used to succeed, such as if we tighten
the RNG to reject a name of '../\n'); but blindly passing the flag
means we also have to add in fallback code to disable validation if
the server is too old to understand the flag.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Similar to VIR_DOMAIN_DEF_PARSE_VALIDATE_SCHEMA; the next patch will
put it to use with a counterpart public API flag.
No need to change qemudomainsnapshotxml2xmltest to use the flag, since
the testsuite already has a separate virschematest that does the same.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
We no longer need to special-case xenUnified, since 1dac5fbbbb
dropped support for that naming scheme.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Previous commit:
commit faceedaf71
Author: Jonathon Jongsma <jjongsma@redhat.com>
Date: Tue Jun 18 11:13:12 2019 -0500
src/vz: use #pragma once in headers
accidentally chomped the "#" in a "#define" when re-indenting
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Support for the modern CPU_ALLOC macros was added 10 years ago in
commit a73cd93b24
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Nov 16 16:08:29 2009 +0000
Alternate CPU affinity impl to cope with NR_CPUS > 1024
This is long enough that we can assume it always exists and drop the
back compat code.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Continuous integration caught that although 'make syntax-check' was
sufficient to let me be aware that I had to change bhyve to use
s/virDomainShutdownEnsureACL/virDomainShutdownFlagsEnsureACL/, it was
not sufficient to note which ACL functions require 2 vs. 3 arguments
for flag validation.
Fixes: eded8aad
Signed-off-by: Eric Blake <eblake@redhat.com>
The @oldDef variable in libxlAddDom0() is not used really. Drop
it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Note that virDomainBlockStats does not trivially forward to
virDomainBlockStatsFlags, so that one is omitted for now.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
We've dropped old xend support over a year ago. At this point we can
also drop support for parsing very old configs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use new coding style to merge the only use of xenFormatSxprSound into
the caller.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The docs talked about an active snapshot when they meant an active
domain; they also claimed the flag was a no-op for hypervisors with no
snapshot metadata even though the flag is currently rejected as
unrecognized for hypervisors with no snapshot support at all. A later
patch may teach more drivers to ignore the flag as a no-op, but that
shouldn't conflict with the wording chosen here (since a new client
talking to an old server still runs into the same issue, even if a
newer server becomes more tolerant).
Reported-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The virConnectGetType() method has an unfortunate signature, returning a
static string that must not be freed by the caller. The remote driver,
however, gets this string dynamically over an RPC call, which raised a
design discussion on the mailing list. Eventually the problem was
resolved by having the remote driver cache the returned string
internally and free it when the connection was closed.
The link to the mailing list is thus talking about a problem that does
not actually exist in the final implementation, and at best serves to
confuse the reader into thinking there might be a memory leak.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Neither the sasl_client_init or sasl_server_init methods are even
remotely threadsafe. They do a bunch of one-time initialization and
merely use a simple integer counter to avoid repeated work, not even
using atomic increment/reads on the counter. This can easily race in a
threaded program. Protect the calls using a virOnce initializer function
which is guaranteed threadsafe at least from libvirt's POV.
If the application using libvirt also uses another library that makes
use of SASL then the race still exists. It is impossible to fix that
fully except in SASL code itself.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Similar to commit a487890d for qemu, a little bit of refactoring in
the snapshot delete code will make it easier to reuse functionality
for checkpoints.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The 'tty' variable is only used on Win32. Instead of just annotating it
with ATTRIBUTE_UNUSED, make its declaration conditional on WIN32 so that
it is clear why it is not used.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Simplify the clean code paths for doRemoteOpen by using VIR_AUTOFREE
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The doRemoteOpen method was a little unusual in declaring a bunch of
local variables in the middle of the function. Move them to the top as
it is normal libvirt style.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is an error path that jumps over the initialization of
nerrors, and the jump target reads the variable contents.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Zero out the user provided memory in order to avoid potentially freeing
uninitialized memory.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Mention libssh as possible transport in the error message of an
unrecognized transport.
https://bugzilla.redhat.com/show_bug.cgi?id=1727013
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The LIBVIRTD_CONFIGURATION_FILE constant was introduced in
commit b7c42619e6
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Mon Jun 11 11:43:41 2007 +0000
Mon Jun 11 12:41:00 BST 2007 Richard W.M. Jones <rjones@redhat.com>
and then never used !
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The LIBVIRTD_CONFIG and LIBVIRTD_NOFILES_LIMIT parameters were only
honoured when using the sysvinit scripts. This was removed already in
commit 912fe2df9d
Author: Andrea Bolognani <abologna@redhat.com>
Date: Fri Mar 15 16:47:27 2019 +0100
Drop support for "Red Hat" init scripts
so the parameters can safely be dropped.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sysvinit script was previously removed in
commit 912fe2df9d
Author: Andrea Bolognani <abologna@redhat.com>
Date: Fri Mar 15 16:47:27 2019 +0100
Drop support for "Red Hat" init scripts
A make rule was accidentally left behind.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the flags argument is completely ignored, but it should be
checked for any unsupported flags that might have been passed.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Always return / and /boot as the mount points imitating the default
Fedora installation. Use the first disk found, otherwise if no disk
device of type VIR_DOMAIN_DISK_DEVICE_DISK is present, return 0 mount
points.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Calling virDomainObjUpdateModificationImpact directly inside the
function body is redundant, since the same function call is embedded
into virDomainObjGetOneDef.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
There are some paths (e.g. /dev/vfio/vfio or /dev/mapper/control)
which are defined in qemu_domain.c and then in qemu_cgroup.c
again. This is suboptimal. Let's move paths into qemu_domain.h and
drop duplicate definitions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In my review of 89320788ac I've simplified assigning disk errors
too much as the code I've changed it to will set
VIR_DOMAIN_DISK_ERROR_NONE. This is in contradiction with our
documentation which specifies that disks with no errors are not
reported.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If something goes wrong in testDomainGetDiskErrors() then we try
to free any strings that were previously allocated in return
array. Problem is, in my review of original patch (89320788ac)
I've mistakenly did some changes which result in possible NULL
dereference (@vm is set to NULL as the first thing under cleanup
label).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This reverts commit fc3990c7e6.
Now that all the reported bugs are fixed let's turn the feature
back on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A simple helper function that would be used from DAC and SELinux
drivers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The purpose of this API is to allow caller move XATTRs (or remove
them) from one file to another. This will be needed when moving
top level of disk chain (either by introducing new HEAD or
removing it).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This effectively reverts d7420430ce and adds new code.
Here is the problem: Imagine a file X that is to be shared
between two domains as a disk. Let the first domain (vm1) have
seclabel remembering turned on and the other (vm2) has it turned
off. Assume that both domains will run under the same user, but
the original owner of X is different (i.e. trying to access X
without relabelling leads to EPERM).
Let's start vm1 first. This will cause X to be relabelled and to
gain new attributes:
trusted.libvirt.security.ref_dac="1"
trusted.libvirt.security.dac="$originalOwner"
When vm2 is started, X will again be relabelled, but since the
new label is the same as X already has (because of vm1) nothing
changes and vm1 and vm2 can access X just fine. Note that no
XATTR is changed (especially the refcounter keeps its value of 1)
because the vm2 domain has the feature turned off.
Now, vm1 is shut off and vm2 continues running. In seclabel
restore process we would get to X and since its refcounter is 1
we would restore the $originalOwner on it. But this is unsafe to
do because vm2 is still using X (remember the assumption that
$originalOwner and vm2's seclabel are distinct?).
The problem is that refcounter stored in XATTRs doesn't reflect
the actual times a resource is in use. Since I don't see any easy
way around it let's just not store original owner on shared
resources. Shared resource in world of domain disks is:
- whole backing chain but the top layer,
- read only disk (we don't require CDROM to be explicitly
marked as shareable),
- disk marked as shareable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Just like previous commit allowed to enable or disable owner
remembering for each individual path, do the same for SELinux
driver. This is going to be needed in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
One caller in particular (virSecurityDACSetImageLabelInternal)
will want to have the feature turned on only in some cases.
Introduce @remember member to _virSecurityDACChownItem to track
whether caller wants to do owner remembering or not.
The actual remembering is then enabled if both caller wanted it
and the feature is turned on in the config file.
Technically, we could skip over paths that don't have remember
enabled when creating a list of paths to lock. We won't touch
their XATTRs after all. Well, I rather play it safe and keep them
on the locking list for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Both DAC and SELinux drivers support transactions. Each item on
the transaction list consists of various variables and @restore
is one of them. Document it so that as the list of variables grow
it's easier to spot which variable does what.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The way that virSecurityDACRecallLabel is currently written is
that if XATTRs are not supported for given path to the caller
this is not different than if the path is still in use. The value
of 1 is returned which makes secdrivers skip label restore.
This is clearly a bug as we are not restoring labels on say NFS
even though previously we were.
Strictly speaking, changes to virSecurityDACRememberLabel are not
needed, but they are done anyway so that getter and setter behave
in the same fashion.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It's better to have the function report errors, because none of
the callers does.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It's better to have the function report errors, because none of
the callers does.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The way that security drivers use XATTR is kind of verbose. If
error reporting was left for caller then the caller would end up
even more verbose.
There are two places where we do not want to report error if
virFileGetXAttr fails. Therefore virFileGetXAttrQuiet is
introduced as an alternative that doesn't report errors.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Just like it's DAC counterpart is doing,
virSecuritySELinuxRestoreAllLabel() could print @migrated in the
debug message.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test is beautiful. It checks if we haven't messed up
refcounting on security labels (well, XATTRs where the original
owner is stored). It does this by setting up tracking of XATTR
setting/removing into a hash table, then calling
qemuSecuritySetAllLabel() followed by immediate
qemuSecurityRestoreAllLabel() at which point, the hash table must
be empty. The test so beautifully written that no matter
what you do it won't fail. The reason is that all seclabel work
is done in a child process. Therefore, the hash table in the
parent is never changed and thus always empty.
There are two reasons for forking (only one of them makes sense
here though):
1) namespaces - when chown()-ing a file we have to fork() and
make the child enter desired namespace,
2) locking - because of exclusive access to XATTRs we lock the
files we chown() and this is done in a fork (see 207860927a for
more info).
While we want to fork in real world, we don't want that in a test
suite. Override virProcessRunInFork() then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 5a148ce84 altered the virNetServerNew to remove a parameter
but neglected to update the ATTRIBUTE_NONNULL's which causes a build
failure for when checking is enabled such as when lv_cv_static_analysis
is enabled.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Because of a systemd delegation policy [1] we should not write to any
cgroups files owned by systemd which in case of cgroups v2 includes
'cgroups.subtree_control'.
systemd will enable controllers automatically for us to have them
available for VM cgroups.
[1] <https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit 7bca1c9bdc.
As it turns out it's not a good idea on systemd hosts. The root
cgroup can have all controllers enabled but they don't have to be
enabled for sub-cgroups.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit 226094fbc4.
A deprecation is a warning to something that use of a feature is
being discouraged. By definition it is not an error condition to
continue to use a deprecated feature.
A VIR_ERR_DEPRECATED constant thus makes no conceptual sense. For
features which are entirely absent we already document that the
VIR_ERR_NO_SUPPORT code will be used. There is no need to distinguish
between a feature which never existed and a feature which previously
existed and was since removed.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The public API entry points will report VIR_ERR_NO_SUPPORT to the
caller when a driver does not provide an implementation of a particular
method.
When deleting methods, leaving the driver API entry point explicitly
set to NULL with an version range comment, allows the hvsupport.html
page to document when the AP was removed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since c257352797 a reference of 'cfg' would be leaked if the function
does not need to process anything. Fix it by using VIR_AUTOUNREF.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
when a disk without PR perform attach or detach operation,
need not call qemuHotplugRemoveManagedPR, otherwise, it will
print err log about PR, let us fix it.
Signed-off-by: Jie Wang <wangjie88@huawei.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The sys/sysctl.h header is only needed on BSD platforms to get
the sysctlbyname() function declaration. On Linux we talk to
procfs instead to change sysctls.
Unfortunately a legacy sys/sysctl.h header does exist on Linux
and including it has recently started triggering a deprecation
warning from glibc.
Protect its inclusion with a HAVE_SYSCTLBYNAME check instead
so that it only gets used on platforms where we need that
function declaration.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When detecting available controllers on host we can be limited by list
of controllers from qemu.conf file.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently CPU controller cannot be enabled if there is any real-time
task running and is assigned to non-root cgroup which is the case on
several distributions with graphical environment.
Instead of erroring out treat it as the controller is not available.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In order to skip controllers that we are not able to activate we need
to return different return value so the caller can decide what to do.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
It might happen that we are not able to enable CPU controller so we
can enable it for thread sub-cgroups only if it's available in parent
cgroup.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The assumption that CPU controller would be always enabled is wrong, we
should use any available controller to create a new sub-cgroup.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This affects only cgroups v2 where enabled controllers are not based on
available mount points but on the list provided in cgroup.controllers
file. However, moving it will fill in placement as well, so it needs
to be freed together with mount point if we don't need that controller.
Before this patch we were assuming that all controllers available in
root cgroup where available in all other sub-cgroups which was wrong.
In order to fix it we need to move the cgroup controllers detection
after cgroup placement was prepared in order to build correct path for
cgroup.controllers file.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In cgroups v2 we don't have to detect available controllers every single
time if we are creating a new cgroup based on parent cgroup.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our code would skip adding the default type in this cases, but since we
know that the only reasonable option here is 'fat' we can add it while
starting the VM.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The storage volume may in fact convert into a directory when starting
the VM so that it may be actually possible to use it.
This is a regression caused by c9b27af32d as moving the check to
validation time without adjustment causes problems as the volumes are
not translated yet.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuBuildDriveSourceStr omits the disk format string when we are
emulating a 'fat' filesystem from a directory. The logic should decide
based on the 'actualType' as a disk type=pool may be converted to a
directory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virStorageSourceGetActualType would return VIR_STORAGE_TYPE_NONE in case
when a virStorageSource of (top level) type VIR_STORAGE_TYPE_VOLUME was
not prepared to use by the vm by calling
virDomainDiskTranslateSourcePool.
Fix this issue by returning VIR_STORAGE_TYPE_VOLUME in case when the
volume was not translated yet.
Additionally also add documentation for the function describing the
quirk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The field is set just before returning on success.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When changing media using blockdev-add we need to remove the leftovers
if we didn't succeed plugging in the full chain or closing the tray.
Otherwise the data structures will be freed and thus the backing chain
members will never be unplugged.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As this conversion removes the last use of qemuHotplugDiskSource*
functions we can remove all of them now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new helpers for removing the backing chain in case when
-blockdev is used. For -drive this function has a local implementation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the use of qemuHotplugDiskSourceAttach* helpers with
qemuBuildStorageSourceChainAttachPrepare(Blockdev|Drive).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the open-coded local implementation with
qemuBuildStorageSourceChainAttachPrepare(Drive|Blockdev).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These are meant to replace the ad-hoc helpers qemuHotplugDiskSourceAttach...
and the open-coded version in qemu_command.c for use in command line
generation.
The functions for preparing for attach of chains unfortunately need to
be in qemu_command.c as they use function defined by that file and
inclusion hierarchy.
In this patch new functions are introduced and subsequent patches then
refactor individual parts to use them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We use only one copy-on-read filter per disk, so we should handle it
separately from the chain.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move it to qemu_block.c and call it qemuBlockStorageSourceDetachPrepare.
It will be reused in other parts as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We've deprecated qemuConnectDomainXMLFromNative qemuDomainQemuAttach.
Switch the error code from VIR_ERR_OPERATION_UNSUPPORTED to the new
VIR_ERR_DEPRECATED.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow a simple programatic check that a given feature is no longer
supported by introducing a separate error code for this scenario.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit a7fb2258 added sanitization of storage pool target paths,
however source dir paths were left unsanitized.
A netfs pool with:
<source>
<host name='10.20.30.40'/>
<dir path='/nfs/'/>
</source>
will not be correctly detected as mounted by
virStorageBackendFileSystemIsMounted, because it shows up in the
mount list without the trailing slash.
Sanitize the source dir as well.
https://bugzilla.redhat.com/show_bug.cgi?id=1723247
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The function modifies the context but did not care to restore it back.
If a <seclabel> was used on a disk, the <privateData> would not be
parsed.
Use VIR_XPATH_NODE_AUTORESTORE and add a test case to validate that
everything works.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add omitted comma for multiple hosts.
Fixes: cdd362e0e7
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Commit 9c9620af called x86DataAdd without checking for an error,
so add the error checking.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 56b254dcc called virCPUx86DataAdd, but returned -1 directly
without calling the virCPUx86DataFree.
Found by Coverity.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Trivial change. Adding the name of the device that has an
unknown PCI header type in that function helps when debugging
PCI code.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Commit 7bf679ae removed the @json argument from the qemuMonitorOpen
prototype; however, it did not update the ATTRIBUTE_NONNULL value
which causes a build failure for when checking is enabled such as
when lv_cv_static_analysis is enabled.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In the virStorageSourceChainHasManagedPR() function we iterate
over whole backing chain trying to determine if one of the layers
has managed PR configured. But due to a typo we in fact check the
top layer only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The files for libvirt-net-rpc-server.la refernce the sasl/sasl.h
system header but never used the $(SASL_CFLAGS) variable. This
was never noticed previously because the $(AVAHI_CLFAGS) were
set and these typically pulled in the same include directory.
When mDNS/Avahi support was removed this exposed the bug which
caused FreeBSD builds to break as /usr/local/include was no
longer searched for headers.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Filter out the given capabilities and set domain taint if we've done so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when e.g. a new feature breaks upstream behaviour it's useful
to allow users to disable the new feature to verify the regression and
possibly use it as a workaround until a fix is available.
The new qemu.conf option named "capability_filters" allows to remove
qemu capabilities from the detected bitmap.
This patch introduces the configuration infrastructure to parse the
option and pass it around.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For testing purposes it's sometimes desired to be able to control the
presence of capabilities of qemu. This adds the possibility to do this
via the qemu namespace.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly how we allow adding arbitrary command line arguments and
environment variables this patch introduces the ability to control
libvirt's perception of the qemu process by tweaking the capability bits
for testing purposes.
The idea is to allow developers and users either test a new feature by
enabling it early or disabling it to see whether it introduced
regressions.
This feature is not meant for production use though, so users should
handle it with care.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will allow enabling/disabling custom hypervisor
features for debugging/testing purposes via the qemu namespace.
Add a taint flag where we will flag such a domain so it's obvious what's
happening.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Simplify the main function by splitting out how we parse the extra
passthrough environment variables.
Note that the validation function checks that the first letter must be a
character or underscore which makes the check whether the name is
redundant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Simplify the main function by splitting out how we parse the extra
passthrough commandline arguments.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_conf.c deals with the configuration file. Better fit for the
structure and freeing function will be qemu_domain.c where the rest of
the namespace parsing/formatting stuff resides.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The data injected via the namespace may contain also other things than
commandline passthrough definitions. Rename it to make it more
universal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In kernel 4.12 there was introduced new BFQ scheduler and in kernel
5.0 the old CFQ scheduler was removed. This has an implication on
the cgroups file names.
If the CFQ controller is enabled we use one file:
io.weight
The new BFQ controller expose one file with different name:
io.bfq.weight
Except for different name they have different syntax.
io.weight:
default $val
major:minor $val
io.bfq.weight:
$val
The difference is that BFQ doesn't support per-device weight.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In kernel 4.12 there was introduced new BFQ scheduler and in kernel
5.0 the old CFQ scheduler was removed. This has an implication on
the cgroups file names.
If the CFQ controller is enabled we use these two files:
blkio.weight
blkio.weight_device
The new BFQ controller expose only one file with different name:
blkio.bfq.weight
The reason is that BFQ controller doesn't support per-device weight.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we need to get a path of specific file and we need to check its
existence before we use it then we can reuse that path to get value
for specific device. This way we will not build the path again in
virCgroupGetValueForBlkDev.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we need to get a path of specific file and we need to check its
existence before we use it then we can reuse that path to get/set
values instead of calling the existing get/set value functions which
would be building the path again.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We currently refuse to connect to remote libvirtd over SSH if we see the
path ends in /session. Earlier on though we checked for /session and set
the VIR_DRV_OPEN_REMOTE_USER flag. There is one subtle distinction
though with the test driver. All test URIs are marked with this flag,
regardless of whether the URI indicates a local or remote connection.
Previously a local connection to the test driver would have used the
unprivileged libvirtd while a remote connection would have tried the
privileged libvirtd. With this we are consistent and use the
unprivileged for both local & remote, if the current user is non-root.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the VIR_DRV_OPEN_REMOTE_USER flag is only set when we identify
that we're connecting to a local libvirtd daemon. We would like to be
able to set that even if connecting to a remote libvirtd daemon. This
entails refactoring the conditional check.
One subtle change is that the VIR_DRV_OPEN_REMOTE_USER is now set when
the test+XXX:// URI is used, even if a servername is present. This has
no effect in this patch, but will later.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirtd has long had integration with avahi for advertising libvirtd
using mDNS when TCP/TLS listening is enabled. For a long time the
virt-manager application had support for auto-detecting libvirtds
on the local network using mDNS, but this was removed last year
commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
Author: Cole Robinson <crobinso@redhat.com>
Date: Sat Oct 6 20:55:31 2018 -0400
connect: Drop avahi support
Libvirtd can advertise itself over avahi. The feature is disabled by
default though and in practice I hear of no one actually using it
and frankly I don't think it's all that useful
The 'Open Connection' wizard has a disproportionate amount of code
devoted to this feature, but I don't think it's useful or worth
maintaining, so let's drop it
I've never heard of any other applications having support for using
mDNS to detect libvirtd instances. Though it is theoretically possible
something exists out there, it is clearly going to be a niche use case
in the virt ecosystem as a whole.
By removing avahi integration we can cut down the dependency chain for
the basic libvirtd install and reduce our code maint burden.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The unprivileged libvirtd daemon switched to use the XDG dir layout in
the 0.9.13 release, and included code for moving config files from the
old location. The chances of someone upgrading libvirt from <= 0.9.12
directly to libvirt >= 5.5.0 is close enough to zero that we can
reasonably drop the back compat code.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In libssh 0.9.0 functions ssh_is_server_known and ssh_write_knownhost
are marked as deprecated.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1722735
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
testDomainInterfaceAddresses always returns the same hard-coded
addresses. Change the behavior such as if there is a DHCP range defined,
addresses are returned from that pool.
The specific address returned depends on both the domain id and the
specific guest interface in an attempt to return unique addresses *most
of the time*.
Additionally, properly handle IPv6 networks which were previously
ignored completely.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When connecting to virtlogd fails e.g. due to wrong libvirtd selinux
process label we'd report an utterly useless error message:
$ virsh start upstream
error: Failed to start domain upstream
error: Cannot recv data: Connection reset by peer
Use virLastErrorPrefixMessage in the correct place to give a better
sense of what's going on:
$ virsh start upstream
error: Failed to start domain upstream
error: can't connect to virtlogd: Cannot recv data: Connection reset by peer
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
In some cases we report a low level error message which does not have
enough information to see what the problem is. To allow improving on
this add an API which will prefix the error message with another error
message string which can be used to describe where the error comes from.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Commit f34397e51c introduced a crash-inducing problem when collecting
disk snapshot data, where the array would be filled starting from the
second element.
The code then dereferenced the first one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The "cpu-add" command is supported in all supported qemu versions and
cpu unplug did not work at all until the new cpu unplug approach (using
device_add/del) was implemented.
Remove the support for falling back to the text monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The docstring of virNetworkGetDHCPLeases is not correctly formatted and
as a result the example code snippet appears as normal text under the
"Returns:" section. This patch fixes the problem.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.
Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Without "unavailable-features" CPU property we cannot properly detect
whether a specific MSR feature we asked for (either explicitly or
implicitly via a CPU model) was disabled by QEMU for some reason.
Because this could break migration, snapshots, and save/restore
operaions, it's better to just forbid any use of MSR features with QEMU
which lacks "unavailable-features" CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is used by the host capabilities code to construct host CPU
definition.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This functions may be used as a virCPUDefFeatureFilter callbacks for
virCPUDefCheckFeatures, virCPUDefFilerFeatures, and similar functions to
select (virCPUx86FeatureFilterSelectMSR) or drop
(virCPUx86FeatureFilterDropMSR) features reported via MSR.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Until now, this was a macro usable for direct initialization when a
variable is defined. Turning the macro into a function makes it more
general.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This API can be used to check whether a CPU definition contains features
matching a given filter.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These APIs can be used to execute arbitrary emulators.
Forbid them on read-only connections.
Fixes: CVE-2019-10168
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This API can be used to execute arbitrary emulators.
Forbid it on read-only connections.
Fixes: CVE-2019-10167
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainManagedSaveDefineXML can be used to alter the domain's
config used for managedsave or even execute arbitrary emulator binaries.
Forbid it on read-only connections.
Fixes: CVE-2019-10166
Reported-by: Matthias Gerstner <mgerstner@suse.de>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainSaveImageGetXMLDesc API is taking a path parameter,
which can point to any path on the system. This file will then be
read and parsed by libvirtd running with root privileges.
Forbid it on read-only connections.
Fixes: CVE-2019-10161
Reported-by: Matthias Gerstner <mgerstner@suse.de>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Use 'rc' to temporarily store the subfunction return values,
instead of ret.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
In preparation to removing the json field from qemuMonitor,
stop checking for it in QEMU_CHECK_MONITOR.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Always assume JSON monitor was requested, since all the callers
pass true anyway.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Now that we no longer support the HMP monitor, remove some dead code.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
No reason not to be consistent with the user-visible value.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using 8 hex digits all the time, regardless of whether the
actual value can fit in fewer, makes it more obvious to the
user what the limits are.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to sPAPR, addresses are 32-bit rather than 64-bit.
Update qemuDomainDeviceDefValidateAddress() accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1598657
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce a switch() statement and prepare for validating
more address types than just PCI.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the virDomainQemuAttach API returns an error, we can remove the
unused qemuProcessAttach function as well, deleting the only user
that possibly could have requested to open a non-JSON monitor.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The only user is now in qemu_monitor_json.c to re-parse the command line
format into keyvalue pairs for use in QMP command construction.
Move and rename the functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
qemu_domain.c is now the only place that uses it, so we can move it from
qemu_parse_command.h
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
It's now unused and utterly obsolete.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This code is really neglected and does not at all work reliably. It
can't even be used for converting our own commandline back.
Since this was mostly useful for aiding migration from manually run qemu
to libvirt and will not work for this puspose in many cases it's not
worth having.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we no longer support attaching to a live QEMU process not
managed by libvirt we can drop the backend functions as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Attaching to modern qemu will not work with all this code and attempting
to ressurect it would be mostly pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There are couple of functions which get shorter after the
treatment.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Couple of things happening in this patch:
1) We can mark the device we're adding onto active list as used
way before - when adding it onto temporary list.
2) When actually moving device from a temporary helper list onto
the list of active devices we check if the device isn't
already there. The same check is performed by
virSCSIVHostDeviceListAdd() later. Drop this duplicity.
3) The 'error' label is renamed to 'rollback' to reflect what it
is actually doing. While in the rest of the code we don't
allow random label names, this source file is different.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When looking up a USB device by vendor the
virUSBDeviceFindByVendor() is used. The function returns number
of items found. But the logic in caller to process it is
needlessly complicated.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are couple of functions which get shorter after the
treatment.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's no need to translate virDomainHostdevDef-s into
virPCIDevice-s with locked list of PCI devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's no need to translate virDomainHostdevDef-s into
virPCIDevice-s with locked list of PCI devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function is a good candidate for VIR_AUTOPTR() conversion.
But this conversion will be easier if we only add @pci device
onto @pcidevs list after it was all set up.
This is no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If spawning qemu fails then we report an error and proceed to
writing status XML onto the disk. This is unnecessary as we are
sure that the domain is not running.
At the same time, if virPidFileReadPath() fails it returns
-errno. Use it in the error message. It may explain what went
wrong.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting from version 4.1 qemu allows reporting 'features' for a given
QAPI type object. This allows reporting support of fixes and additions
which are otherwise invisible in the QAPI schema.
Implement a possibility to query 'features' in the QAPI query strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When updating guest CPU definition according to the vCPU actually
created by QEMU, we want to use the generic qemuMonitorGetGuestCPU to
get both CPUID and MSR features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unlike the old version (which is now called qemuMonitorGetGuestCPUx86),
this monitor API checks for individual features by their names rather
than processing CPUID bits. Thus we can get the list of enabled and
disabled features for both CPUID and MSR features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function converts a list of QOM properties into a NULL-terminated
array of property names. The new type parameter may be used to limit the
result to properties of a specific type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a generic replacement for the former virCPUx86DataAddFeature,
which worked on the generic virCPUDataPtr anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was never implemented or used for anything else anyway. Mainly
because it uses CPUID features bits. The function is renamed as
qemuMonitorGetGuestCPUx86 to make this explicit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We used type=full expansion on the result of previous type=static
expansion to get all possible spellings of CPU features. Since we can
now translate the QEMU's canonical names to our names, we can drop this
magic and do only type=static CPU model expansion.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By default query-cpu-model-expansion only reports canonical names of all
CPU features. We do some magic and call the command twice to get all
possible spellings of the features, but being able to consume canonical
names will allow us to drop this magic.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When building QEMU command line, we should use the preferred spelling of
each CPU feature without relying on compatibility aliases (which may be
removed at some point).
The "unavailable-features" CPU property is used as a witness for the
correct names of the features in our translation table.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way we call query-cpu-model-expansion will rely on some capabilities
bits. Let's make sure all capabilities are set before probing host CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It is similar to "filtered-features" property, which reports CPUID bits
corresponding to disabled features, but more general. The
"unavailable-features" property supports both CPUID and MSR features by
listing their names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We will use it to check whether QEMU supports a specific CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far we always used libvirt's name of each CPU feature relying on
backward compatible aliases in QEMU. The new translation table can be
used whenever QEMU mandates or prefers canonical feature names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Normal CPU features use modern -cpu ...,feature=on|off syntax when
available, but kvm features kept using the old +feature or -feature.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Properly filter features which should not be passed to QEMU because they
were never supported by QEMU or they did nothing and QEMU dropped them.
Currently they are just silently ignored by the command line generator.
Let's make this process more visible and clean by dropping the features
from the domain's active definition in qemuProcessUpdateGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This new internal API can be used for in place filtering of CPU features
in virCPUDef.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already have virQEMUCapsCPUFilterFeatures for filtering features
which QEMU does not know about. Let's move osxsave and ospke from
qemuFeatureNoEffect there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
