A function that keeps the hash in binary form instead of converting
it to human-readable hexadecimal form.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The callers needing to know the size of the resulting digest
rely on _DIGEST_SIZE constants from gnulib.
Introduce VIR_CRYPTO_HASH_SIZE_ constants to remove the dependency.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1480668
QEMU has this new feature memory-backend-file.discard-data=yes
which is a nifty optimization. Basically, when qemu is quitting
or on memory hotplug it calls munmap() and close() on the file
that is backing the memory. However, this does not mean kernel
won't stop touching that part of memory. It still might. With
this feature enabled we tell kernel: "we don't need this memory
nor data stored in it". This makes kernel drop the memory
immediately without trying to sync memory with the mapped file.
Unfortunately, this cannot be turned on by default because we
can't be sure when users really don't care about what happens to
data after qemu dies. So it has to be opt-in. As usual, there are
three places where one can configure memory attributes. This
patch adds the feature to all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU has possibility to call madvise(.., MADV_REMOVE) in some
cases. Expose this feature to users by new element/attribute
discard.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the same time convert the code to use virXMLFormatElement.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if qemu has "qom-list-properties" monitor
command.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we've gotten rid of misleading names we can introduce
qemuMonitorGetObjectProps() function which queries -object
properties. Again, some parts of code can be reused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code that processes list of device properties is going to be
reused. Therefore put it into a separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The <memoryBacking><locked/></memoryBacking> element will now pass the
wired (-S) flag to the bhyve command.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Strongly recommend against use of the log_levels setting since it
creates overly verbose logs and has a serious performance impact.
Describe the log filter syntax better and mention use of shell
glob syntax. Also provide more realistic example of good settings
to use. The libvirtd example is biased towards QEMU, but when the
drivers split off each daemon can get its own more appropriate
example.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Rather than specialcasing handling of the '*' character, use fnmatch()
to get normal shell wildcard syntax, as described in 'man glob(7)'.
To get an indication of the performance impact of using globs instead
of plain string matches, a test program was written. The list of all
260 log categories was extracted from the source. Then a typical log
filters setup was picked by creating an array of the strings "qemu",
"security", "util", "cgroup", "event", "object". Every filter string
was matched against every log category. Timing information showed that
using strstr() this took 8 microseconds, while fnmatch() took 114
microseconds.
IOW, fnmatch is 14 times slower than our existing strstr check. These
numbers show a worst case scenario that will never be hit, because it
is rare that every log category would have data output. The log category
matches are cached, so each category is only checked once no matter how
many log statements are emitted. IOW despite being slower, this will
be lost in the noise and have no consequence on real world logging
performance.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's this macro virBufferSetChildIndent which sets offset of
child buffer from given parent buffer. However, it is calling
virBufferAdjustIndent() which only adds adjustment instead of
calling virBufferSetIndent() which clears out any adjustment
previously set.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After version 0.7.5, libssh deprecated the function scope
ssh_get_publickey() and moved to ssh_get_server_publickey(). So, Libvirt
is failing to compile using this new function name.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If we are the last one to use pr-manager object we need to remove
it and also kill the qemu-pr-helper process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When attaching a disk that requires pr-manager we might need to
plug the pr-manager object and start the pr-helper process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Before we exec() qemu we have to spawn pr-helper processes for
all managed reservations (well, technically there can only one).
The only caveat there is that we should place the process into
the same namespace and cgroup as qemu (so that it shares the same
view of the system). But we can do that only after we've forked.
That means calling the setup function between fork() and exec().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like we allow users overriding path to bridge-helper
detected at compile time we can allow them to override path to
qemu-pr-helper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like in previous commit, qemu-pr-helper might want to open
/dev/mapper/control under certain circumstances. Therefore we
have to allow it in cgroups.
The change virdevmapper.c might look spurious but it isn't. After
6dd84f6850 any path that we're allowing in deivces CGroup is
subject to virDevMapperGetTargets() inspection. And libdevmapper
returns ENXIO for the path from subject.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If qemu-pr-helper is compiled with multipath support the first
thing it does is open /dev/mapper/control. Since we're going
to be running it inside qemu namespace we need to create it
there. Unfortunately, we don't know if it was compiled with or
without multipath so we have to create it anyway.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For command line we need two things:
1) -object pr-manager-helper,id=$alias,path=$socketPath
2) -drive file.pr-manager=$alias
In -object pr-manager-helper we tell qemu which socket to connect
to, then in -drive file-pr-manager we just reference the object
the drive in question should use.
For managed PR helper the alias is always "pr-helper0" and socket
path "${vm->priv->libDir}/pr-helper0.sock".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The capability tracks if qemu has pr-manager-helper object. At
this time don't actually detect if qemu has the capability. Not
just yet. Only after the code is written the feature will be
enabled.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Couple of reasons for that:
a) there's no monitor command to change path where the pr-helper
connects to, or
b) there's no monitor command to introduce a new pr-helper for a
disk that already exists.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a definition that holds information on SCSI persistent
reservation settings. The XML part looks like this:
<reservations enabled='yes' managed='no'>
<source type='unix' path='/path/to/qemu-pr-helper.sock' mode='client'/>
</reservations>
If @managed is set to 'yes' then the <source/> is not parsed.
This design was agreed on here:
https://www.redhat.com/archives/libvir-list/2017-November/msg01005.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Rather than have virJSONValueArraySize return a -1 when the input
is not an array and then splat an error message, let's check for
an array before calling and then change the return to be a size_t
instead of ssize_t.
That means using the helper virJSONValueIsArray as well as using a
more generic error message such as "Malformed <something> array".
In some cases we can remove stack variables and when we cannot,
those variables should be size_t not ssize_t. Alter a few references
of if (!value) to be if (value == 0) instead as well.
Some callers can already assume an array is being worked on based
on the previous call, so there's less to do.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The pointer to the qemu driver is already included in domain object's
private data, so does not need to be passed as yet another parameter
when the domain object is already passed.
Also removes parameter 'driver' from functions which had it just because of
qemuBlockJobUpdate.
Signed-off-by: Roland Schulz <schullzroll@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Use the new helper when checking that the VM needs to be tainted as a
host-cdrom passthrough.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The function will be reused in the test code where we don't care much
that the gluster debug level can't be populated from the qemu config.
Set the level only when 'cfg' is passed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When using blockdev-add and friends, libvirt will need to create also
properties for the qcow2/raw/... format handler in qemu. This patch adds
the infrastructure and implements all formats known to libvirt including
all properties which are expressed at the format level in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Enabling discard for the storage node allows the format drivers to
discard snapshots and other things, while configuration of the format
layer actually decides whether to actually discard data on request from
the host.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This will be required when doing blockdev-add to conform with the
approach qemu choses to create the disks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When used directly with blockdev-add/-blockdev the cache mode will need
to be specified directly for every image rather than just for the disk
itself. This implements the backing options 'direct' and 'no-flush'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
qemu declares node-name as a 32 byte buffer and silently truncates
anything longer than that. This is unacceptable for libvirt, so we need
to make sure that we won't ever supply a node-name exceeding 31 chars.
Add a function which will do the validation and use it to validate
storage-protocol node names.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The gluster protocol in qemu uses two styles, one of which is legacy and
not covered by the QAPI schema.
To allow using of the new style in the blockdev-add code, add a
parameter for qemuBlockStorageSourceGetBackendProps which will switch
between the two modes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Block storage should actually be passed to qemu via 'host_device' or
'host_cdrom' according to the device type. There were no users of this
behaviour so we thankfully can change it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use virFileIsCDROM to detect whether a block device is a cdrom drive and
store it in virStorageSource. This will be necessary to correctly create
the 'host_cdrom' backend in qemu when using -blockdev.
We assume that host_cdrom makes only sense when used directly as a raw
image, but if a backing chain would be put in front of it, libvirt will
use 'host_device' in that case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add detection mechanism which will allow to check whether a path to a
block device is a physical CDROM drive. This will be useful once we will
need to pass it to hypervisors.
The linux implementation uses an ioctl to do the detection, while the
fallback uses a simple string prefix match.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Handle VIR_STORAGE_TYPE_DIR in qemuBlockStorageSourceGetBackendProps so
that a 'vvfat' driver is used, which emulates a FAT filesystem
containing the folders.
qemu requires us to add it as a storage layer, since a 'raw' layer is
usually put on top of it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Move it to the validation callback and make it more robust. This will
also put the checks in the correct place to use with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add a flag denoting that a virStorageSource is going to be used as a
floppy image. This will be useful in cases where the user passes in
files which shall be exposed as an image to the guest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
'file' backend in qemu supports few more options than the current
implementation. Extract it so that changes don't pollute the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Some properties don't make sense to be configured for every single layer
of the backing chain, but to avoid needing to pass the disk structure we
will copy them to the individual virStorageSource.
Zero detection is applied only for the top layer image, while caching
and iomode for all layers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Few things which are currently stored the virDomainDiskDef structure are
actually relevant for the storage source as well. Add the fields with a
note that they are just mirror of the values from the disk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Save and restore node names if we know them or when we will be
generating them in the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Everything besides the top of the chain is readonly. Track this when
parsing the XML and detecting the chain from the disk. Also fix the
state when taking snapshots.
All other cases where the top image is changed already preserve the
readonly state from the original image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability is unused since we stopped parsing -help output.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The -no-kvm-pit-reinjection option has been deprecated since
its introduction in QEMU 1.3. See commit <1569fa1>.
Drop the capability since all the QEMUs we support allow tuning
the kvm-pit properties via -global.
Also add the QEMU_CAPS_KVM_PIT_TICK_POLICY to the clock-catchup
tests, since expecting it to succeed with QEMU that does not
have kvm-pit makes no sense.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since we started assuming QEMU_CAPS_MACHINE_OPT in
commit <69420756>, this function can only be reached
for unsupported virt types.
Replace the call with a virReportError.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We have been checking whether qemu-img supports the -o compat
option by scraping the -help output.
Since we require QEMU 1.5.0 now and this option was introduced in 1.1,
assume we support it and ditch the help parsing code along with the
extra qemu-img invocation.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When adding a new object to the domain object list, there should
have been 2 virObjectRef calls made one for each list into which
the object was placed to match the 2 virObjectUnref calls that
would occur during Remove as part of virHashRemoveEntry when
virObjectFreeHashData is called when the element is removed from
the hash table as set up in virDomainObjListNew.
Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
by calling virObjectRef upon successful return from virDomainObjListAdd
in order to use virDomainObjEndAPI when done with the returned @vm.
While others (bhyve, openvz, test, and vmware) handled this via only
calling virObjectUnlock upon successful return from virDomainObjListAdd.
This patch will "unify" the approach to use virDomainObjEndAPI
for any @vm successfully returned from virDomainObjListAdd.
Because list removal is so tightly coupled with list addition,
this patch fixes the list removal algorithm to return the object
as entered - "locked and reffed". This way, the callers can then
decide how to uniformly handle add/remove success and failure.
This removes the onus on the caller to "specially handle" the
@vm during removal processing.
The Add/Remove logic allows for some logic simplification such
as in libxl where we can Remove the @vm directly rather than
needing to set a @remove_dom boolean and removing after the
libxlDomainObjEndJob completes as the @vm is locked/reffed.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Since the @dconn reference via args->conn will be used via a thread
or callback, let's make sure memory associated with it isn't free'd
unexpectedly before we use it. The Unref will be done when the object
is Dispose'd.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When adding the @vm to the @args for usage during a thread or
callback, let's add the reference to it at the time of adding to
ensure nothing else deletes it. The corresponding Unref is then
added to the Dispose function.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Rather than open code within virDomainObjListRemove, just call
the *Locked function.
Additionally, add comments to virDomainObjListRemove to describe
the usage model.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Use the FindBy{UUID|Name}Locked helpers which will return a locked
and ref counted object rather than the direct virHashLookup and
virObjectLock of the returned object. We'll need to temporarily
virObjectUnref when we assign a new domain @def, but that will
change shortly when virDomainObjListAddObjLocked returns the
correct reference counted object.
Use the virDomainObjEndAPI in the error path to Unref/Unlock for
the corresponding Unref/Unlock of either the FindBy* return or
the virDomainObjNew since both return a reffed/locked object.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Create helpers virDomainObjListFindByUUIDLocked and
virDomainObjListFindByNameLocked to avoid the need
to lock the domain object list leaving that task
for the caller.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This is the old style and we really shouldn't be adding any more
examples like this. Add a comment to warn devs away
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<features><vmcoreinfo/> is a bare boolean XML property. We don't really
use this format anymore and instead prefer tristate <X state=on|off/>
since it's required for modeling on/off/default. If for example future
qemu started enabling vmcoreinfo by default we wouldn't have any way
for the user to turn this off.
Convert it to tristate. For writing XML this is semanticly the same,
<vmcoreinfo/> is processed as <vmcoreinfo state='on'/>.
For apps reading guest XML this is technically an API change,
as they might misinterpret <vmcoreinfo state='off'/>, however this
has only been present in libvirt since 3.10.0 and I don't think any
apps are dependent on this yet
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We want to make sure our wrapper is used instead in order
to keep the test suite working.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The latter is impossible to mock on platforms that use the
gnulib implementation, such as FreeBSD, while the former
doesn't suffer from this limitation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It's a trivial wrapper around canonicalize_file_name(),
which we need in order to fully mock file access on non-Linux
platforms.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The vm name is not needed for any functional requirement, but it will be
useful when debugging problems to identify which VM is associated with a
filter, since UUID is not human friendly.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainNet struct contains everything related to configuring a
guest network device. Out of all of this info, only 5 fields are
relevant to configuring network filters. It will be more convenient for
future changes to the nwfilter driver if the relevant fields are kept in
a dedicated struct. Thus the virNWFilterBinding struct is created to
track this information.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The filter parameters were not correctly free'd when an error hits while
adding to the hash table.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is a bunch of left over code in the nwfilter driver related to
monitoring firewalld over dbus, that is no longer used since the
conversion to use virFirewall APIs.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNWFilterIPAddrLearnReq type should only be used by the IP address
learning code, so can live in the implementation file instead of header
file.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Various methods return a virNWFilterIPAddrLearnReq struct, but the
callers are only interested in whether the return value is non-NULL.
It is thus preferrable to just return a bool.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
