Fedora 30 has been EOL for almost a month now.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NErik Skultety <eskultet@redhat.com>

The same functionality can be achieved using migrate-set-parameters QMP
command with xbzrle-cache-size parameter.

https://bugzilla.redhat.com/show_bug.cgi?id=1845012Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The same functionality can be achieved using query-migrate-parameters
QMP command and checking the xbzrle-cache-size parameter.

https://bugzilla.redhat.com/show_bug.cgi?id=1829544Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The same functionality can be achieved using migrate-set-parameters QMP
command with downtime-limit parameter.

https://bugzilla.redhat.com/show_bug.cgi?id=1829543Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The same functionality can be achieved using migrate-set-parameters QMP
command with max-bandwidth parameter.

https://bugzilla.redhat.com/show_bug.cgi?id=1829545Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

These parameters were originally set via dedicated commands which are
now deprecated. We want to use migrate-set-parameters instead if
possible.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

In v6.4.0-72-g3dda889a I've introduced parsing and formatting
of new sysinfo type 'fwcfg'. However, I've forgot to introduce
code that would free parsed data.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

This function handles the change of NUMA nodeset for a given
guest, setting CpusetMems for the emulator, vcpus and IOThread
sub-groups. It doesn't set the same  nodeset to the root cgroup
though. This means that cpuset.mems of the root cgroup ends up
holding the new nodeset and the old nodeset as well. For
a guest with placement=strict, nodeset='0', doing

virsh numatune <vm> 0 8 --live

Will make cpuset.mems of emulator, vcpus and iothread to be
"8", but cpuset.mems of the root cgroup will be "0,8".

This means that any new tasks that ends up landing in the
root cgroup, aside from the emulator/vcpus/iothread sub-groups,
will be split between the old nodeset and the new nodeset,
which is not what we want.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since a08669c3, @tsc is not automatically free'd by any g_auto* method.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 1f5deed9, @veid_str has been leaked in the error path.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 60623a7c, @temp_file was not properly free'd on the non error path.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since ceb3255c, @absFile is leaked.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 9ea90206, @drvpath could be overwritten if we jumped to recheck

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 5b82f7f3, @path should have been placed inside the for loop
since it'd need to be free'd for each pass through the loop; otherwise,
we'd leak like a sieve.

Found by Coverity.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 5084091a, @authcred is filled by a g_key_file_get_string which is
now an allocated string as opposed to some hash table lookup value, so
we need to treat it as so.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Since 5084091a, @tmp is filled by a g_key_file_get_string which is
now an allocated string as opposed to some hash table lookup value,
so we need to treat it as so.

Found by Coverity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

On Linux, changing the nodeset on 'numatune' does not imply that
the guest memory will be migrated on the spot to the new nodeset.
The memory migration is tied on guest usage of the memory pages,
and an idle guest will take longer to have its memory migrated
to the new nodeset.

This is a behavior explained in detail in the Linux kernel
documentation in Documentation/admin-guide/cgroup-v1/cpusets.rst.
The user doesn't need this level of detail though - just needs
his/her expectations under check. Running 'numastat' and hoping
for instant memory migration from the previous nodeset to the new
one is not viable.

There's also parts of the memory that are locked by QEMU in the
same place, e.g. when VFIO devices are present. Let's also
mention it as another factor that impacts the results the
user might expect from NUMA memory migration with numatune.

https://bugzilla.redhat.com/show_bug.cgi?id=1640869Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Commit 068efae5 accidentally removed the slash.

https://bugzilla.redhat.com/show_bug.cgi?id=1847234Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Domains are now allowed to be pinned to host CPUs with IDs up to 16383.
The new limit is as arbitrary as the old one. It's just bigger.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Protected virtualization/IBM Secure Execution for Linux protects
guest memory and state from the host.

Add some basic information about technology and a brief guide
on setting up secure guests with libvirt.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Update document with changes in qemu capability caching and the added
secure guest support checking for AMD SEV in virt-host-validate.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add checking in virt-host-validate for secure guest support
on x86 for AMD Secure Encrypted Virtualization.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add checking in virt-host-validate for secure guest support
on s390 for IBM Secure Execution.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Implement secure guest check for AMD SEV (Secure Encrypted
Virtualization) in order to invalidate the qemu capabilities
cache in case the availability of the feature changed.

For AMD SEV the verification consists of:
 - checking if /sys/module/kvm_amd/parameters/sev contains the
   value '1': meaning SEV is enabled in the host kernel;
 - checking if /dev/sev exists
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This patch introduces a common function to verify if the
availability of the so-called Secure Guest feature on the host
has changed in order to invalidate the qemu capabilities cache.
It can be used as an entry point for verification on different
architectures.

For s390 the verification consists of:
- checking if /sys/firmware/uv is available: meaning the HW
facility is available and the host OS supports it;
- checking if the kernel cmdline contains 'prot_virt=1': meaning
the host OS wants to use the feature.

Whenever the availability of the feature does not match the secure
guest flag in the cache then libvirt will re-build it in order to
pick up the new set of capabilities available.
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Introduce two utility functions to parse a kernel command
line string according to the kernel code parsing rules in
order to enable the caller to perform operations such as
verifying whether certain argument=value combinations are
present or retrieving an argument's value.
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This was mostly boilerplate conversion, but in one case I needed to
define several differently named char* to take the place of a single
char *tmp that was re-used multiple times, and in another place there
was a single char* that was used at the toplevel of the function, and
then later used repeatedly inside a for loop, so I defined a new
separate char* inside the loop.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Now that we have support for IPv6 in the iptables helpers, and a new
option in the XML schema, we can wire up support for it in the network
driver.
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Historically IPv6 did not support NAT, so when IPv6 was added to
libvirt's virtual networks, when requesting <forward mode="nat"/>
libvirt will NOT apply NAT to IPv6 traffic, only IPv4 traffic.

This is an annoying historical design decision as it means we
cannot enable IPv6 automatically. We thus need to introduce a
new attribute

   <forward mode="nat">
     <nat ipv6="yes"/>
   </forward>
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

IPv6 does support masquerade since Linux 3.9.0 / ip6tables 1.4.18,
which is Fedora 18 / RHEL-7 vintage, which covers all our supported
Linux versions.
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

In v6.4.0-rc1~143 I've introduced a check that is supposed to
return from the function early, if given path is not a dm target.
While the idea is still valid, the implementation had a flaw.
It calls stat() over given path and the uses major(sb.st_dev) to
learn the major of the device. This is then passed to
dm_is_dm_major() which returns true or false depending whether
the device is under devmapper's control or not.

The problem with this approach is in how the major of the device
is obtained - paths managed by devmapper are special files and
thus we want to be using st_rdev instead of st_dev to obtain the
major number. Well, that's what virIsDevMapperDevice() does
already so might as well us that.

Fixes: 01626c66
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1839992Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

When introducing virdevmapper.c (in v4.3.0-rc1~427) I didn't
realize there is a function that calls in devmapper. The function
is called virIsDevMapperDevice() and lives in virutil.c. Now that
we have a special file for handling devmapper move it there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The repository is now obsolete, and it never had proper GitLab CI
support anyway.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There are many different settings that required to config a KVM guest
for real time, low latency workoads. The documentation included here is
based on guidance developed & tested by the Red Hat KVM real time team.
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Compilers are not very good at detecting this problem. Fixed by manual
inspection of compilation warnings after replacing 'VIR_FREE' with an
empty macro.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

If one of the early checks to get screen resolution fails 'screenData'
would be passed to VIR_FREE uninitialized. Unfortunately the compiler
isn't able to detect this when VIR_FREE is implemented using
g_clear_pointer.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

'uri_out' may be passed to VIR_FREE uninitialized if 'conn' is NULL.
Unfortunately the compiler isn't able to detect this problem when
VIR_FREE is implemented using g_clear_pointer. Initialize the variable.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com