These files are using functions from virstoragefile.h but are missing
explicit include.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The way this completer works is that it dumps XML of specified
domain and then tries to look for @name attribute of <alias/>
element. However, the XPATH it uses is not correct which results
in no aliases returned by the completer.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When adding a rule for an image file and that image file has a chain
of backing files then we need to add a rule for each of those files.
To get that iterate over the backing file chain the same way as
dac/selinux already do and add a label for each.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/118
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
A few commits ago I've implemented virtio-pmem memory model.
Mention it in the news file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since Hyper-V allows multiple VMs to be created with the same name,
some commands produce unpredictable results due to
hypervDomainLookupByName's WMI query selecting the wrong domain.
For example, this prevents `virsh dumpxml` from outputting XML for the
wrong domain.
Signed-off-by: Matt Coleman <matt@datto.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Leap 15.1 will reach EOL on January 31st 2021, so we should not test on
it during the current development cycle ending on March 1st.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In this refresh CentOS 7 now uses docker.io registry and the PowerTools
repo name regression was fixed for CentOS Stream this time.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This should fix CI error:
../dist-unpack/libvirt-7.1.0/src/storage/storage_backend_vstorage.c:10:10: fatal error: 'mntent.h' file not found
#include <mntent.h>
^~~~~~~~~~
on freebsd and mac.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
As can be seen in commit 8a62a1592a (from
autoconf era), the coverage flags have to be used also when linking
objects. However, this was not reflected when we switched to meson.
Without this patch linking fails with undefined references to various
__gcov_* symbols.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The current formulation can lead people to believe SCSI
controllers only allow the virtio-scsi model, but really the
only difference is that you have to use model='virtio-scsi'
where you would use model='virtio' for another device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
It's better to fill in missing values in post parse callbacks
than during parsing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The _virDomainMemoryDef structure has @uuid member which is
needed for PPC64 guests. No other architectures use it. Since the
member is VIR_UUID_BUFLEN bytes long, the structure is
unnecessary big. If the member is just a pointer then we can also
replace some calls of virUUIDIsValid() with plain test against
NULL and also simplify formatter code which can now also check
the pointer against NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now we have everything prepared for generating the command line.
The device alias prefix was chosen to be 'virtiopmem'.
Since virtio-pmem-pci device goes onto PCI bus generating device
alias must have been changed slightly because
qemuAssignDeviceMemoryAlias() might have used DIMM slot number to
generate the alias. This obviously won't work and thus the "old"
way (which includes qemuDomainDeviceAliasIndex()) must be used.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1735375
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Some users might want to have virtio-pmem backed by a block device
in which case we have to create the device in the domain private
namespace.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Some users might want to have virtio-pmem backed by a block
device in which case we have to allow the device in CGroups.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Just like with NVDIMM model, we have to relabel the path to
virtio-pmem so that QEMU can access it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The virtio-pmem is a virtio variant of NVDIMM and just like
NVDIMM virtio-pmem also allows accessing host pages bypassing
guest page cache. The difference is that if a regular file is
used to back guest's NVDIMM (model='nvdimm') the persistence of
guest writes might not be guaranteed while with virtio-pmem it
is.
To express this new model at domain XML level, I've chosen the
following:
<memory model='virtio-pmem' access='shared'>
<source>
<path>/tmp/virtio_pmem</path>
</source>
<target>
<size unit='KiB'>524288</size>
</target>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</memory>
Another difference between NVDIMM and virtio-pmem is that while
the former supports NUMA node locality the latter doesn't. And
also, the latter goes onto PCI bus and not into a DIMM module.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This commit introduces a new capability that reflects virtio-pmem-pci
device support in qemu:
QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI, /* -device virtio-pmem-pci */
The virtio-pmem-pci device was introduced in QEMU 4.1.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is an adaptation of the libvirtd manpage.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This group will be distinct from the per-driver modular daemon mapages.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Subsitute in the current version so the example always reflect today's
version of reality.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the past, the MTU of libvirt virtual network bridge devices was
implicitly set by setting the MTU of the "dummy tap device" (which was
being added in order to force a particular MAC address from the
bridge). But the dummy tap device was removed in commit ee6c936fbb
(libvirt-6.8.0), and so the mtu setting in the network is ignored.
The solution is, of course, to explicitly set the bridge device MTU
when it is created.
Note that any guest interface with a larger MTU that is attached will
cause the bridge to (temporarily) assume the larger MTU, but it will
revert to the bridge's own MTU when that device is deleted (this is
not due to anything libvirt does; it's just how Linux host bridges
work).
Fixes: ee6c936fbb
Resolves: https://bugzilla.redhat.com/1913561
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
managed='no' on an <interface> allows an unprivileged libvirt to use a
pre-created tap/macvtap device that libvirt has permission to
open/read/write, but no permission to modify (i.e. set the MTU or MAC
address). But when the XML had an <mtu size='blah'/> setting (which
was put there in order to tell the *guest* OS what MTU to set for the
emulated device at the other end of the tap) we were attempting to set
the MTU of the tap device on the host, paying no attention to the
setting of 'managed'. That would of course end in failure.
This patch only sets the MTU if managed='no' is *not* set (so, if it
is 'yes', or just not set at all).
Note that MTU of the tap is also set when connecting the tap to a
bridge device, but managed='no' is only allowed for <interface
type='ethernet'>, which would never attach to a bridge anyway, so we
don't need the check there.
Resolves: https://bugzilla.redhat.com/1905929
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The error message printed by scripts/group-qemu-caps.py and
scripts/test-wrap-argv.py doesn't actually print the filename of the
offending file:
Incorrect line wrapping in $file
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
