While we need to know the difference between the total memory stored in
<memory> and the actual size not included in the possible memory modules
we can't pre-calculate it reliably. This is due to the fact that
libvirt's XML is copied via formatting and parsing the XML and the
initial memory size can be reliably calculated only when certain
conditions are met due to backwards compatibility.
This patch removes the storage of 'initial_memory' and fixes the helpers
to recalculate the initial memory size all the time from the total
memory size. This conversion is possible when we also make sure that
memory hotplug accounts properly for the update of the total memory size
and thus the helpers for inserting and removing memory devices need to
be tweaked too.
This fixes a bug where a cold-plug and cold-remove of a memory device
would increase the size reported in <memory> in the XML by the size of
the memory device. This would happen as the persistent definition is
copied before attaching the device and this would lead to the loss of
data in 'initial_memory'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1344892
When converting domXML to xen xl.cfg, backendtype should
not be emitted if <driver> is not specified. Moreover,
<driver name='file'/> should be converted to backendtype
qdisk, similar to handling of <driver> in libxlMakeDisk()
in libxl_conf.c.
Prior to this change, connectDomainXMLToNative would
produce incorrect xl.cfg when the input domXML contained
<driver name='file'/>
domXML:
<disk type="file" device="disk">
<driver name="file"/>
<source file="/image/file/path"/>
<target dev="xvda" bus="xen"/>
</disk>
virsh domxml-to-native xen-xl domXML
disk = [ "format=raw,vdev=xvda,access=rw,backendtype=target=/image/file/path" ]
xl create xl.cfg
config parsing error in disk specification: unknown value
for backendtype: near `target=/image/file/path' in
`format=raw,vdev=xvda,access=rw,backendtype=target=/image/file/path'
Commit b3d069872c added peer address setting to the low level
virNetDevSetIPAddress() function, but ended up causing a segfault in
cases where the caller passed NULL for peer address.
Commit a3510e33d3 fixed the segfault, but managed to cause us to
skip setting the broadcast address when setting an interface's IP
address. The result is that the broadcast address is 0.0.0.0 for all
libvirt-created bridges (and interfaces in lxc containers with IP
addresses set by libvirt).
This was reported on the mailing list:
https://www.redhat.com/archives/libvir-list/2016-June/msg00027.html
but I was too busy to investigate at the time. I found it by accident
today while refactoring virNetDevSetIPAddress(). Since this regression
is present in the 1.3.5 release, I'm sending the bugfix as a separate
patch from my larger refactoring patchset.
Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).
This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.
Previously there was no way to have a Q35 domain that didn't have
these two controllers. This patch skips their creation as long as
there are some other kinds of pci controllers at index 1 and 2
(e.g. some pcie-root-port controllers).
I'm hoping that soon we won't add them at all, plugging all devices
into auto-added pcie-*-port ports instead, but in the meantime this
makes it easier to experiment with alternative bus hierarchies.
Implement storage pool event callbacks for START, STOP, DEFINE, UNDEFINED
and REFRESHED in functions when a storage pool is created/started/stopped
etc. accordingly
Storage pool lifecycle event API entry points for registering and deregistering
storage pool events, as well as types of events associated with storage pools.
These entry points will be used for implementing asynchronous lifecycle events.
Storage pool API:
virConnectStoragePoolEventRegisterAny
virConnectStoragePoolEventDeregisterAny
virStoragePoolEventLifecycleType which has events STARTED, STOPPED, DEFINED,
UNDEFINED, and REFRESHED
The other two DomainHasBlockJob usage error messages don't contain
'an', so unify things to save translators some effort. Dropping
the 'an' is closer to the sentence structure in the errors from
qemuDomainDiskBlockJobIsActive as well
In the auth config file, it is currently required to have
an entry for each hostname to connect to, eg
[auth-libvirt-prod1.example.com]
credentials=prod
This is inconvenient when there are large numbers of machines
all with the same credentials. Add support for a default
entry:
[auth-default]
credentials=prod
This function is plenty of ifdefs providing implementations for
Linux, *BSD and OS-X. However, if we are being build for any
other architecture, all that's left behind by preprocessor is
just a error reporting call and return of -1. In that case,
passed arguments are unused:
../../src/util/virhostcpu.c: In function 'virHostCPUGetInfo':
../../src/util/virhostcpu.c:966:33: error: unused parameter 'cpus' [-Werror=unused-parameter]
unsigned int *cpus,
^~~~
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Support hot attach/detach a USB host device to guest.
Currently libxl only supports xen PV guest, and only
supports specifying USB host device by 'bus number'
and 'device number', for example:
usb.xml:
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<address bus='1' device='3'/>
</source>
</hostdev>
#xl attach-device dom usb.xml
#xl detach-device dom usb.xml
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Support creating guest with USB host device in config file.
Currently libxl only supports xen PV guest, and only supports
specifying USB host device by 'bus number' and 'device number',
for example:
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<address bus='1' device='3'/>
</source>
</hostdev>
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
If the domain is not running, but for example the CPUs are stopped, the
ACPI event gets queued and resume of the domain will just shut it off.
https://bugzilla.redhat.com/show_bug.cgi?id=1216281
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since obtaining a job can wait for another job to finish, the state
might change in the meantime. And checking it more than once is
pointless.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This bumps the release number of 2.0.0, to reflect the switch to
a new time based release versioning scheme. The downloads page
is updated to describe our policies for release schedules and
release version numbering
The stable release docs are changed to reflect the fact that
the stable version numbers are now just 3 digits long instead
of 4.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This option allows or disallows detection of zero-writes if it is set to
"on" or "off", respectively. It can be also set to "unmap" in which
case it will try discarding that part of image based on the value of the
"discard" option.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Populate libxl_domain_build_info struct with bios and firmware
info from virDomainLoaderDef.
Note: Currently libxl only allows specifying the type of BIOS.
For type LIBXL_BIOS_TYPE_OVMF, the firmware path is configured
when building Xen using '--with-system-ovmf='. If not specified,
LIBXL_FIRMWARE_DIR/ovmf.bin is used. In the future, Xen will
support a user-specified firmware path. See
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01628.html
Once that work is merged into xen.git, the libvirt libxl driver
will be able to honor a user-specified path. In the meantime use
the implicit path, which is tolerable since it is advertised in
domcapabilities.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Add support to xenconfig for conversion of xl.cfg(5) bios config
to/from libvirt domXml <loader> config. SeaBIOS is the default
for HVM guests using upstream QEMU. ROMBIOS is the default when
using the old qemu-dm. This patch allows specifying OVMF as an
alternate firmware.
Example xl.cfg:
bios = "ovmf"
Example domXML:
<os>
...
<loader readonly='yes' type='pflash'>/usr/lib/xen/boot/ovmf.bin</loader>
</os>
Note that currently Xen does not support a separate nvram for
non-volatile variables.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Prefer firmwares specified via --with-loader-nvram configure
option. If none are specified, use the Xen-provided default
firmwares found in LIBXL_FIRMWARE_DIR.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.
To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
In libxl driver we do virObjectRef in libxlDomainObjBeginJob,
If virCondWaitUntil failed, it goes to error, do virObjectUnref,
There's a chance that someone undefine the vm at the same time,
and refs unref to zero, vm is freed in libxlDomainObjBeginJob.
But the vm outside function is not Null, we do virObjectUnlock(vm).
That's how we overwrite the vm memory after it's freed. I fix it.
Signed-off-by: Wang Yufei <james.wangyufei@huawei.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
* Fix misspelt function name:
s/virHostCPUGetStatsFreebsd/virHostCPUGetStatsFreeBSD/
* Mark the first argument to virHostCPUGetInfo with ATTRIBUTE_UNUSED
as it's not actually used on non-Linux
SYSFS_SYSTEM_PATH is only defined for Linux, however it's used outside
of #ifdef __linux__ code, e.g. as the first argument to
nodeCapsInitNUMAFake().
But as this argument's value is used on Linux only, it's safe to define
SYSFS_SYSTEM_PATH to "fake" to get things built on FreeBSD.
As it turned out PrlVmDev_GetStackIndex can return negative values
without reporting an error, which is incorrect but nevertheless.
After that we feed this negative index to virIndexToDiskName,
which in turn returns NULL and we set it to virDomainDiskDef.dst.
Using virDiskNameToBusDeviceIndex with a virDomainDiskDef structure
which has NULL dst field crashes.
Fix this by returning an error in prlsdkGetDiskId in such cases.
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
The approach of subscribing on first stat API call and then waiting
for receiving of performance event from sdk to process the call originates
in times when every vz libvirt connections spawns its own sdk connection.
Thus without this waiting virsh stat call would return empty stats. Now
with single sdk connection this scheme is unnecessary complicated.
This patch subscribes to performance events on first domain appearence
and unsubscribe on its removing.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
../../src/conf/domain_conf.c:10949: error: declaration of 'socket'
shadows a global declaration [-Wshadow]
../../src/conf/domain_conf.c:24373: error: declaration of 'listen'
shadows a global declaration [-Wshadow]
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1298070
We have the code for attaching redirdevs for ages now.
Unfortunately, our monitor code that handles talking to the qemu
process was missing a little piece of code that actually enabled
the feature.
BTW: it really is called "type" on the monitor, even though it's
called "name" on the cmd line. Don't ask.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In the 162efa1a commit the function was introduced, but the
commit forgot to update livirt_private.syms accordingly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add the virDomainLxcEnterCGroup API to the libvirt-lxc.so
file. This method moves the calling process into the cgroups
associated with the container.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Move all APIs with a virHostMEM name prefix out into new
util/virhostmem.h & util/virhostmem.c files
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Move all APIs with a virHostCPU name prefix out into new
util/virhostcpu.h & util/virhostcpu.c files
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In preparation for moving all the CPU related APIs out of
the nodeinfo file, give them a virHostCPU name prefix.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In preparation for moving all the memory related APIs out of
the nodeinfo file, give them a virHostMem name prefix.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Instead of having platform specific code in nodeGetInfo to
fetch CPU topology, split it all out into a new method
nodeGetCPUInfo.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The GNULIB physmem module already provides support for
the FreeBSD platform, so there's no reason to re-implement
FreeBSD portability code in libvirt. If there are bugs in
the GNULIB code, we should fix GNULIB rather than workaround
it in libvirt.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The nodeGetInfo() method currently has its own code for getting
memory size in KB, that basically just re-invents what nodeGetMemory
already does. Remove it and just call nodeGetMemory, converting its
result from bytes to KB, allowing removal of more platform specific
conditional code.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Nearly all the methods in the nodeinfo file are given a
'const char *sysfs_prefix' parameter to override the
default sysfs path (/sys/devices/system). Every single
caller passes in NULL for this, except one use in the
unit tests. Furthermore this parameter is totally
Linux-specific, when the APIs are intended to be cross
platform portable.
This removes the sysfs_prefix parameter and instead gives
a new method linuxNodeInfoSetSysFSSystemPath for use by
the test suite.
For two of the methods this hardcodes use of the constant
SYSFS_SYSTEM_PATH, since the test suite does not need to
override the path for thos methods.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If you want to set block device I/O tuning values that end with '_max'
and there is nothing else set, libvirt emits an error. In particular:
error: internal error: Unexpected error
That's an unknown error. That is because *_max values depend on their
respective non-_max values. QEMU even says that in the error message
sent as a response to the monitor command:
"error": {"class": "GenericError", "desc": "bps_max/iops_max require
corresponding bps/iops values"}
the problem was that we didn't know that and there was no check for it.
Adding such check makes sure that there will be less confused users.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This new listen type is currently supported only by spice graphics.
It's introduced to make it easier and clearer specify to not listen
anywhere in order to start a guest with OpenGL support.
The old way to do this was set spice graphics autoport='no' and don't
specify any ports. The new way is to use <listen type='none'/>. In
order to be able to migrate to old libvirt the migratable XML will be
generated without the listen element and with autoport='no'. Also the
old configuration will be automatically converted to the this listen
type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
VNC graphics already supports sockets but only via 'socket' attribute.
This patch coverts that attribute into listen type 'socket'.
For backward compatibility we need to handle listen type 'socket' and 'socket'
attribute properly to support old XMLs and new XMLs. If both are provided they
have to match, if only one of them is provided we need to be able to parse that
configuration too.
To not break migration back to old libvirt if the socket is provided by user we
need to generate migratable XML without the listen element and use only 'socket'
attribute.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This moves the socket generation if "vnc_auto_unix_socket" is set.
It also fixes a bug with this config option that we should auto-generate
socket path only if listen type is address and there is no address
specified.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Even though it's auto-generated it's based on qemu.conf option and listen type
address already uses "fromConfig" to carry this information. Following commits
will convert the socket to listen element so this rename is required because
there will be also an option to get socket auto-generated independently on the
qemu.conf option.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Since commit 7140807917, qemu agent
channel cannot be plugged in because we won't generate its path
automatically. Let's not only fix that, but also add tests for it so
next time it's checked for.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1322210
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Put it into separate function called qemuDomainPrepareChannel() and call
it from the new qemuProcessPrepareDomain().
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
As a side effect this changes the order of CPU features in XMLs
generated by libvirt, but that's not a big deal since the order there is
insignificant.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
For two reasons:
- 0x00000001 is very similar to 0x80000001, but 0x01 is visually
different
- 0x01 format is consistent with CPUID manual
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. This patch prepares the x86 CPU
driver code for the new 'ecx_in' CPUID parameter.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The internal features are only used in explicit checks with
cpuHasFeature. Loading them into the CPU map is dangerous since the
features may accidentally be reported to users when decoding CPUID data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virCPUData and struct ppc64_model structures contained a pointer to
virCPUppc64Data, which was not very nice since the real data were
accessible by yet another level of pointers from virCPUppc64Data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virCPUData, virCPUx86Feature, and virCPUx86Model all contained a pointer
to virCPUx86Data, which was not very nice since the real CPUID data were
accessible by yet another pointer from virCPUx86Data. Moreover, using
virCPUx86Data directly will make static definitions of internal CPU
features a bit easier.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This patch splits qemuMonitorJSONGetCPUx86Data in three functions:
- qemuMonitorJSONCheckCPUx86 checks if QEMU supports reporting CPUID
features for a guest CPU
- qemuMonitorJSONParseCPUx86Features parses CPUID features from a JSON
array
- qemuMonitorJSONGetCPUx86Data gets the requested guest CPU property
from QOM and uses qemuMonitorJSONParseCPUx86Features to parse it
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. Let's rename 'function' to
'eax_in' in preparation for adding 'ecx_in'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
A CPU data XML file already contains the architecture, let the parser
use it to detect which CPU driver should be used to parse the rest of
the file.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When computing CPU data for a given guest CPU we should set CPUID vendor
bits appropriately so that we don't lose the vendor when transforming
CPU data back to XML description.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
A few functions using virDomainLiveConfigHelperMethod use the generic
name 'vmdef' to point to the persistent definition.
Use persistentDef and/or persistentDefCopy to make its purpose obvious.
Support reading the TLS priority from the client configuration
file via the "tls_priority" config option, eg
$ cat $HOME/.config/libvirt/libvirt.conf
tls_priority="NORMAL:-VERS-SSL3.0"
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virConnectOpenInternal method opens the libvirt client
config file and uses it to resolve things like URI aliases.
There may be driver specific things that are useful to
store in the config file too, so rather than have them
re-parse the same file, pass the virConfPtr down to the
drivers.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add support for a "tls_priority" URI parameter in remote
driver URIs. eg
qemu+tls://localhost/session?tls_priority=NORMAL:-VERS-SSL3.0
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Extend the virNetTLSContextNew* constructors to allow
the TLS priority string to be passed in, overriding the
compile time default.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently libvirt calls gnutls_set_default_priority()
which on old systems resolves to "NORMAL" while new
systems it resolves to "@SYSTEM". Either way, this
is a global default that is identical across all apps.
We want to allow distros to flexibility to define a
custom default string for libvirt priority, so add
a --tls-priority=STRING flag to configure to enable
this to be set.
It is expected that distros would use this when creating
RPM/Deb/etc packages, according to their preferred crypto
handling policies.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently we set the gnutls log function when creating a
TLS context, however, the setting is in fact global, not
per context. So we should be setting it when we first call
gnutls_global_init() instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We need to use the gnutls_priority_set_direct method which
was not introduced until 2.1.7, so bump version to 2.2.0
which is the first stable release with it included. This
release dates from Dec 2007 so it is reasonable to ditch
support for the 1.x.x series for gnutls releases entirely.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In commit 1e38ef72 the disk startup policy check was moved prior to the
call to virDomainObjSetDefTransient which dropped the disk from the
config rather than the def to be started which is a bug.
Additionally we'd not report the disk change event for this since the
disk aliases were not set at that point.
Finally 'volume' based disks would not work with startup policy too.
Fix it by moving it back after the definition is copied, aliases are
assigned and disk sources are translated.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1341415
qemuProcessStart does not unset the infrastructure that retrieves errors
from the qemu log file in case of migration. As this wasn't handled
properly in qemuDomainSaveImageStartVM we kept the logging context/fd
open for the lifetime of the VM rather than closing it after it's not
needed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325080
tap2 only handles 'aio', but not 'raw', which must be explicitly given:
| $ virsh domxml-to-native yyy.xml > yyy.xm
| $ xm new yyy.xm
| Error: tap:/srv/xen/xxx.img not a valid disk type
| $ sed -i -e 's/tap2:/&aio:/' yyy.xm
| $ xm new yyy.xm
Fix reading and writing "xen-xm" format for "tap2" by handling it the
same as "tap".
Use qemuDomainLogAppendMessage rather than attempting to open a new
logging context with file descriptors. The new approach allows to log
the message even if qemu is still running at that point which appens
during migration finish phase where qemuProcessStop is killing qemu.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1312188
Along with the virtlogd addition of the log file appending API implement
a helper for logging one-shot entries to the log file including the
fallback approach of using direct file access.
This will be used for noting the shutdown of the qemu proces and
possibly other actions such as VM migration and other critical VM
lifecycle events.
For logging one-shot entries to the VM log file it's quite a waste to
hold open the file descriptor for logging that is provided by the
current API.
This new API will be ideal for logging one-shot entries to the file
e.g. at the point when we shut the VM down rather than having to add the
whole file-descriptor infrastructure.
Additionally this will allow to add the messages even after restart of
libvirtd since virtlogd doesn't allow to obtain a regular context with
filedescriptors while the VM is still active.
Since it will not be called from outside of conf we can unexport it too
if we move it to the appropriate place.
Test suite change is necessary since the error will be reported sooner
now.
Validation of qemu process startup requires to know whether the process
is used for a fresh VM or whether it's reloaded from a
snapshot/migration. Pass this information in via a flag rather than
calculating it from a bunch of bools.
Similarly to the domain definition validator add a device validator. The
change to the prototype of the domain validator is necessary as
virDomainDeviceInfoIterateInternal requires a non-const pointer.
Until now we weren't able to add checks that would reject configuration
once accepted by the parser. This patch adds a new callback and
infrastructure to add such checks. In this patch all the places where
rejecting a now-invalid configuration wouldn't be a good idea are marked
with a new parser flag.
Historically, we added heads=1 to videos, but for example for qxl, we
did not reflect that on the command line.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283207
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Use udevHasDeviceProperty instead of udevGetStringProperty.
We do not need to copy the string since we do not need it.
Also add braces around the if body, since the change made
syntax check complain.
Two out of three callers free it right after converting it to a number.
Also change the comment at the beginning of the function, because
the comment inside the function told me to.
The wrapper adds an error message or a debug log.
Since we already log the properties we get from udev as strings,
there is no much use for the debug logs.
Open code the error message and delete the function.
Most of the code paths had to reset it to -1 and returning 0 was
only possible if we made it to the end of the function.
Initialize it to -1 and only set it to 0 if we reach the end, as we do
in most of libvirt code.
The sd_notify method is used to tell systemd when libvirtd
has finished starting up. All it does is send a datagram
containing the string parameter to systemd on a UNIX socket
named in the NOTIFY_SOCKET environment variable. Rather than
pulling in the systemd libraries for this, just code the
notification directly in libvirt as this is a stable ABI
from systemd's POV which explicitly allows independant
implementations:
See "Reimplementable Independently" column in the
"$NOTIFY_SOCKET Daemon Notifications" row:
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1314881
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Move the module from qemu_command.c to a new module virqemu.c and
rename the API to virQEMUBuildObjectCommandline.
This API will then be shareable with qemu-img and the need to build
a security object for luks support.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Split out a helper from virStorageBackendCreateQemuImgCmdFromVol
to check the encryption - soon a new encryption sheriff will be
patroling and that'll mean all sorts of new checks.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Remove the live attribute and mark the definition as transient
whether the domain is runing or not.
There were only two callers left calling with live=false:
* testDomainStartState, where the domain already is active
because we assigned vm->def->id just a few lines above the call
* virDomainObjGetPersistentDef, which now only calls
virDomainObjSetDefTransient for an active domain
Calling virDomainObjSetDefTransient with live=false is a no-op
on an inactive domain.
Only call it on an active domain, since this is the only place using
the live bool.
Commit 45ec297d from November 2010:
Make state driver device hotplug/update actually transient
added virDomainObjSetDefTransient calls to the domain startup
function in several drivers.
In November 2011, commit 8866eed:
Set aliases for LXC/UML console devices
added a call earlier in the startup function, without removing the
existing ones.
Also, in the UML driver it seems the function never did anything
useful - vm->def->id is set asynchronnously in umlNotifyEvent.
At the time of calling virDomainObjSetDefTransient with live=false,
vm->def->id was likely still -1, making the call a no-op.
When building using -Og, gcc sees that some variables can be used
uninitialized It can be debatable whether it is possible with our
codeflow, but functions should be self-contained and initializations are
always good. The return instead of goto is due to actualType being used
in the cleanup.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
So imagine the following. You connect read only to a daemon and
try to fetch stats for a shut off domain, e.g.:
virsh -r domstats $dom
but all of a sudden, virsh instead of printing the stats throws
the following error at you:
error: Disconnected from qemu:///system due to I/O error
error: End of file while reading data: Input/output error
The daemon crashed. This is its backtrace:
#0 0x00007fa43e3751a8 in virPerfEventIsEnabled (perf=0x0, type=VIR_PERF_EVENT_MBMT) at util/virperf.c:241
#1 0x00007fa424a9f042 in qemuDomainGetStatsPerf (driver=0x7fa3f4022a30, dom=0x7fa3f40e24c0, record=0x7fa41c000e20, maxparams=0x7fa4360b38d0, privflags=1) at qemu/qemu_driver.c:19110
#2 0x00007fa424a9f2e7 in qemuDomainGetStats (conn=0x7fa41c001b20, dom=0x7fa3f40e24c0, stats=127, record=0x7fa4360b3970, flags=1) at qemu/qemu_driver.c:19213
#3 0x00007fa424a9f672 in qemuConnectGetAllDomainStats (conn=0x7fa41c001b20, doms=0x7fa41c0017f0, ndoms=1, stats=127, retStats=0x7fa4360b3a50, flags=0) at qemu/qemu_driver.c:19303
#4 0x00007fa43e4e15f6 in virDomainListGetStats (doms=0x7fa41c0017f0, stats=0, retStats=0x7fa4360b3a50, flags=0) at libvirt-domain.c:11615
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f28d1a38700 (LWP 16154)]
0x00007f28da4fa1a8 in virPerfEventIsEnabled (perf=0x0, type=VIR_PERF_EVENT_MBMT) at util/virperf.c:241
241 return event->enabled;
Problem is, shut off domains don't have priv->perf allocated.
Therefore if in frame #1 qemuDomainGetStatsPerf() tries to check
if perf events are enabled, NULL is passed to
virPerfEventIsEnabled() which due to some incredible
implementation dereference it. Fix this by checking whether
passed object is not NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function is not used anywhere. Moreover, the code that would
use lives in virperf.c and therefore has access to the FD anyway.
Well, for instance virPerfReadEvent is doing just that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
There's this problem on the recent gcc-6.1:
In file included from conf/domain_conf.c:37:0:
conf/domain_conf.c: In function 'virDomainChrPreAlloc':
conf/domain_conf.c:14109:35: error: potential null pointer dereference [-Werror=null-dereference]
return VIR_REALLOC_N(*arrPtr, *cntPtr + 1);
^~
./util/viralloc.h:158:73: note: in definition of macro 'VIR_REALLOC_N'
# define VIR_REALLOC_N(ptr, count) virReallocN(&(ptr), sizeof(*(ptr)), (count), \
^~~~~
conf/domain_conf.c: In function 'virDomainChrRemove':
conf/domain_conf.c:14133:21: error: potential null pointer dereference [-Werror=null-dereference]
for (i = 0; i < *cntPtr; i++) {
^~~~~~~
GCC basically fails to see, that the
virDomainChrGetDomainPtrsInternal will never actually return NULL
because it's never called over a domain char device with _LAST
type. But to make it shut up, lets turn this function into
returning an integer and check in the callers if a zero value
value was returned.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Okay, I admit that our code here is complex. It's not easy to
spot that NULL deref can't really happen here. So it's no wonder
that a dumb compiler fails to see all the connections and
produces the following errors:
CC conf/libvirt_conf_la-domain_conf.lo
conf/domain_conf.c: In function 'virDomainDefFormatInternal':
conf/domain_conf.c:22162:22: error: potential null pointer dereference [-Werror=null-dereference]
if (sched->policy == i)
~~~~~^~~~~~~~
<snip/>
cc1: all warnings being treated as errors
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
cpu/cpu_ppc64.c: In function 'ppc64Compute':
cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference [-Werror=null-dereference]
if (STRNEQ(guest_model->name, host_model->name)) {
~~~~~~~~~~~^~~
cpu/cpu_ppc64.c:620:9: note: in expansion of macro 'STRNEQ'
if (STRNEQ(guest_model->name, host_model->name)) {
^~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
