This is pretty straightforward and self explanatory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1837990
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For the case where -fw_cfg uses a file, we need to set the
seclabels on it to allow QEMU the access. While QEMU allows
writing into the file (if specified on the command line), so far
we are enabling reading only and thus we can use read only label
(in case of SELinux).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This capability tracks whether QEMU supports -fw_cfg command line
option, more specifically whether it allows specifying filename.
There are some releases of QEMU which support -fw_cfg but not
filename. If this is ever a problem we can refine the capability
later on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are recommendations and limitations to the name of the
config blobs we need to follow [1].
We don't want users to change any value only add new blobs. This
means, that the name must have "opt/" prefix and at the same time
must not begin with "opt/ovmf" nor "opt/org.qemu" as these are
reserved for OVMF or QEMU respectively.
1: docs/specs/fw_cfg.txt from qemu.git
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has -fw_cfg which allows users to tweak how firmware
configures itself and/or provide new configuration blobs.
Introduce new <sysinfo/> type "fwcfg" that will hold these
new blobs.
It's possible to either specify new value as a string or
provide a filename which contents then serve as the value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Setting OEM strings for a domain was introduced in
v4.1.0-rc1~315. However, any application that wanted to use them
(e.g. to point to an URL where a config file is stored) had to
'dmidecode -u --oem-string N' (where N is index of the string).
Well, we can expose them under our <sysinfo/> XML and if the
domain is running Libvirt inside it can be obtained using
virConnectGetSysinfo() API.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since nobody sets custom dmidecode path anymore, we can drop all
code that exists only because of that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Problem with custom dmidecode scripts is that they are hard to
modify, especially if we will want them to act differently based
on passed arguments. So far, we have two scripts which do no more
than 'cat $sysinfo' where $sysinfo is saved dmidecode output.
The virCommandSetDryRun() can be used to trick
virSysinfoReadDMI() thinking it executed real dmidecode.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When trying to decode DMI table, just before constructing
virCommand() the decoder is looked for in PATH using
virFindFileInPath(). Well, this is not necessary because
virCommandRun() will do this too (in virExec()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Virtually every variable defined in the function can be freed
automatically when going out of scope.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Before QEMU introduced migratable CPU property, "-cpu host" included all
features that could be enabled on the host, even those which would block
migration. In other words, the default was equivalent to migratable=off.
When the migratable property was introduced, the default changed to
migratable=on. Let's record the default in domain XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The attribute is only allowed for host-passthrough CPUs and it can be
used to request only migratable or all supported features to be enabled
in the virtual CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There's no need to set ctxt->node outside of the function. The
function can set it itself - it has all the info needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
I think that since <qemu:commandline/> is kind of a hack, it
doesn't deserve place in the front row.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virStateInitialize() function has ATTRIBUTE_NONNULL()
referring to @root argument (incorrectly anyway) but in
daemonRunStateInit() NULL is passed in anyway.
Then there is virCommandAddArgPair() which also has
ATTRIBUTE_NONNULL() for one of its arguments and then checks the
argument for being NULL anyways.
Signed-off-by:Bihong Yu <yubihong@huawei.com>
Reviewed-by:Chuan Zheng <zhengchuan@huawei.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit b50a8354f6 added call to qemuDomainDiskBlockJobIsSupported prior
to filling the 'disk' variable resulting in a crash when attempting a
block commit.
https://gitlab.com/libvirt/libvirt/-/issues/31
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Juan Quintela noticed that when he restarted libvirt he was getting
extra iptables rules added by libvirt even though he didn't have any
libvirt networks that used iptables rules. It turns out this also
happens if the firewalld service is restarted. The extra rules are
just the private chains, and they're sometimes being added
unnecessarily because they are added separately in a global
networkPreReloadFirewallRules() that does the init if there are any
active networks, regardless of whether or not any of those networks
will actually add rules to the host firewall.
The fix is to change the check for "any active networks" to instead
check for "any active networks that add firewall rules".
(NB: although the timing seems suspicious, this isn't a new regression
caused by the recently pushed f5418b427 (which forces recreation of
private chains when firewalld is restarted); it was an existing bug
since iptables rules were first put into private chains, even after
commit c6cbe18771 delayed creation of the private chains. The
implication is that any downstream based on v5.1.0 or later that cares
about these extraneous (but harmless) private chains would want to
backport this patch (along with the other two if they aren't already
there))
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
If virDomainUpdateDeviceFlags() was used to update an <interface>, and
the interface type changed from type='network' where the network was
an unmanaged bridge (so actualType == bridge) to type='bridge'
(i.e. actualType *also* == bridge), the update would fail due to the
perceived change in type.
In practice it is okay to switch between any interface types that end
up using a tap device, since libvirt just needs to attach the device
to a new bridge. But in this case we were erroneously rejecting it due
to a conditional that was too restrictive. This is what the code was doing:
if (old->type != new->type)
[allow update]
else
if ((oldActual == bridge and newActual == network)
|| (oldActual == network and newActual == bridge)) {
[allow update]
else
[error]
In the case described above though, old->type and new->type don't match,
but oldActual and newActual are both 'bridge', so we get an error.
This patch changes the inner conditional so that any combination of
'network' and 'bridge' for oldActual and newActual, since they both
use a tap device connected to a bridge.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The previous fix accidentally picked up a debug change that put
alignment back at 4, not 8, bytes as it claimed:
commit 37ae042642
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Wed Jun 3 11:18:23 2020 +0100
conf: force 8 byte alignment for virObjectEvent
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We need to be able to cast from virObjectEventPtr to one of
its many subclasses. Some of these subclasses have 8 byte
alignment on 32-bit platforms, but virObjectEventPtr only
has 4 byte alignment.
Previously the virObject base class had 8 byte alignment
but this dropped to 4 byte when converted to inherit from
GObject. This introduces cast alignment warnings on 32-bit:
../../src/conf/domain_event.c: In function 'virDomainEventDispatchDefaultFunc':
../../src/conf/domain_event.c:1656:30: error: cast increases required alignment of target type [-Werror=cast-align]
1656 | rtcChangeEvent = (virDomainEventRTCChangePtr)event;
| ^
../../src/conf/domain_event.c:1785:34: error: cast increases required alignment of target type [-Werror=cast-align]
1785 | balloonChangeEvent = (virDomainEventBalloonChangePtr)event;
| ^
../../src/conf/domain_event.c:1896:35: error: cast increases required alignment of target type [-Werror=cast-align]
1896 | blockThresholdEvent = (virDomainEventBlockThresholdPtr)event;
| ^
../../src/conf/domain_event.c: In function 'virDomainQemuMonitorEventDispatchFunc':
../../src/conf/domain_event.c:1974:24: error: cast increases required alignment of target type [-Werror=cast-align]
1974 | qemuMonitorEvent = (virDomainQemuMonitorEventPtr)event;
| ^
../../src/conf/domain_event.c: In function 'virDomainQemuMonitorEventFilter':
../../src/conf/domain_event.c:2179:20: error: cast increases required alignment of target type [-Werror=cast-align]
2179 | monitorEvent = (virDomainQemuMonitorEventPtr) event;
| ^
Forcing 8-byte alignment on virObjectEventPtr removes the
alignment increase during casts to subclasses.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is convenience macro, use it more. This commit was generated
using the following spatch:
@@
symbol node;
identifier old;
identifier ctxt;
type xmlNodePtr;
@@
- xmlNodePtr old;
+ VIR_XPATH_NODE_AUTORESTORE(ctxt);
...
- old = ctxt->node;
... when != old
- ctxt->node = old;
@@
symbol node;
identifier old;
identifier ctxt;
type xmlNodePtr;
@@
- xmlNodePtr old = ctxt->node;
+ VIR_XPATH_NODE_AUTORESTORE(ctxt);
... when != old
- ctxt->node = old;
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts b897973f2e
Even though it may have been the case in the past, relative
XPaths don't overwrite the ctxt->node. Thus, there's no need to
save it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar to commits 55ce656463 and 6c17606b7c in the qemu driver, make
separate copies of persistent and live device config and normalize the MAC
address between the two. This avoids having different MAC address for the
persistent and live config, ensuring the device has the same address when
the persistent config takes affect after a VM restart.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Laine Stump <laine@redhat.com>
To avoid bugs with mixing of g_object_(ref|unref) vs
virObject(Ref|Unref), we want every virObject to be
a GObject.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Memory allocated using g_object_new must never be released using
VIR_FREE/g_free because g_object_new uses a special allocation
strategy internally.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ref count will be private to the GObject base class
and we must not peek at it, even for debugging messages.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
GObject has an arbitrary limit on the object struct size of 0xffff
bytes. It is expected that any large fields be separately allocated.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
To prepare for a conversion to GObject, we need virObjectUnref
to have the same API design as g_object_unref, which means it
needs to be void.
A few places do actually care about the return value though,
and in these cases a thread local flag is used to determine
if the dispose method was invoked.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Some, but not all, of the monitor event handlers check
the virObjectUnref return value to see if the domain
was disposed.
It should not be possible for this to happen, since
the function already holds a lock on the domain and
has only just acquired an extra reference on the
domain a few lines earlier.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Upon migration with disks, libvirt determines if each disk exists
on the destination and tries to pre-create missing ones. Well,
NVMe disks can't be pre-created, but they can be checked for
presence.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1823639
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to the context, here we are checking net->downscript's validity,
Signed-off-by: Liao Pingfang <liao.pingfang@zte.com.cn>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If built without attr support removing any image will trigger
qemuBlockRemoveImageMetadata (the one that emits the warning)
-> qemuSecurityMoveImageMetadata
-> virSecurityManagerMoveImageMetadata
-> virSecurityDACMoveImageMetadata
-> virSecurityDACMoveImageMetadataHelper
-> virProcessRunInFork (spawns subprocess)
-> virSecurityMoveRememberedLabel
In there due to !HAVE_LIBATTR virFileGetXAttrQuiet will return
ENOSYS and from there the chain will error out.
That is wrong and looks like:
libvirtd[6320]: internal error: child reported (status=125):
libvirtd[6320]: Unable to remove disk metadata on vm testguest from
/var/lib/uvtool/libvirt/images/testguest.qcow (disk target vda)
This change makes virSecurityDACMoveImageMetadataHelper and
virSecuritySELinuxMoveImageMetadataHelper accept that
error code gracefully and in that sense it is an extension of:
5214b2f1a3 "security: Don't skip label restore on file systems lacking XATTRs"
which does the same for other call chains into the virFile*XAttr functions.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Support downscript for booting vm,
and hotunplug interface device.
Signed-off-by: Chen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The stepping range (10-11) is likely incomplete. QEMU uses 10 and the
CPUID data for Cooperlake show 11. We will update the range if needed
once more details about he CPU are available.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit v3.10.0-182-g237f045d9a ("qemu: Ignore fallback CPU attribute
on reconnect") forced CPU 'fallback' to ALLOW, regardless of user
choice. This fixed a situation in which guests created with older
Libvirt versions, which used CPU mode 'host-model' in runtime, would
fail to launch in a newer Libvirt if the fallback was set to FORBID.
This would lead to a scenario where the CPU was translated to 'host-model'
to 'custom', but then the FORBID setting would make the translation
process fail.
PSeries can operate with 'host-model' in runtime due to specific PPC64
mechanics regarding compatibility mode. The update() implementation of
the cpuDriverPPC64 driver is a NO-OP if CPU mode is 'host-model', and
the driver does not implement translate(). The commit mentioned above
is causing PSeries guests to get their 'fallback' setting to ALLOW,
overwriting user choice, exposing a design problem in
qemuProcessRefreshCPU() - for PSeries guests, handling 'host-model'
as it is being done does not apply.
All other cpuArchDrivers implements update() and changes guest mode
to VIR_CPU_MODE_CUSTOM, meaning that PSeries is currently the only
exception to this logic. Let's make it official.
https://bugzilla.redhat.com/show_bug.cgi?id=1660711
Suggested-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200525123945.4049591-2-danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
