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>
