While 'namespace' is not a reserved word in C, it is in C++. Our
compilers are happy with it but syntax-hilighting in some editors
hilights is as a keyword. Rename it to prevent confusion.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

virHostCPUGetStatsLinux walks through every cpu in /proc/stat until it
finds cpu%cpuNum that matches with the requested cpu.
If none is found it logs the error but it should return -1, instead of 0.
Otherwise virsh nodecpustats --cpu <invalid cpu number> and API bindings
don't fail properly, printing a blank line instead of an error message.

This patch also includes an additional test for virhostcputest to avoid
this regression to happen again in the future.

Fixes: 93af79fbReported-by: NSatheesh Rajendran <satheera@in.ibm.com>
Signed-off-by: NMauro S. M. Rodrigues <maurosr@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Use just 'fs' instead of 'virtiofsd'.

https://bugzilla.redhat.com/show_bug.cgi?id=1816577Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

There is no need to repeat the shortName, since it's
already present in the directory path.

Also use just 'fs' instead of 'virtiofsd'.

https://bugzilla.redhat.com/show_bug.cgi?id=1816577Signed-off-by: NJán Tomko <jtomko@redhat.com>
Suggested-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Using the 'uuid' element for ppc64 NVDIMM memory added in the
previous patch, use it in qemuBuildMemoryDeviceStr() to pass
it over to QEMU.

Another ppc64 restriction is the necessity of a mem->labelsize,
given than ppc64 only support label-area backed NVDIMMs.

Finally, we don't want ppc64 NVDIMMs to align up due to the
high risk of going beyond the end of file with a 256MiB
increment that the user didn't predict. Align it down
instead. If target size is less than the minimum of
256MiB + labelsize, error out since QEMU will error out
if we attempt to round it up to the minimum.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

ppc64 NVDIMM support was implemented in QEMU by commit [1].
The support is similar to what x86 already does, aside from
an extra 'uuid' element.

This patch introduces a new optional 'uuid' element for the
NVDIMM memory model. This element behaves like the 'uuid'
element of the domain definition - if absent, we'll create
a new one, otherwise use the one provided by the XML.
The 'uuid' element is exclusive to pseries guests and are
unavailable for other architectures.

Next patch will use this new element to add NVDIMM support
for ppc64.

[1] https://github.com/qemu/qemu/commit/ee3a71e36654317b14ede0290e87628f8b79f850Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Update ppc64 capabilities to pick up the new NVDIMM capability
support for ppc64.

Since the ppc64 capabilities weren't updated for some time, the
bulk of the changes here are related to the blockdev support
(see commit c6a9e54c for info) that we are picking up just
now.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In previous patches virKeyFile was replaced with its GLib
counterpart which created an incompatible change: comments can
now begin only with a number sign (#). While this won't probably
affect anyone, mention it in the release notes.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The functionality is now provided by glib's GKeyFile.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Replace libvirt's virKeyFile by glib's GKeyFile.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This function changes the amount of time that libvirt waits for a
response from the guest agent for all guest agent commands. Since this
is a configuration change, it should not be allowed on read-only
connections.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The agent 'guest-sync' command historically had a 5s response timeout
which was different from other agent commands, which waited forever.
When we added the ability to customize the response timeout for guest
agent commands, we intended to continue to use 5s for 'guest-sync' when
the user specified a response timeout greater than 5s, and use the
user-specified timeout if it was below 5s. Unfortunately, when
attempting to determine whether the user-specified timeout was less than
5s, we were comparing against an enum value of
VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT (which is -1) rather than against
the actual time value that it represented (5).

This change makes it so that 'guest-sync' now uses the user-specified
tiemout if it is less than 5s.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Use existing function built for this exact purpose.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When a QEMU process dies in the middle of a hotplug, then we fail
to restore the seclabels on the device. The problem is that if
the thread doing hotplug locks the domain object first and thus
blocks the thread that wants to do qemuProcessStop(), the
seclabel cleanup code will see vm->pid still set and mount
namespace used and therefore try to enter the namespace
represented by the PID. But the PID is gone really and thus
entering will fail and no restore is done. What we can do is to
try enter the namespace (if requested to do so) but if entering
fails, fall back to no NS mode.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1814481Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

When running a function in a forked child, so far the only thing
we could report is exit status of the child and the error
message. However, it may be beneficial to the caller to know the
actual error that happened in the child.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

The @src is not always a file. It may also be a directory (for
instance qemuDomainCreateDeviceRecursive() assumes that) - even
though it doesn't happen usually. Anyway, mount() can mount only
a dir onto a dir and a file onto a file.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

The @devPath variable is not modifiable. It merely just points to
string containing path where private devtmpfs is being
constructed. Make it const so it doesn't look weird that it's not
freed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

If building namespace fails somewhere in the middle (that is some
files exists under devMountsSavePath[i]), then plain rmdir() is
not enough to remove dir. Umount the temp location and use
virFileDeleteTree() to remove the directory.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

The virFileMakePathWithMode() which is our recursive version of
mkdir() fails, it simply just returns a negative value with errno
set. No error is reported (as compared to virFileTouch() for
instance).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

Validate that we are able to parse back the dotted syntax arrays we were
generating in the pre-blockdev era.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

For the few instances where we'd generate an array in dotted syntax we
should be able to parse it back. Add another step in deflattening of the
dotted syntax which reconstructs the arrays so that the backing store
parser can parse it.

https://bugzilla.redhat.com/show_bug.cgi?id=1466177Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Extract the code so that there's a clean separation once we'll want do
do other steps.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Use automatic memory handling to remove the cleanup section.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

virBitmapNewEmpty can't fail now so we can make it obvious and fix all
callers.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

virStorageEncryptionSecretPtr may have a string inside it, thus we must
copy the string too. Use virSecretLookupDefCopy to do that.

Caused by non-obvious code introduced in 756b46dd and later 47e88b33
which added a string that needed to be copied.

https://bugzilla.redhat.com/show_bug.cgi?id=1814923Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The function always returns succes so there's no need for a return
value.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

qemuBlockStorageSourceGetFormatRawProps aggregated both formats but
since we now have props specific for either of those formats it's
unwanted to aggregate the code such way. Split out the 'luks' props
formatter into qemuBlockStorageSourceGetFormatLUKSProps.

The wrong separation demonstrates istself on formatting of the 'size'
and 'offset' attributes for the 'luks' driver which does not conform
to the qapi schema.

https://bugzilla.redhat.com/show_bug.cgi?id=1814975Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The 'luks' driver in qemu is as any other non-raw format driver and thus
doesn't support the properties for 'slice'. Since libvirt considers
luks files to be raw+encryption we need to special case them when
dealing with the slice.

https://bugzilla.redhat.com/show_bug.cgi?id=1814975Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Introduce qemuBlockStorageSourceNeedsStorageSliceLayer which will hold
the decision logic and fix all places that open-code it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since libvirt handles the luks encryption in a weird special way
(raw+encryption) we should really test that case with slices as well.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

A fixup to patch [1]. We need to reset await_event in all
error paths.

[1] 52532073 : qemu: remove redundant needReply argument of qemuAgentCommand
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In one of my previous commits I've introduced code that creates
all devices for given (possible) multipath target. But I've made
a mistake there - the code accesses 'next->path' without checking
if the disk source is local. Note that the 'next->path' is
NULL/doesn't make sense for VIR_STORAGE_TYPE_NVME.

Fixes: a30078cb
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1814947Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NSebastian Mitterle <smitterl@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NSebastian Mitterle <smitterl@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since the removal of gnulib, HAVE_SOCKETPAIR is no more defined, making
these two tests effectively skipped.

Use the same strategy used in other generic library bits, i.e. exclude
the socketpair usage on Windows.

Semi-related change in virnetdaemontest.c to make it build: since
virutil.h does not include unistd.h anymore, we need to include it.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>