Since we already have a function that will generate the drivestr from
the alias, let's use it and remove the qemuDeviceDriveHostAlias.
Move the QEMU_DRIVE_HOST_PREFIX definition into qemu_alias.h
Also alter qemuAliasFromDisk to use the QEMU_DRIVE_HOST_PREFIX instead
of "drive-%s".
Rather than pass the disks[i]->info.alias to qemuMonitorSetDrivePassphrase
and then generate the "drive-%s" alias from that, let's use qemuAliasFromDisk
prior to the call to generate the drive alias and then pass that along
thus removing the need to generate the alias from the monitor code.
Node device lifecycle event API entry points for registering and
deregistering node deivce events, as well as types of events
associated with node device.
These entry points will be used for implementing asynchronous
lifecycle events.
Node device API:
virConnectNodeDeviceEventRegisterAny
virConnectNodeDeviceEventDeregisterAny
virNodeDeviceEventLifecycleType which has events CREATED and DELETED
As commit id 'e2b86f580' notes, when mode=agent possibly setting the
fake reboot flag to true wouldn't be necessary; however, it doesn't
"force" the issue by just ensuring the fake reboot is false, so this
patch adds the explicit setting for the reboot path.
More investigation and details can be found in commit id '8be502fd'
as well as in the archives at:
https://www.redhat.com/archives/libvir-list/2015-April/msg00715.html
Conditional setting of the fake reboot flag should only happen for
the acpi mode shutdown path; however, for the agent mode shutdown,
the fake reboot should be cleared. This patch will essentially revert
commit id '8be502fd', but adds an explicit setting of the flag to false
when using mode=agent while also only conditionally setting the reboot
flag if the guest went away. This also avoids an issue where a shutdown
with reboot semantics is done from agent mode which sets the reboot
flag followed by a shutdown from within the guest which would result
in a reboot due to the fake reboot flag being set. The change will
also properly handle the cases described in the following archive post:
https://www.redhat.com/archives/libvir-list/2015-April/msg00715.html
Commit id '44304c6eb' added the API libxlDomainAttachControllerDevice
inside a conditional LIBXL_HAVE_PVUSB, but called that function outside
the conditional in libxlDomainAttachDeviceLive.
Similarly, the API libxlDomainDetachControllerDevice was added inside a
conditional LIBXL_HAVE_PVUSB, but called outside the conditional in
libxlDomainDetachDeviceLive.
This patch adds the conditional LIBXL_HAVE_PVUSB around those two calls
from within the switch.
Prior to commit 2737aaaf, we allowed every client to connect successfully,
however, if accepting a client would eventually lead to an overcommit of the
limits, we would disconnect it immediately with "Too many active clients,
dropping connection from...". Recent changes refactored the code in a way, that
it is not possible for the client-related callback to be dispatched and the
client to be accepted if the limits wouldn't permit to do so, therefore a check
if a connection should be dropped due to limits violation has become a dead
code that could be removed.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit 2737aaaf changed our policy for accepting new clients in a way, that
instead of accepting new clients only to disconnect them immediately, since
that would overcommit the limit, we temporarily disable polling for the
dedicated file descriptor, so any new connection will queue on the socket.
Commit 8b1f0469 then added the possibility to change the limits during runtime
but it didn't re-enable polling for the previously disabled file descriptor,
thus any new connection would still continue to queue on the socket. This patch
forces an update of the services each time the limits were changed in some way.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1357776
Signed-off-by: Erik Skultety <eskultet@redhat.com>
So far, virNetServerCheckLimits was only used to possibly re-enable accepting
new clients that might have previously been disabled due to client limits
violation (max_clients, max_anonymous_clients). This patch refactors
virNetServerAddClient, which is currently the only place where the services get
disabled, in order to use the virNetServerCheckLimits helper instead of
checking the limits by itself.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Since virNetServerAddClient checks for the limits in order to temporarily
suspend the services, thus not accepting any more clients, there is no reason
why virNetServerCheckLimits, which is only responsible for re-enabling
previously disabled services according to the limits, could not do both. To be
able to do that however, it needs to be moved up in the file since it's static
(and because it's just a helper and there's only one caller it should remain
static).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In case of error, libxlReconnectDomain may call
virDomainObjListRemoveLocked. However it has no local reference on
the domain object, leading to segfault. Get a reference to the domain
object at the start of the function and release it at the end to avoid
problems.
This commit also factorizes code between the error and normal ends.
To sync with virDomainControllerModelUSB, we add two models
in qemuControllerModelUSB 'qusb1' and 'qusb2', but those
models are not supported in qemu driver. So add check in
device post parse to report errors if 'qusb1' and 'qusb2'
are specified.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
libxl configuration files conversion can now handle USB controllers.
When parting libxl config file, USB controllers with type PV are
ignored as those aren't handled.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
When hotplugging a USB device, check if there is an available controller
and port, if not, automatically create a USB controller of version
2.0 and 8 ports.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Support USB controller hot-plug and hot-unplug.
#virsh attach-device dom usbctrl.xml
#virsh detach-device dom usbctrl.xml
usbctrl.xml example:
<controller type='usb' index='0' model='qusb2'>
Signed-off-by: Chunyan Liu <cyliu@suse.com>
To support USB Controller in xen guest domains, just add
USB controller in domain config xml as following:
<controller type='usb' model='qusb2' ports='4'/>
Signed-off-by: Chunyan Liu <cyliu@suse.com>
According to libxl implementation, it supports pvusb
controller of version 1.1 and version 2.0, and it
supports two types of backend, 'pvusb' (dom0 backend)
and 'qusb' (qemu backend). But currently pvusb backend
is not checked in yet.
To match libxl support, extend usb controller schema
to support two more models: qusb1 (qusb, version 1.1)
and 'qusb2' (qusb version 2.0).
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Let's cleanly differentiate what wiping a volume does for ploop and
other volumes so it's more readable what is done for each one instead of
branching out multiple times in different parts of the same function.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Some functions use volume specification merely to use the target path
from it. Let's change it to pass the path only so that it can be used
for other files than just volumes.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This is done in order to call them in next patches from each other and
definitions would be missing otherwise.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
When reset was called from a domain that crashed we didn't change the
crashed state into a paused one which could confuse users.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1269575
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Until now we simply errored out when the translation from pool+volume
failed. However, we should instead check whether that disk is needed or
not since there is an option for that.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1168453
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
There is an error reset following the function and check for
startupPolicy before that. Let's reflect those things inside that
function so that future code doesn't have to be that complex.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
When wiping a volume we just rewrite all the data of the volume, not
only the content. Since format gets overridden, we need to recreate the
volume. However we can't do that for every possible format out there.
Since it was only coded for the ploop volume type, let's document what
might be the consequences instead of forbidding it for every other
format out there.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868771
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The panic devices with models s390 and pseries are autogenerated.
For backwards compatibility reasons the devices are to be removed
when migrating.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Ever since virDomainCreateWithFlags() was introduced by de3aadaa
[drivers: add virDomainCreateWithFlags if virDomainCreate exists], the
domain ID retrieved with virDomainGetID() was incorrect for several
drivers after virDomainCreateWithFlags() was called. The API consumer
had to look up the domain anew to retrieve the correct ID.
For the ESX driver, this was fixed in 6139b274 [esx: Update ID after
starting a domain]. For the openvz driver, it was fixed in fd81a097
[openvzDomainCreateWithFlags: set domain id to the correct value]. The
test driver, the OpenNebula driver (removed in the meantime) and the
vbox driver were already updating the domain ID correctly in
domainCreate().
Copy over the ID in qemuDomainCreateWithFlags() to fix this for the qemu
driver, too.
Fixes: de3aadaa ("drivers: add virDomainCreateWithFlags if virDomainCreate exists")
Reported-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Tested-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Consider the following XML snippet:
<memory model=''>
<target>
<size unit='KiB'>523264</size>
<node>0</node>
</target>
</memory>
Whats wrong you ask? The @model attribute. This should result in
an error thrown into users faces during virDomainDefine phase.
Except it doesn't. The XML validation catches this error, but if
users chose to ignore that, they will end up with invalid XML.
Well, they won't be able to start the machine - that's when error
is produced currently. But it would be nice if we could catch the
error like this earlier.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The original name 'admin_uri_default' was introduced to our code by commit
dbecb87f. However, at that time we already had a separate config file for
admin library but the commit mentioned above didn't properly adjust the
config's option name. The result is that when we're loading the config, we
check a non-existent config option (there's not much to do with the URIs
anyway, since we only allow local connection). Additionally, virt-admin's man
page documents, that the default URI can be altered by setting
admin_uri_default option. So the fix proposed by this patch leaves the
libvirt-admin.conf as is and adjusts the naming in the code as well as in the
virt-admin's man page.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1356436
Commit id '56057900' altered the discovery of iSCSI node targets by
using the "--op nonpersistent". This caused issues for clean environments
or if by chance a "-m node -o delete" was executed.
Since each iSCSI Storage Pool has the required iSCSI target path, use
that and the virISCSINodeNew API in order to generate the iSCSI node record.
https://bugzilla.redhat.com/show_bug.cgi?id=1356436
According to RFC 3721 (https://www.ietf.org/rfc/rfc3721.txt), there are
two ways to "discover" targets in/for the iSCSI environment. Discovery
is the process which allows the initiator to find the targets to which
it has access and at least one address at which each target may be
accessed.
The method currently implemented in libvirt using the virISCSIScanTargets
API is known as "SendTargets" discovery. This method is more useful when
the target IP Address and TCP port information are available, e.g. in
libvirt terms the "portal". It returns a list of targets for the portal.
From that list, the target can be found. This operation can also fill an
iSCSI node table into which iSCSI logins may occur. Commit id '56057900'
altered that filling by adding the "--op nonpersistent" since it was
not necessarily desired to perform that for non libvirt related targets.
The second method is "Static Configuration". This method not only needs
the IP Address and TCP port (e.g. portal), but also the iSCSI target name.
In libvirt terms this would be the device path field from the iSCSI pool
<source> XML. This patch implements the second methodology using that
required device path as the targetname.
The current LUKS support has a "luks" volume type which has
a "luks" encryption format.
This partially makes sense if you consider the QEMU shorthand
syntax only requires you to specify a format=luks, and it'll
automagically uses "raw" as the next level driver. QEMU will
however let you override the "raw" with any other driver it
supports (vmdk, qcow, rbd, iscsi, etc, etc)
IOW the intention though is that the "luks" encryption format
is applied to all disk formats (whether raw, qcow2, rbd, gluster
or whatever). As such it doesn't make much sense for libvirt
to say the volume type is "luks" - we should be saying that it
is a "raw" file, but with "luks" encryption applied.
IOW, when creating a storage volume we should use this XML
<volume>
<name>demo.raw</name>
<capacity>5368709120</capacity>
<target>
<format type='raw'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</target>
</volume>
and when configuring a guest disk we should use
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/home/berrange/VirtualMachines/demo.raw'/>
<target dev='sda' bus='scsi'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</disk>
This commit thus removes the "luks" storage volume type added
in
commit 318ebb36f1
Author: John Ferlan <jferlan@redhat.com>
Date: Tue Jun 21 12:59:54 2016 -0400
util: Add 'luks' to the FileTypeInfo
The storage file probing code is modified so that it can probe
the actual encryption formats explicitly, rather than merely
probing existance of encryption and letting the storage driver
guess the format.
The rest of the code is then adapted to deal with
VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS
instead of just VIR_STORAGE_FILE_LUKS.
The commit mentioned above was included in libvirt v2.0.0.
So when querying volume XML this will be a change in behaviour
vs the 2.0.0 release - it'll report 'raw' instead of 'luks'
for the volume format, but still report 'luks' for encryption
format. I think this change is OK because the storage driver
did not include any support for creating volumes, nor starting
guets with luks volumes in v2.0.0 - that only since then.
Clearly if we change this we must do it before v2.1.0 though.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Refactor the virStorageFileMatchesNNN methods so that
they don't take a struct FileFormatInfo parameter, but
instead get the actual raw dat items they needs. This
will facilitate reuse in other contexts.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
To collect all balloon statistics for all guests it was necessary to make
several libvirt requests. Now it's possible to get all balloon statiscs via
single connectGetAllDomainStats call.
Signed-off-by: Derbyshev Dmitry <dderbyshev@virtuozzo.com>
To allow using failover with gluster it's necessary to specify multiple
volume hosts. Add support for starting qemu with such configurations.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
To allow richer definitions of disk sources add infrastructure that will
allow to register functionst generating a JSON object based definition.
This infrastructure will then convert the definition to the proper
command line syntax and use it in cases where it's necessary. This will
allow to keep legacy definitions for back-compat when possible and use
the new definitions for the configurations requiring them.
Add support for converting objects nested in arrays with a numbering
discriminator on the command line. This syntax is used for the
object-based specification of disk source properties.
As gluster natively supports multiple hosts for failover reasons we can
easily add the support to the storage driver code in libvirt.
Extract the code setting an individual host into a separate function and
call them in a loop. The new code also tries to keep the debug log
entries sane.
Extract the code so that it can be called from multiple places. This
also removes a tricky fallthrough in the large switch in
qemuBuildNetworkDriveStr.
Add a modular parser that will allow to parse 'json' backing definitions
that are supported by qemu. The initial implementation adds support for
the 'file' driver.
Due to the approach qemu took to implement the JSON backing strings it's
possible to specify them in two approaches.
The object approach:
json:{ "file" : { "driver":"file",
"filename":"/path/to/file"
}
}
And a partially flattened approach:
json:{"file.driver":"file"
"file.filename":"/path/to/file"
}
Both of the above are supported by qemu and by the code added in this
commit. The current implementation de-flattens the first level ('file.')
if possible and required. Other handling may be added later but
currently only one level was possible anyways.
The cur_balloon also increases/decreases with dimm hotplug/unplug.
To be consistent, adjust the value for coldplug too. This was inconsistently
taken care when cur_ballon != memory to begin with. The patch fixes it
irrespective of that.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Since commit c4bdff19, the path to the configuration file has been constructed
in the following manner:
- if no config filename was passed to virConfLoadConfigPath, libvirt.conf was
used as default
- otherwise the filename was concatenated with
"<config_dir>/libvirt/libvirt%s%s.conf" which in admin case resulted in
"libvirt-libvirt-admin.conf.conf". Obviously, this non-existent config led to
ignoring all user settings in libvirt-admin.conf. This patch requires the
config filename to be always provided as an argument with the concatenation
being simplified.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1357364
Signed-off-by: Erik Skultety <eskultet@redhat.com>
For use with memory hotplug virQEMUBuildCommandLineJSONRecurse attempted
to format JSON arrays as bitmap on the command line. Make the formatter
function configurable so that it can be reused with different syntaxes
of arrays such as numbered arrays for use with disk sources.
This patch extracts the code and adds a parameter for the function that
will allow to plug in different formatters.
Until now the JSON->commandline convertor was used only for objects
created by qemu. To allow reusing it with disk formatter we'll need to
escape ',' as usual in qemu commandlines.
Refactor the command line generator by adding a wrapper (with
documentation) that will handle the outermost object iteration.
This patch also renames the functions and tweaks the error message for
nested arrays to be more universal.
The new function is then reused to simplify qemucommandutiltest.
As we already test that the extraction of the backing store string works
well additional tests for the backing store string parser can be made
simpler.
Export virStorageSourceNewFromBackingAbsolute and use it to parse the
backing store strings, format them using virDomainDiskSourceFormat and
match them against expected XMLs.
Nothing in the code path after the removed call has needs/uses the alias
anyway (as would be the case for command line building or talking to monitor).
The alias is VIR_FREE'd in virDomainDeviceInfoClear which is called for any
device that needs/uses an alias via virDomainDeviceDefFree or virDomainDefFree
as well as during virDomainDeviceInfoFree for host devices.
For persistent domains, the domain definition (including aliases) gets
freed a few screens later when it's replaced with newDef.
For transient domains, the definition is freed/unref'd along with the
virDomainObj a few moments later.
Introduce initial support for domainBlockStats API call that
allow us to query block device statistics. OpenStack nova
uses this API call to query block statistics, alongside
virDomainMemoryStats and virDomainInterfaceStats. Note that
this patch only introduces it for VBD for starters. QDisk
would come in a separate patch series.
A new statistics data structure is introduced to fit common
statistics among others specific to the underlying block
backends. For the VBD statistics on linux these are exported
via sysfs on the path:
"/sys/bus/xen-backend/devices/vbd-<domid>-<devid>/statistics"
To calculate the block devno libxlDiskPathToID is introduced.
Each backend implements its own function to extract statistics,
allowing support for multiple backends and different platforms.
VBD stats are exposed in reqs and number of sectors from
blkback, and it's up to us to convert it to sector sizes.
The sector size is gathered through xenstore in the device
backend entry "physical-sector-size".
BlockStatsFlags variant is also implemented which has the
added benefit of getting the number of flush requests.
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
QEMU reports timestamp along with other memory statistics, but this information is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in qemu_monitor_text.c.
Signed-off-by: Derbyshev Dmitry <dderbyshev@virtuozzo.com>
'memtotal' in virtio drivers and qemu corresponds to 'available' in libvirt.
Because of that, 'stat-available-memory' is renamed into 'usable'.
Balloon statistics are not reported in hrf, so no modifications are made in qemu_monitor_text.c.
Signed-off-by: Derbyshev Dmitry <dderbyshev@virtuozzo.com>
Dropping the caching of ccw address set.
The cached set is not required anymore, because the set is now being
recalculated from the domain definition on demand, so the cache
can be deleted.
The address sets (pci, ccw, virtio serial) are currently cached
in qemu private data, but all the information required to recreate
these sets is in the domain definition. Therefore I am removing
the redundant data and adding a way to recalculate these sets.
Add a function that calculates the ccw address set
from the domain definition.
Dropping the caching of virtio serial address set.
The cached set is not required anymore, because the set is now being
recalculated from the domain definition on demand, so the cache
can be deleted.
Credit goes to Cole Robinson.
Dropping the caching of virtio serial address set.
Instead of using the cached address set, a function in qemu_hotplug.c
now recalculates it on demand.
Credit goes to Cole Robinson.
The address sets (pci, ccw, virtio serial) are currently cached
in qemu private data, but all the information required to recreate
these sets is in the domain definition. Therefore I am removing
the redundant data and adding a way to recalculate these sets.
Add a function that calculates the virtio serial address set
from the domain definition.
Credit goes to Cole Robinson.
The symbol being missing has been reported as causing build
failures on OS X. If it's not already defined, define it to
zero so that it won't have any effect.
Commit 4a585a88 introduced searching QOM device path by alias, let's use it for
memballoon too. This may speedup the search because in most cases we will find
the correct QOM device path directly by using alias without the need for the
recursion code.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit ce745914 introduced detection of actual video ram sizes to fix migration
if QEMU decide to modify the values provided by libvirt. This works perfectly
for domains with number of video devices up to two.
If there are more than two video devices in the guest all the secondary devices
in the XML will have the same memory values. This is because our current code
search for QOM device path only by the device type name and all the secondary
video devices has the same name "qxl".
This patch introduces a new search function that will try to search a QOM device
path using also device's alias if the alias is available. After that it will
fallback to the old recursive code if the alias search found no results.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358728
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Previously, qemuDomainAttachDeviceFlags was doing two things:
handling the job and attaching devices. Now the second part is
in a new function.
This change is required to make it possible to test more complex
device attachment situations, like attaching a device to both
config and live at once.
We want to be able to pass a NULL instead of the connection
and use this function in tests. To achieve this, the virConnectPtr
is passed instead of virDomainPtr, and the driver is a new separate
parameter.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
So commit 306b3a8504 tried mimicking behaviour of commit 540c339a25, but
added a virObjectRef(vm) only after virDomainObjListAdd() in
lxcDomainDefineXMLFlags() and not in lxcDomainCreateXMLWithFiles().
That way undefining a domain that was started with different XML than
defined will leave the domain object in a state with not enough
references to then remove it. Hence any lxcDomainDestroyFlags() called
afterwards crashes the daemon.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351057
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since return code is checked globally at the end of the function, let's
make sure that we set it correctly at any point.
This fixes a regression introduced in commit 0aa19f35 where the first
command to eject changeable media would fail unconditionally.
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
This patch forces container's init process, to become a session leader,
that is its session ID is made the same as its process ID.
That might seem unnecessary in general, but if we want to checkpoint a
container with CRIU, which is needed for container migration,
we must ensure that the SID of each process inside the container points
to a process that lives in the same PID namespace as the container.
Therefore, we force that the session leader is the init.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
When parsing a command line with USB devices that have
no address specified, QEMU automatically adds a USB hub
if the device would fill up all the available USB ports.
To help most of the users, add one hub if there are more
USB devices than available ports. For wilder configurations,
expect the user to provide us with more hubs and/or controllers.
Walk through all the usb hubs in the domain definition
that have a USB address specified, create the
corresponding structures in the virDomainUSBAddressSet
and mark the port it occupies as used.
A new type to track USB addresses.
Every <controller type='usb' index='i'/> is represented by an
object of type virDomainUSBAddressHub located at buses[i].
Each of these hubs has up to 'nports' ports.
If a port is occupied, it has the corresponding bit set in
the 'ports' bitmap, e.g. port 1 would have the 0th bit set.
If there is a hub on this port, then hubs[i] will point
to this hub.
Undefine procedure drops domain lock while waiting for detaching
disks vz sdk call. Meanwhile vz sdk event domain-config-changed
arrives, its handler finds domain and is blocked waiting for job
condition. After undefine API call finishes event processing procedes
and tries to refreshes domain config thru existing vz sdk domain handle.
Domain does not exists anymore and event processing fails. Everything
is fine we just don't want to see error message in log for this
particular case.
Fortunately domain has flag that domain is removed from list. This
also imply that vz sdk domain is also undefined. Thus if we check
for this flag right after domain is locked again on accuiring
job condition we gracefully handle this situation.
Actually the race can happen in other situations too. Any
time we wait for job condition in mutualy exclusive job in
time when we acquire it vz sdk domain can cease to exist.
So instead of general internal error we can return domain
not found which is easier to handle. We don't need to patch
other places in mutually exclusive jobs where domain lock
is dropped as if job is started domain can't be undefine
by mutually exclusive undefine job.
The code of this patch is quite similar to qemu driver checks
for is domain is active after acquiring a job. The difference
only while qemu domain is operational while process is active
vz domain is operational while domain exists.
Current vz driver implementation is not usable when it comes to
long runnig operations. Migration or saving a domain blocks all
other operations even query ones which are expecteted to be available.
This patch addresses this problem.
All vz driver API calls fall into next 3 groups:
1. only query domain cache (virDomainObj, vz cache statistic)
examples are vzDomainGetState, vzDomainGetXMLDesc etc.
2. use thread shared sdkdom object
examples are vzDomainSetMemoryFlags, vzDomainAttachDevice etc.
3. use no thread shared sdkdom object nor domain cache
examples are vzDomainSnapshotListNames, vzDomainSnapshotGetXMLDesc etc
API calls from group 1 don't need to be changed as they hold domain lock only
for short period of time. These calls [1] are easily distinguished. They query
domain object thru libvirt common code or query vz sdk statistics handle thru
vz sdk sync operations.
vzDomainInterfaceStats is the only exception. It uses sdkdom object to
convert interface name to its vz sdk stack index which could not be saved in
domain cache. Interface statistics is available thru this stack index as a key
rather than name. As a result we can have accidental 'not known interface'
errors on quering intrerface stats. The reason is that in the process of
updating domain configuration we drop all devices and then recreate them again
in sdkdom object and domain lock can be dropped meanwhile (to remove networks
for existing bridged interfaces and(or) (re)create new ones). We can fix this
by changing the way we support bridged interfaces or by reordering operations
and changing bridged networks beforehand. Anyway this is better than moving
this API call into 2 group and making it an exclusive job.
As to API calls from group 2, first thread shared sdkdom object needs to be
explained. vz sdk has only one handle for a given domain, thus threads need
exclusive access to operate on it. These calls are fixed to drop and reacquire
domain lock on any lengthy operations - namely waiting the result of async vz
sdk operation. As lock is dropped we need to take extra reference to domain
object if it is not taken already as domain object can be deleted from list
while lock is dropped. As this operations use thread shared sdkdom object, the
simplest way to make calls from group 2 be consistent to each other is to make
them mutually exclusive. This is done by taking/releasing job condition thru
calling correspondent job routine. This approach makes group 1 and group
2 calls consistent to each other too. Not all calls of group 2 change the
domain cache but those that do update it thru prlsdkUpdateDomain which holds
the lock thoughout the update.
API calls from group [2] are easily distinguished too. They use
beginEdit/commit to change domain configuration (vzDomainSetMemoryFlags) or/and
update domain cache from sdkdom at the end of operation (vzDomainSuspend).
There is a known issue however. Frankly speaking it was introduced by ealier
patch '[PATCH 6/9] vz: cleanup loading domain code' from a different series.
The patch significantly reduced amount of time when the driver lock is held when
creating domain from API call or as a result of domain added event from vz sdk.
The problem is these two paths race on using thread shared sdkdom as we don't
have libvirt domain object and can not lock on it. However this don't
invalidates the patch as we can't use the former approach of preadding domain
into the list as we need name at least and name is not given by event. Anyway
i'm against adding half baked object into the list. Eventually this race can be
fixed by extra measures. As to current situation races with different
configurations are unlikely and race when adding domain thru vz driver and
simultaneous event from vz sdk is not dangerous as configuration is the same.
The last group [3] is API calls that need only sdkdom object to make vz sdk
call and don't change thread shared sdkdom object or domain cache in any way.
For now these are mostly domain snapshot API calls. The changes are similar to
those of group 2 - they add extra reference and drop/reacquire the lock on waiting
vz async call result. One can simply take the immutable sdkdom object from the
cache and drop the lock for the rest of operations but the chosen approach
makes implementation of these API calls somewhat similar to those of from group
2 and thus a bit futureproof. As calls of group 3 don't need vz driver
domain/vz sdk cache in any way, they are consistent with respect to API calls from
groups 1 and 3.
There is another exception. Calls to make-snapshot/revert-to-snapshot/migrate
are moved to group 2. That is they are made mutually exclusive. The reason
is that libvirt API supports control/query only for one job per domain and
these are jobs that are likely to be queried/aborted.
Appendix.
[1] API calls that only query domain cache.
(marked [*] are included for a different reason)
.domainLookupByID = vzDomainLookupByID, /* 0.10.0 */
.domainLookupByUUID = vzDomainLookupByUUID, /* 0.10.0 */
.domainLookupByName = vzDomainLookupByName, /* 0.10.0 */
.domainGetOSType = vzDomainGetOSType, /* 0.10.0 */
.domainGetInfo = vzDomainGetInfo, /* 0.10.0 */
.domainGetState = vzDomainGetState, /* 0.10.0 */
.domainGetXMLDesc = vzDomainGetXMLDesc, /* 0.10.0 */
.domainIsPersistent = vzDomainIsPersistent, /* 0.10.0 */
.domainGetAutostart = vzDomainGetAutostart, /* 0.10.0 */
.domainGetVcpus = vzDomainGetVcpus, /* 1.2.6 */
.domainIsActive = vzDomainIsActive, /* 1.2.10 */
.domainIsUpdated = vzDomainIsUpdated, /* 1.2.21 */
.domainGetVcpusFlags = vzDomainGetVcpusFlags, /* 1.2.21 */
.domainGetMaxVcpus = vzDomainGetMaxVcpus, /* 1.2.21 */
.domainHasManagedSaveImage = vzDomainHasManagedSaveImage, /* 1.2.13 */
.domainGetMaxMemory = vzDomainGetMaxMemory, /* 1.2.15 */
.domainBlockStats = vzDomainBlockStats, /* 1.2.17 */
.domainBlockStatsFlags = vzDomainBlockStatsFlags, /* 1.2.17 */
.domainInterfaceStats = vzDomainInterfaceStats, /* 1.2.17 */ [*]
.domainMemoryStats = vzDomainMemoryStats, /* 1.2.17 */
.domainMigrateBegin3Params = vzDomainMigrateBegin3Params, /* 1.3.5 */
.domainMigrateConfirm3Params = vzDomainMigrateConfirm3Params, /* 1.3.5 */
[2] API calls that use thread shared sdkdom object
(marked [*] are included for a different reason)
.domainSuspend = vzDomainSuspend, /* 0.10.0 */
.domainResume = vzDomainResume, /* 0.10.0 */
.domainDestroy = vzDomainDestroy, /* 0.10.0 */
.domainShutdown = vzDomainShutdown, /* 0.10.0 */
.domainCreate = vzDomainCreate, /* 0.10.0 */
.domainCreateWithFlags = vzDomainCreateWithFlags, /* 1.2.10 */
.domainReboot = vzDomainReboot, /* 1.3.0 */
.domainDefineXML = vzDomainDefineXML, /* 0.10.0 */
.domainDefineXMLFlags = vzDomainDefineXMLFlags, /* 1.2.12 */ (update part)
.domainUndefine = vzDomainUndefine, /* 1.2.10 */
.domainAttachDevice = vzDomainAttachDevice, /* 1.2.15 */
.domainAttachDeviceFlags = vzDomainAttachDeviceFlags, /* 1.2.15 */
.domainDetachDevice = vzDomainDetachDevice, /* 1.2.15 */
.domainDetachDeviceFlags = vzDomainDetachDeviceFlags, /* 1.2.15 */
.domainSetUserPassword = vzDomainSetUserPassword, /* 1.3.6 */
.domainManagedSave = vzDomainManagedSave, /* 1.2.14 */
.domainSetMemoryFlags = vzDomainSetMemoryFlags, /* 1.3.4 */
.domainSetMemory = vzDomainSetMemory, /* 1.3.4 */
.domainRevertToSnapshot = vzDomainRevertToSnapshot, /* 1.3.5 */ [*]
.domainSnapshotCreateXML = vzDomainSnapshotCreateXML, /* 1.3.5 */ [*]
.domainMigratePerform3Params = vzDomainMigratePerform3Params, /* 1.3.5 */ [*]
.domainUpdateDeviceFlags = vzDomainUpdateDeviceFlags, /* 2.0.0 */
prlsdkHandleVmConfigEvent
[3] API calls that do not use thread shared sdkdom object
.domainManagedSaveRemove = vzDomainManagedSaveRemove, /* 1.2.14 */
.domainSnapshotNum = vzDomainSnapshotNum, /* 1.3.5 */
.domainSnapshotListNames = vzDomainSnapshotListNames, /* 1.3.5 */
.domainListAllSnapshots = vzDomainListAllSnapshots, /* 1.3.5 */
.domainSnapshotGetXMLDesc = vzDomainSnapshotGetXMLDesc, /* 1.3.5 */
.domainSnapshotNumChildren = vzDomainSnapshotNumChildren, /* 1.3.5 */
.domainSnapshotListChildrenNames = vzDomainSnapshotListChildrenNames, /* 1.3.5 */
.domainSnapshotListAllChildren = vzDomainSnapshotListAllChildren, /* 1.3.5 */
.domainSnapshotLookupByName = vzDomainSnapshotLookupByName, /* 1.3.5 */
.domainHasCurrentSnapshot = vzDomainHasCurrentSnapshot, /* 1.3.5 */
.domainSnapshotGetParent = vzDomainSnapshotGetParent, /* 1.3.5 */
.domainSnapshotCurrent = vzDomainSnapshotCurrent, /* 1.3.5 */
.domainSnapshotIsCurrent = vzDomainSnapshotIsCurrent, /* 1.3.5 */
.domainSnapshotHasMetadata = vzDomainSnapshotHasMetadata, /* 1.3.5 */
.domainSnapshotDelete = vzDomainSnapshotDelete, /* 1.3.5 */
[4] Known issues.
1. accidental errors on getting network statistics
2. race with simultaneous use of thread shared domain object on paths
of adding domain thru API and adding domain on vz sdk domain added event.
sdk domain handle is unique per connection so there is
no sense to query it again if we have it in vzDomObjPtr.
Side effect of prlsdkSdkDomainLookupByUUID is refreshing
domain config is of no use too as PrlVm_BeginEdit do it too.
Commit id '5e46d7d6' did not take into account that usage of a luks
volume will require usage of the master key encrypted passphrase for
a QEMU environment. So rather than allow creation of something that
won't be usable, just fail the creation.
Resolves a CI test integration failure with a RHEL6/Centos6 environment.
In order to use a LUKS encrypted device, the design decision was to
generate an encrypted secret based on the master key. However, commit
id 'da86c6c' missed checking for that specifically.
When qemuDomainSecretSetup was implemented, a design decision was made
to "fall back" to a plain text secret setup if the specific cipher was
not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC))
as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup
there is no fall back to the plaintext secret, thus if that gets set
up by qemuDomainSecretSetup, then we need to fail.
Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET
bit, it didn't take into account the second requirement that the
ability to generate the encrypted secret is possible. So modify the
test to not attempt to run the luks-disk if we know we don't have
the encryption algorithm.
Any error happening after the hand shake in the lxc controller
will not result in a failure as errors are checked during the handshake.
Move the handshake after the last possible error.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021
Generate the luks command line using the AES secret key to encrypt the
luks secret. A luks secret object will be in addition to a an AES secret.
For hotplug, check if the encinfo exists and if so, add the AES secret
for the passphrase for the secret object used to decrypt the device.
Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle
find a uuid or a volume usage with a specific path prefix in the XML
(corresponds to the already generated XML tests). Add error message
when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39'
altered the error message generation to rely on the errors from the
secret_driver (or it's faked replacement).
Add the .args output for adding the LUKS disk to the domain
Signed-off-by: John Ferlan <jferlan@redhat.com>
Soon we will be adding luks encryption support. Since a volume could require
both a luks secret and a secret to give to the server to use of the device,
alter the alias generation to create a slightly different alias so that
we don't have two objects with the same alias.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Commit id 'a1344f70a' added AES secret processing for RBD when starting
up a guest. As such, when the hotplug code calls qemuDomainSecretDiskPrepare
an AES secret could be added to the disk about to be hotplugged. If an AES
secret was added, then the hotplug code would need to generate the secret
object because qemuBuildDriveStr would add the "password-secret=" to the
returned 'driveStr' rather than the base64 encoded password.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Partially resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1301021
If the volume xml was looking to create a luks volume take the necessary
steps in order to make that happen.
The processing will be:
1. create a temporary file (virStorageBackendCreateQemuImgSecretPath)
1a. use the storage driver state dir path that uses the pool and
volume name as a base.
2. create a secret object (virStorageBackendCreateQemuImgSecretObject)
2a. use an alias combinding the volume name and "_luks0"
2b. add the file to the object
3. create/add luks options to the commandline (virQEMUBuildLuksOpts)
3a. at the very least a "key-secret=%s" using the secret object alias
3b. if found in the XML the various "cipher" and "ivgen" options
Signed-off-by: John Ferlan <jferlan@redhat.com>
When formatting the graphics data for TYPE_SPICE, check if the glisten
is NULL before blindly referencing
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
A recent adjustment to qemuDomainAttachRNGDevice to properly cleanup
the props object after a qemuMonitorAddObject also would affect this
code. Alter the cleanup to be similar to RNG changes.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Commit da665fbd introduced the following condition to virLXCProcessEnsureRootFS
and openvzReadFSConf:
if (!(<some_var> = virDomainFSDefNew()) < 0)
which broke the build on fedora with GCC 5.3.1: "logical not is only applied to
the left hand side of comparison".
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The commit da665fbd introduced virStorageSourcePtr inside the structure
_virDomainFSDef. This is causing an error when libvirt is being compiled.
make[3]: Entering directory `/media/julio/8d65c59c-6ade-4740-9cdc-38016a4cb8ae
/home/julio/Desktop/virt/libvirt/src'
CC security/virt_aa_helper-virt-aa-helper.o
security/virt-aa-helper.c: In function 'get_files':
security/virt-aa-helper.c:1087:13: error: passing argument 2 of 'vah_add_path'
from incompatible pointer type [-Werror]
if (vah_add_path(&buf, fs->src, "rw", true) != 0)
^
security/virt-aa-helper.c:732:1: note: expected 'const char *' but argument is
of type 'virStorageSourcePtr'
vah_add_path(virBufferPtr buf, const char *path, const char *perms, bool
recursive)
^
cc1: all warnings being treated as errors
Adding the attribute "path" from virStorageSourcePtr fixes this issue.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
vz supports only a subset of tcp and udp parameters.
1. tcp type supports only 'raw' protocol.
2. udp type supports only same parameters of 'host' and 'service'
for 'bind' and 'connect'.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
After domain is in the domains list let's keep it there. This
is approach taken by qemu driver and vz vzDomainMigrateFinish3Params too.
It quite reasonable, driver domain object is fully constructed and
can be discovered by client later.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
9c14a9ab introduced vzNewDomain function to enlist libvirt domain
object before actually creating vz sdk domain. Fix should fix
race on same vz sdk domain added event where libvirt domain object is
enlisted too. But later eb5e9c1e added locked checks for
adding livirtd domain object to list on vz sdk domain added event.
Thus now approach of 9c14a9ab is unnecessary complicated.
See we have otherwise unuseful prlsdkGetDomainIds function only
to create minimal domain definition to create libvirt domain object.
Also vzNewDomain is difficult to use as it creates partially
constructed domain object.
Let's move back to original approach where prlsdkLoadDomain do
all the necessary job. Another benefit is that we can now
take driver lock for bare minimum and in single place. Reducing
locking time have small disadvatage of double parsing on race
conditions which is typical if domain is added thru vz driver.
Well we have this double parse inevitably with current vz sdk api
on any domain updates so i would not take it here seriously.
Performance events subscribtion is done before locked check and
therefore could be done twice on races but this is not the problem.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Vz containers are able to use ploop volumes from storage pools
to work upon.
To use filesystem type volume, pool name and volume name should be
specifaed in <source> :
<filesystem type='volume' accessmode='passthrough'>
<driver type='ploop' format='ploop'/>
<source pool='guest_images' volume='TEST_POOL_CT'/>
<target dir='/'/>
</filesystem>
The information about pool and volume is stored in ct dom configuration:
<StorageURL>libvirt://localhost/pool_name/vol_name</StorageURL>
and can be easily obtained via PrlVmDevHd_GetStorageURL sdk call.
The only shorcoming: if storage pool is moved somewhere the ct
should be redefined in order to refresh the information aboot path
to root.hdd
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
We do not need to check domainf fs type there,
because it is done in prlsdkCheckUnsupportedParams.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
New type of <devices> <filesystem type= 'volume'> is introduced.
This patch allows to use volumes for storing the filesystem, that is
accessed from the guest e.g. root directory for container.
To take advantage of volumes as a backend of filesystem volume
and pool names should be specified:
<filesystem type= 'volume'>
<source pool='pool name' volume='volume name'/>
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Adding domain to domain list on preparation step is not correct.
First domain is not fully constructed - domain definition is
missing. Second we can't use VIR_MIGRATE_PARAM_DEST_XML parameter
to parse definition as vz sdk can patch it by itself. Let's add/remove
domain on finish step. This is for synchronization purpose only so domain
is present/absent on destination after migration completion. Actually
domain object will probably be created right after actual vz sdk
migration start by vz sdk domain defined event.
We can not and should not sync domain cache on error path in finish step
of migration. We can not as we really don't know what is the reason of
cancelling and we should not as user should not make assumptions on
state on error path. What we should do is cleaning up temporary migration
state that is induced on prepare step but we don't have one. Thus
cancellation should be noop.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
libvirt domain defined event is issued only on correspondent vz sdk
event. But in case event delivered before domain is added to
domain list we can mistakenly skip this event if prlsdkNewDomainByHandle
return NULL in case of domain is discovered in the list under
the driver lock. Let's return domain object in this case.
Now prlsdkNewDomainByHandle returns NULL only in case of
error which is more convinient.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
The first version of migration cookie was rather dumb resulting
in passing empty or unused fields here and there. Add flags to
specify what to bake to and eat from cookie so we deal only
with meaningful data. However for backwards compatibility
we still need to pass at least some faked fields sometimes.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Older libvirt versions send persistent XML in a migration cookie even
when VIR_MIGRATE_PERSIST_DEST flag is not used, but current libvirt
properly fails if the cookie contains unexpected flags. Thus migration
from old libvirt fails with
internal error: Unsupported migration cookie feature persistent
unless VIR_MIGRATE_PERSIST_DEST flag is set.
https://bugzilla.redhat.com/show_bug.cgi?id=1320500
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
A nodedev device definition like this is required for testing
NodeDeviceCreateXML and NodeDeviceDestroy. So unless it's part
of the stock test:///default set there's no way to actually
invoke those functions for the default URI
Convert the individual XML documents into one big XML document
in the format expected by the non-default test://$PATH URI, and
use the same internal helpers for assembling the driver contents.
virConfGetValueLLong() errors out if the value is too big to
fit into a long long integer, but claims the supported range
to be (0,LLONG_MAX) instead of (LLONG_MIN,LLONG_MAX).
When parsing numeric values, we always store them as unsigned
unless they're negative. We can use this fact to simplify the
logic by removing a bunch of unnecessary checks.
Commit 6381c89f8c changed virConfValue to store long long
integers instead of long integers; however, the temporary variable
used in virConfParseLong() was not updated accordingly, causing
trouble for 32-bit machines.
In preparation to tracking which USB addresses are occupied.
Introduce two helper functions for printing the port path
as a string and appending it to a virBuffer.
We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).
Only format the port if it has been specified and mark it as optional
in the XML schema.
Migration to an older libvirt (pre v1.3.0-175-g7140807) is broken
because older versions of libvirt generated different channel paths and
they didn't drop the default paths when parsing domain XMLs. We'd get
such a nice error message:
internal error: process exited while connecting to monitor:
2016-07-08T15:28:02.665706Z qemu-kvm: -chardev socket,
id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/
domain-3-nest/org.qemu.guest_agent.0,server,nowait: Failed to bind
socket to /var/lib/libvirt/qemu/channel/target/domain-3-nest/
org.qemu.guest_agent.0: No such file or directory
That said, we should not even format the default paths when generating a
migratable XML.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Playing directly with our live definition, updating it, and reverting it
back once we are done is very nice and it's quite dangerous too. Let's
just make a copy of the domain definition if needed and do all tricks on
the copy.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
If size_t is the same size as long long, then we can skip
some of the range checks. This avoids triggering some
bogus compiler warning messages.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virConf 'l' field is a 'signed long long', so whenever
the 'type' field is VIR_CONF_ULONG, we should explicitly cast
'l' to a 'unsigned long long' before doing range checks.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This function tries to get a ssize_t value from a config file.
But before returning it, it checks whether the value would fit in
ssize_t and if not an error is printed out among with the range
for the ssize_t type. However, on some platforms SSIZE_MAX may
actually be a signed long type:
util/virconf.c: In function 'virConfGetValueSSizeT':
util/virconf.c:1268:9: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=]
virReportError(VIR_ERR_INTERNAL_ERROR,
^
$ grep -r SSIZE_MAX /usr/include/
/usr/include/bits/posix1_lim.h:#ifndef SSIZE_MAX
/usr/include/bits/posix1_lim.h:# define SSIZE_MAX LONG_MAX
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
MinGW complained that we might be dereferencing a NULL pointer. While
that can't be true, the logic certainly allows for that.
../../src/conf/domain_conf.c: In function 'virDomainDefPostParse':
../../src/conf/domain_conf.c:4224:18: error: potential null pointer dereference [-Werror=null-dereference]
if (!vcpu->online && vcpu->cpumask) {
~~~~^~~~~~~~
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
MinGW complained that we might be dereferencing a NULL pointer. While
that can't be true, the logic certainly allows for that.
src/conf/domain_conf.c: In function 'virDomainDefGetVcpuPinInfoHelper':
src/conf/domain_conf.c:1545:17: error: potential null pointer dereference [-Werror=null-dereference]
if (vcpu->cpumask)
~~~~^~~~~~~~~
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
IPv6 RA always contains an implicit default route via
the link-local address of the source of RA. This forces
the guest to install a route via isolated network, which
may disturb the guest's networking in case of multiple interfaces.
More info in 013427e6e7.
The validity of this route is controlled by "default [route] lifetime"
field of RA. If the lifetime is set to 0 seconds, then no route
is installed by receiver.
dnsmasq 2.67+ supports "ra-param=<interface>,<RA interval>,<default
lifetime>" option. We pass "ra-param=*,0,0"
(here, RA_interval=0 means default) to disable default gateway in RA
for isolated networks.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1354238
So we spend some time and effort constructing perfect file name
for an automatic coredump of a domain, but then just leak it and
use the domain name anyway. This is probably due to a silly
mistake that slipped even through review.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
At least with systemd v210, NOTIFY_SOCKET is abstact, e.g.
@/org/freedesktop/systemd1/notify. sendmsg() fails on such a socket
with "Connection refused". The unix(7) man page contains the following
details wrt abstract socket addresses
abstract: an abstract socket address is distinguished (from a
pathname socket) by the fact that sun_path[0] is a null byte
('\0'). The socket's address in this namespace is given by the
additional bytes in sun_path that are covered by the specified
length of the address structure. (Null bytes in the name have
no special significance.)
So we need to be more precise about the address length, setting it to
the sizeof sa_family_t + length of address copied to sun_path instead
of setting it to the sizeof the entire sockaddr_un struct.
Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=987668
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
When fetching domains with virConnectListAllDomains() and when filtering
by snapshot existence is requested the ESX driver first lists all the
domains and then check one-by-one for snapshot existence. This process
takes unnecessarily long time.
To significantly improve the time necessary to finish the query we can
request the snapshot related info directly when querying the list of
domains from VMware.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
In an unlikely event of execve() failing, the virCommandExec()
function does not report any error, even though checks that are
at the beginning of the function are verbose when failing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The modification of .volWipe callback wipes ploop volume using one of
given wiping algorithm: dod, nnsa, etc.
However, in case of ploop volume we need to reinitialize root.hds and DiskDescriptor.xml.
v2:
- added check on ploop tools presens
- virCommandAddArgFormat changed to virCommandAddArg
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Check whether QEMU supports -device intel-iommu
Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1235580
Currently many users of virConf APIs are defining the same
macros for calling virConfValue() and then doing type
checking. To remove this repeated code, add a set of
typesafe accessor methods.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If the config file does not end with a \n, the parser will append
one. When re-allocating the array though, it is mistakenly assuming
that 'len' is the length including the trailing NUL, but it does
not. So we must add 2 to len, when reallocating, not 1.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This one's a bit more complicated. In qemuProcessPrepareDomain()
a master key for encrypting secret for ciphered disks is created.
This object lives within qemuDomainObjPrivate object. It is freed
in qemuProcessStop(), but if nobody calls it (for instance like
our qemuxml2argvtest does), the key object leaks.
==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707
==17078== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==17078== by 0xAD924DF: virAllocN (viralloc.c:191)
==17078== by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166)
==17078== by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678)
==17078== by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913)
==17078== by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542)
==17078== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==17078== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==17078== by 0x446E7A: virTestRun (testutils.c:179)
==17078== by 0x445BD9: mymain (qemuxml2argvtest.c:2022)
==17078== by 0x44886F: virTestMain (testutils.c:969)
==17078== by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Just like every other qemuBuild*CommandLine() function, this uses
a buffer to hold partial cmd line strings too. However, if
there's an error, the control jumps to 'cleanup' label leaving
the buffer behind and thus leaking it.
==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711
==2013== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==2013== by 0x4C2C32F: realloc (vg_replace_malloc.c:692)
==2013== by 0xAD925A8: virReallocN (viralloc.c:245)
==2013== by 0xAD95EA8: virBufferGrow (virbuffer.c:130)
==2013== by 0xAD95F78: virBufferAdd (virbuffer.c:165)
==2013== by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339)
==2013== by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437)
==2013== by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174)
==2013== by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546)
==2013== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==2013== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==2013== by 0x446E7A: virTestRun (testutils.c:179)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When storage secret is parsed in virStorageEncryptionSecretParse(),
virSecretLookupParseSecret() which allocates some memory. This is
however never freed.
==21711== 134 bytes in 6 blocks are definitely lost in loss record 70 of 85
==21711== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==21711== by 0xBCA0356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==21711== by 0xA9F432E: virXMLPropString (virxml.c:479)
==21711== by 0xA9D25B0: virSecretLookupParseSecret (virsecret.c:70)
==21711== by 0xA9D616E: virStorageEncryptionSecretParse (virstorageencryption.c:172)
==21711== by 0xA9D66B2: virStorageEncryptionParseXML (virstorageencryption.c:281)
==21711== by 0xA9D68DF: virStorageEncryptionParseNode (virstorageencryption.c:338)
==21711== by 0xAA12575: virDomainDiskDefParseXML (domain_conf.c:7606)
==21711== by 0xAA2CAC6: virDomainDefParseXML (domain_conf.c:16658)
==21711== by 0xAA2FC75: virDomainDefParseNode (domain_conf.c:17472)
==21711== by 0xAA2FAE4: virDomainDefParse (domain_conf.c:17419)
==21711== by 0xAA2FB72: virDomainDefParseFile (domain_conf.c:17443)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Setting up cgroups and other things for all kinds of threads (the
emulator thread, vCPU threads, I/O threads) was copy-pasted every time
new thing was added. Over time each one of those functions changed a
bit differently. So create one function that does all that setup and
start using it, starting with I/O thread setup. That will shave some
duplicated code and maybe fix some bugs as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true
qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
^
It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.
This splits the conditional check into two parts with
distinct error messages and fixes the logic error.
Fixes the bug in
commit 5184f398b4
Author: Peter Krempa <pkrempa@redhat.com>
Date: Fri Jul 1 14:56:14 2016 +0200
qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
An error in virHostCPUGetKVMMaxVCPUs() means we've been unable
to access /dev/kvm, or we're running on a platform that doesn't
support KVM in the first place.
If that's the case, we shouldn't ignore the error and report
domcapabilities even though we know the user won't be able to
start any KVM guest.
If we don't HAVE_LINUX_KVM_H, we can't query /dev/kvm to discover
the limits on the number of vCPUs, so we report an error and
return a negative value instead.
Allow to store driver specific data on a per-vcpu basis.
Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.
Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.
A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.
The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the bootloader is treated as a
custom bootloader.
Custom bootloader are supported by setting the def->os.bootloader and
def->os.bootloaderArgs accordingly
grub-bhyve is also treated as a custom bootloader. Since we don't get the
device map in the native format anyways, we can't reconstruct the complete
boot order. While it is possible to check what type the grub boot disk is by
checking if the --root argument is "cd" or "hd0,msdos1", and then just use the
first disk found, implementing the grub-bhyve argument parser as-is in the
grub-bhyve source would mean adding a dependency to argp or duplicating lots
of the code of argp. Therefore it's not really worth implementing that now.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
loosely based on its argument parser, which reads the following from the bhyve
command line string:
* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime)
* features:
* acpi
* ioapic: While this flag is deprecated in FreeBSD r257423, keep checking for
it for backwards compatibiility.
* the domain UUID; if not explicitely given, one will be generated.
* lpc devices: for now only the com1 and com2 are supported. It is required for
these to be /dev/nmdm[\d+][AB], and the slave devices are automatically
inferred from these to be the corresponding end of the virtual null-modem
cable: /dev/nmdm<N>A <-> /dev/nmdm<N>B
* PCI devices:
* Disks: these are numbered in the order they are found, for virtio and ahci
disks separately. The destination is set to sdX or vdX with X='a'+index;
therefore only 'z'-'a' disks are supported.
Disks are considered to be block devices if the path
starts with /dev, otherwise they are considered to be files.
* Networks: only tap devices are supported. Since it isn't possible to tell
the type of the network, VIR_DOMAIN_NET_TYPE_ETHERNET is assumed, since it
is the most generic. If no mac is specified, one will be generated.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
First, remove escaped newlines and split up the string into an argv-list for
the bhyve and loader commands, respectively. This is done by iterating over the
string splitting it by newlines, and then re-iterating over each line,
splitting it by spaces.
Since this code reuses part of the code of qemu_parse_command.c
(in bhyveCommandLine2argv), add the appropriate copyright notices.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
As there is an explicit constructor for the special case of empty
bitmaps, we should mention that the generic constructors rejects the
creation of empty bitmaps.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Before the variable 'bits' was initialized with 0 (commit
3470cd860d), the following bug was
possible.
A function call with an empty bitmap leads to undefined
behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
and 'sz == 1'. So the non global and non static variable 'bits' would
have never been set. Consequently the check 'bits == 0' results in
undefined behavior.
This patch clarifies the current version of the function by handling the
empty bitmap explicitly. Also, for an empty bitmap there is obviously no
bit set so we can just return -1 (indicating no bit set) right away. The
explicit check for 'bits == 0' after the loop is unnecessary because we
only get to this point if no set bit was found.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.
Broken by bd7c8a69.
https://bugzilla.redhat.com/show_bug.cgi?id=1151723
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
People debugging guest OS boot processes and reported that
the default 128 KB size is too small to capture an entire
boot up sequence. Increase the default size to 2 MB which
should allow capturing a full boot up even with verbose
debugging.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently virtlogd has a hardcoded max file size of 128kb
and max of 3 backups. This adds two new config parameters
to /etc/libvirt/virtlogd.conf to let these be customized.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
After 27726d8c21 a privateData is allocated in
virDomainHostdevDefAlloc(). However, the counter part - freeing
them in Free() is missing which leads to the following memory
leak:
==6489== 24 bytes in 1 blocks are definitely lost in loss record 684 of 1,003
==6489== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==6489== by 0x54B7C94: virAllocVar (viralloc.c:560)
==6489== by 0x5517BE6: virObjectNew (virobject.c:193)
==6489== by 0x1B400121: qemuDomainHostdevPrivateNew (qemu_domain.c:798)
==6489== by 0x5557B24: virDomainHostdevDefAlloc (domain_conf.c:2152)
==6489== by 0x5575578: virDomainHostdevDefParseXML (domain_conf.c:12709)
==6489== by 0x5582292: virDomainDefParseXML (domain_conf.c:16995)
==6489== by 0x5583C98: virDomainDefParseNode (domain_conf.c:17470)
==6489== by 0x5583B07: virDomainDefParse (domain_conf.c:17417)
==6489== by 0x5583B95: virDomainDefParseFile (domain_conf.c:17441)
==6489== by 0x55A3F24: virDomainObjListLoadConfig (virdomainobjlist.c:465)
==6489== by 0x55A43E6: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Libxl is the last user and I don't have the toolchain prepared to
compile the libxl driver. Move it to the libxl driver to avoid having to
refactor the code.
This is just a convenience method for discarding a list of filters instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Provide a separate method to free a logging filter object. This will come handy
once a method to create an individual logging filter object is introduced.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This is just a convenience method for discarding a list of outputs instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Provide a separate method to free a logging output object. This will come handy
once a method to create an individual logging output object is introduced.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Same as with outputs; since the operations will be further divided into smaller
tasks, creating a filter will become a separate operation that will return
a reference to a newly created filter.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Right now, we define outputs one after another. However, the correct flow
should be to define a set of outputs as a whole unit. Therefore each output
should be first created, placed into an array/list and the list will be
defined. Output creation should be a separate operation, so an output will be
returned by a reference. From that perspective, it makes perfect sense to
only store pointers to actual outputs.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In this particular case, reset is meant as clearing the whole list of
outputs/filters, not resetting it to a predefined default setting. Looking at
it from that perspective, returning the number of records removed doesn't help
the caller in any way (not that any of the callers would actually check for
it). Well, callers could detect an error from the number of successfully
removed records, but the only thing that can fail in virLogReset is force
closing a file descriptor in which case the error isn't propagated back to
virLogReset anyway. Conclusion: there is no practical use for having a return
type of 'int' rather than 'void' in this case.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.
Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350772
For type='ethernet' interfaces only.
(This patch had been pushed earlier in
commit 0b4645a7e0, but was reverted in
commit 84d47a3cce because it had been
accidentally pushed during the freeze for release 2.0.0)
(This patch had been pushed earlier in
commit cd5c9f21de, but was reverted in
commit 1549f16832 because it had been
accidentally pushed during the freeze for release 2.0.0)
This will apply to any IP address setting that uses
virNetDevIPInfoAddToDev() (which so far is only the guest-side of LXC
type='ethernet' interfaces).
(This patch had been pushed earlier in
commit cb20f989df, but was reverted in
commit cba06aea8d because it had been
accidentally pushed during the freeze for release 2.0.0)
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
(This patch had been pushed earlier in
commit fe6a77898a, but was reverted in
commit d658456530 because it had been
accidentally pushed during the freeze for release 2.0.0)
The peer attribute is used to set the property of the same name in the
interface IP info:
<interface type='ethernet'>
...
<ip family='ipv4' address='192.168.122.5'
prefix='32' peer='192.168.122.6'/>
...
</interface>
Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.
(This patch now has quite a history: it was originally pushed in
commit 690969af, which was subsequently reverted in commit 1d14b13f,
then reworked and pushed (along with a lot of other related/supporting
patches) in commit 93135abf1; however *that* commit had been
accidentally pushed during dev. freeze for release 2.0.0, so it was
again reverted in commit f6acf039f0).
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: Laine Stump <laine@laine.org>
This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.
One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).
(This patch had been pushed earlier in commit
f1e0d0da11, but was reverted in commit
05eab47559 because it had been
accidentally pushed during the freeze for release 2.0.0)
Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.
This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Add a new secret type known as "passphrase" - it will handle adding the
secret objects that need a passphrase without a specific username.
The format is:
<secret ...>
<uuid>...</uuid>
...
<usage type='passphrase'>
<name>mumblyfratz</name>
</usage>
</secret>
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since the virSecretDefParseUsage ensures each of the fields is present,
no need to check during virSecretDefFormatUsage (also virBufferEscapeString
is a no-op with a NULL argument).
Signed-off-by: John Ferlan <jferlan@redhat.com>
A helper that will execute a callback on every USB device
in the domain definition.
With an ability to skip USB hubs, since we will want to treat
them differently in some cases.
I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.
https://bugzilla.redhat.com/show_bug.cgi?id=1323085
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Pretending (partial) support for something we don't understand is risky.
Reporting a failure is much better.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virTypedParameterAssign steals the string rather than copying it into
the typed parameter and thus freeing it leads to a crash when attempting
to serialize the results.
This was introduced in commit 9f50f6e2 and later made an universal
helper in 32e6339c.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351473
Some code paths already assume that it is allocated since it was always
allocated by virDomainPerfDefParseXML. Make it member of virDomainDef
directly so that we don't have to allocate it all the time.
This fixes crash when attempting to connect to an existing process via
virDomainQemuAttach since we would not allocate it in that code path.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350688
Ensure that the given controller and all controllers with a smaller
index exist; there must not be any missing index in between.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The commit "qemu: hot-plug: Assume support for -device in
qemuDomainAttachSCSIDisk" dropped the code for the automatic SCSI
controller creation used in SCSI disk hot-plugging. If we are
hot-plugging a SCSI disk to a domain and there is no proper SCSI
controller defined, it results in an "error: internal error: Could not
find scsi controller with index X required for device" error.
For that reason reverting a hunk of the commit
d4d32005d6.
This patch also adds an extra comment to the code to clarify the
loop.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
CVE-2016-5008
Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".
https://bugzilla.redhat.com/show_bug.cgi?id=1180092
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Similarly to what virsh virt-login-shell do, call virAdmInitialize prior to
initializing an event loop and initializing the error handler. Commit 97973ebb7
described and fixed an identical issue for libvirt_lxc.
Since virAdmInitialize becomes a public API after applying this patch,
the symbol is also added to public syms and the doc string of the method is
slightly enhanced analogically to virInitialize.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
virNetServerClientGetInfo returns the client's remote address
as a string, which is a part of the client object.
Use VIR_STRDUP to make a copy which can be freely accessed
even after the virNetServerClient object is unlocked.
To reproduce, put a sleep between virObjectUnlock in
virNetServerClientGetInfo and virTypedParamsAddString in
adminClientGetInfo, then close the queried connection during
that sleep.
https://bugzilla.redhat.com/show_bug.cgi?id=1316370
Consider the following disk for a domain:
<disk type='volume' device='cdrom'>
<driver name='qemu' type='raw'/>
<auth username='libvirt'>
<secret type='iscsi' usage='libvirtiscsi'/>
</auth>
<source pool='iscsi-secret-pool' volume='unit:0:0:0' mode='direct' startupPolicy='optional'/>
<target dev='sda' bus='scsi'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Now, startupPolicy is currently not allowed for iscsi disks, so
one would expect an error message to be thrown. But what a
surprise is waiting for users if they try to start up such
domain:
==15724== Invalid free() / delete / delete[] / realloc()
==15724== at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==15724== by 0x54B7A69: virFree (viralloc.c:582)
==15724== by 0x552DC90: virStorageAuthDefFree (virstoragefile.c:1549)
==15724== by 0x552F023: virStorageSourceClear (virstoragefile.c:2055)
==15724== by 0x552F054: virStorageSourceFree (virstoragefile.c:2067)
==15724== by 0x55556AA: virDomainDiskDefFree (domain_conf.c:1562)
==15724== by 0x5557ABE: virDomainDefFree (domain_conf.c:2547)
==15724== by 0x1B43CC42: qemuProcessStop (qemu_process.c:5918)
==15724== by 0x1B43BA2E: qemuProcessStart (qemu_process.c:5511)
==15724== by 0x1B48993E: qemuDomainObjStart (qemu_driver.c:7050)
==15724== by 0x1B489B9A: qemuDomainCreateWithFlags (qemu_driver.c:7104)
==15724== by 0x1B489C01: qemuDomainCreate (qemu_driver.c:7122)
==15724== Address 0x21cfbb90 is 0 bytes inside a block of size 48 free'd
==15724== at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==15724== by 0x54B7A69: virFree (viralloc.c:582)
==15724== by 0x552DC90: virStorageAuthDefFree (virstoragefile.c:1549)
==15724== by 0x12D1C8D4: virStorageTranslateDiskSourcePool (storage_driver.c:3475)
==15724== by 0x1B4396E4: qemuProcessPrepareDomain (qemu_process.c:4896)
==15724== by 0x1B43B880: qemuProcessStart (qemu_process.c:5466)
==15724== by 0x1B48993E: qemuDomainObjStart (qemu_driver.c:7050)
==15724== by 0x1B489B9A: qemuDomainCreateWithFlags (qemu_driver.c:7104)
==15724== by 0x1B489C01: qemuDomainCreate (qemu_driver.c:7122)
==15724== by 0x561CA97: virDomainCreate (libvirt-domain.c:6787)
==15724== by 0x12B6FD: remoteDispatchDomainCreate (remote_dispatch.h:4116)
==15724== by 0x12B61A: remoteDispatchDomainCreateHelper (remote_dispatch.h:4092)
The problem is, in virStorageTranslateDiskSourcePool disk
def->src->auth is freed, but the pointer is not set to NULL. So
later, when qemuProcessStop starts to free the domain definition,
virStorageAuthDefFree() tries to free the memory again, instead
of jumping out immediately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit cf0568b0af moved a bunch of functions from virNetDev
to the more specific virNetDevIP; however, not all of the
existing uses were moved properly, causing build failures on
FreeBSD.
Complete the transition to the new names and drop the
obsolete declarations from the header file while at it.
Not including the header causes
util/virnetdevip.c:520:5: error:
unknown type name 'virCommandPtr'; did you mean 'virCondPtr'?
virCommandPtr cmd = NULL;
^~~~~~~~~~~~~
and plenty more similar failures when compiling on FreeBSD.
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types, and 2) we can retain the info when set to
an invalid interface type all the way through to validation and report
a proper error, rather than just ignoring it (which is currently what
happens for many other type-specific settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
The peer attribute is used to set the property of the same name in the
interface IP info:
<interface type='ethernet'>
...
<ip family='ipv4' address='192.168.122.5'
prefix='32' peer='192.168.122.6'/>
...
</interface>
Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.
(This is an updated *re*-commit of commit 690969af, which was
subsequently reverted in commit 1d14b13f).
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: Laine Stump <laine@laine.org>
This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.
One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).
It makes more sense to have the logging at the lower level so other
callers can share the goodness.
While removing so much stuff from / touching so many lines in
lxcContainerRenameAndEnableInterfaces() (which used to have this
debug/error logging), label names were changed and it was updated to
use the now-more-common method of initializing ret to -1 (failure),
then setting to 0 right before the cleanup label.
virDomainNetIPInfoParseXML() and virDomainNetIPInfoFormat() are no
longer "unused", so we can now remove the "ATTRIBUTE_UNUSED" from
their definitions, since virDomainNetIPInfoFormat() is now the only
caller of virDomainNetIPsFormat() and virDomainNetRoutesFormat(),
those two functions can simply be subsumed into
virDomainNetIPInfoFormat().
libvirt's qemu driver doesn't have direct access to the config on the
guest side of a network interface, and currently doesn't have any
method in place to even inform the guest of the desired config. In the
future, an unenforceable attempt to set the guest-side IP info could
be made by adding a static host entry to the appropriate dnsmasq
configuration (or changing the default dhcp client address on the qemu
commandline for type='user' interfaces), or enhancing the guest agent
to allow setting an IP address, but for now it can't have any effect,
and we don't want to give the illusion that it does.
To prevent the "disappearance" of any existing configs with ip
address/route info (due to parser failure), this check is added in the
newly implemented qemuDomainDeviceDefValidate(), which is only called
when a domain is defined or started, *not* when it is reread from disk
at libvirtd startup.
a.k.a. <hostdev mode='capabilities' type='net'>.
This replaces the existing nips, ips, nroutes, and routes with a
single virNetDevIPInfo, and simplifies the code by calling that
object's parse/format/clear functions instead of open coding.
There are currently two places in the domain where this combination is
used, and there is about to be another. This patch puts them together
for brevity and uniformity.
As with the newly-renamed virNetDevIPAddr and virNetDevIPRoute
objects, the new virNetDevIPInfo object will need to be accessed by a
utility function that calls low level Netlink functions (so we don't
want it to be in the conf directory) and will be called from multiple
hypervisor drivers (so it can't be in any hypervisor directory); the
most appropriate place is thus once again the util directory.
The parse and format functions are in conf/domain_conf.c because only
the domain XML (i.e. *not* the network XML) has this exact combination
of IP addresses plus routes. Note that virDomainNetIPInfoFormat() will
end up being the only caller to virDomainNetRoutesFormat() and
virDomainNetIPsFormat(), so it will just subsume those functions in a
later patch, but we can't do that until they are no longer called.
(It would have been nice to include the interface name within the
virNetDevIPInfo object (with a slight name change), but that can't
be done cleanly, because in each case the interface name is provided
in a different place in the XML relative to the routes and IP
addresses, so putting it in this object would actually make the code
more confused rather than simpler).
These functions all need to be called from a utility function that
must be located in the util directory, so we move them all into
util/virnetdevip.[ch] now that it exists.
Function and struct names were appropriately changed for the new
location, but all code is unchanged aside from motion and renaming.
This patch splits virnetdev.[ch] into multiple files, with the new
virnetdevip.[ch] containing all the functions related to setting and
retrieving IP-related info for a device (both addresses and routes).
When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).
When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.
In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.
This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.
NB: I decided on this course of action after mentioning the
inconsistency here:
https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html
and getting encouragement do eliminate it in a later IRC discussion
with danpb.
in qemuConnectDomainXMLToNative. This function was only accounting for
about 1/10 of all the allocated items in the NetDef prior to memseting
it to all 0's. On top of that, it was going to great pains to learn
the name of the bridge device, but then never doing anything useful
with it (just putting it into data.ethernet.dev, which is *never* used
when building a qemu commandline). (I think this again all started off
as code with good intentions, but it was never completed, and instead
was just Frankensteinically cargo-culted into the odd mish mash we
have today).
The resulting code is much simpler, produces exactly the same output,
and doesn't leak memory.
This patch removes the expanded and duplicated code that all sprung
out of two well-intentioned-but-useless settings of
net->data.(bridge|ethernet).ipaddr.
qemu has never supported even a single IP address in the interface
config, much less a list of them. All of the instances of "clearing
out the IP addresses" that are now in this function originated with
commit d8dbd6 "Basic domain XML conversions for Xen/QEMU drivers" in
May 2009, but even then the single "ipaddr" in the struct for
type='ethernet' and type='bridge' wasn't used in the qemu driver (only
in xen and openvz). Since then anyone who added a new interface type
also tacked on another unnecessary clearing of ipaddr, and when it was
made into a list of IPs (so far supported only by the LXC driver) this
simple setting was turned into a loop (well, multiple loops) to clear
them all.
Commit c9a641 (first appearred in 1.2.12) added support for setting
the guest-side IP address of veth devices in lxc domains.
Unfortunately, it hardcoded the assumption that the proper prefix for
any IP address with no explicit prefix in the config should be "24";
that is only correct for class C IPv4 addresses, but not for any other
IPv4 address, nor for any IPv6 address.
The good news is that there is already a function in libvirt that will
determine the proper default prefix for any IP address. This patch
replaces the use of the ill-fated VIR_SOCKET_ADDR_DEFAULT_PREFIX with
calls to virSocketAddrGetIPPrefix().
lxcContainerRenameAndEnableInterfaces() isn't making a copy of the
interface's ifname_guest (into newname), it's just copying the pointer
to it. This means that when it later calls VIR_FREE(newname), it's
actually freeing up (and fortunately NULLing out, so at least we don't
try to access free'd memory) netDef->ifname_guest.
There are times when we don't have a netmask pointer to give to
virSocketAddrGetIPPrefix() (e.g. the IP addresses in domain interfaces
only have a prefix, no netmask), but it would have caused a segv if we
called it with NULL instead of a pointer to a netmask. This patch
qualifies the code that would use the netmask or address pointers to
check for NULL first.
Rearrange this function to be better organized and more correct:
* the error codes were changed from the incorrect INVALID_ARG to
XML_ERROR
* prefix still isn't required, but if present it must be valid or an
error will be logged.
* don't emit a debug log just because prefix is missing - this
is valid.
* group everything related to setting prefix in one place rather than
scattered through the function.
I'm tired of mistyping this all the time, so let's do it the same all
the time (similar to how we changed all "Pci" to "PCI" awhile back).
(NB: I've left alone some things in the esx and vbox drivers because
I'm unable to compile them and they weren't obviously *not* a part of
some API. I also didn't change a couple of variables named,
e.g. "somethingIptables", because they were derived from the name of
the "iptables" command)
These had been declared in conf/device_conf.h, but then used in
util/virnetdev.c, meaning that we had to #include conf/device_conf.h
in virnetdev.c (which we have for a long time said shouldn't be done.
This caused a bigger problem when I tried to #include util/virnetdev.h
in a file in src/conf (which is allowed) - for some reason the
"device_conf.h: File not found" error.
The solution is to move the data types and functions used in util
sources from conf to util. Some names were adjusted during the move
("virInterface" --> "virNetDevIf", and "VIR_INTERFACE" -->
"VIR_NETDEV_IF")
virNetDevLinkDump should have been in virnetlink.c, but that file
didn't exist yet when the function was created. It didn't really
matter until now - I found that having virnetlink.h included by
virnetdev.h caused build problems when trying to #include virnetdev.h
in a .c file in src/conf (due to missing directory in -I). Rather than
fix that to further institutionalize the incorrect placement of this
one function, this patch moves the function.
This patch enables admin socket creation in daemon's code, bumps the library
version in libvirt_admin_public.syms, and performs all necessary modifications
to our makefiles so that admin API can finally be included in the tarball,
and eventually become part of an rpm package (a patch later in this series).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
We need this because apply graphics functions is used on
update too. Also in case of NULL address resolve it to default
instead of error.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Move graphic device config to post parse. This way we
detect error on early stage and leverage checking on detach too.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
First we need to always set value to vz sdk parameter so
we can leverage setting code for device updates. This patch
resolves tristate default to off implicitly. This is easier
then extract default value from vz sdk itself. First current
default is off too, second this approach is already taken
for 'net->linkstate'.
Second dump this option in domain xml.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Current code that pass gateways to vz sdk is not suitable for
updates. If update has no gateways while we had them before
we need to pass "" for vz sdk gateways to reset old value.
The code definitely deserves its own function.
Drop checks that skip setting gateways if network address
is not set. Such a configuration is possible in vz sdk.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
This is as easy as moving disks checks from domain post
parse callback to device post parse callback.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Attach/detach functions for disk/net are quite trivial and
typically call a few functions in begin/end edit frame. Having
in mind update function too adding configuring for another
device (like graphics) will introduce 3 trivial functions more.
Let's replace current approach by attach/detach functions for
device.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
Current implementation works with hard disks only. This patch
adds support for any disk device (cdroms and hdds right now).
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
This code was added as a part of huge patch that moves driver
from working with prlctl to vz sdk so there is no good explanation
why this is done this way. The problem that it is not correct.
vz sdk cache mode parameter affects all domain disks while this hunk
resets its on every disk to a new value.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Some Intel processor families (e.g. the Intel Xeon processor E5 v3
family) introduced some PQos (Platform Qos) features, including CMT
(Cache Monitoring technology) and MBM (Memory Bandwidth Monitoring),
to monitor or control shared resource. This patch add them into x86
part of cpu_map.xml to be used for applications based on libvirt to
get cpu capabilities. For example, Nova in OpenStack schedules guests
based on the CPU features that the host has.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Both ARM and AArch64 drivers are exactly the same (modulo function
names). Let's use just one driver for all ARM architectures.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit e81de04c switched virNetDevTapGetRealDeviceName() to use
virDirOpen() instead of opendir(), however it mistakenly dropped
DIR *dirp declaration, so restore that to fix build.
Create a function to return a temporary file path to be used in a mkostemp
type call using the path to the stateDir + pool->def->name + vol->name
Signed-off-by: John Ferlan <jferlan@redhat.com>
The VIR_STORAGE_POOL_EVENT_REFRESHED constant does not
reflect any change in the lifecycle of the storage pool.
It should thus not be part of the storage pool lifecycle
event set, but rather be a top level event in its own
right. Thus we introduce VIR_STORAGE_POOL_EVENT_ID_REFRESH
to replace it.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The version field historically has been a 4 byte data; however, an upcoming
new type will use a 2 byte version. So let's adjust for that now.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to read 16 bits of data in the native format and convert add
the 16 bit macros to match existing 32 and 64 bit code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than pass authdef, pass the 'authdef->username' and the
'&authdef->secdef'
Note that a username may be NULL.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than assume/pass the protocol to the qemuDomainSecretPlainSetup
and qemuDomainSecretAESSetup, set and pass the secretUsageType based
on the src->protocol type. This will eventually be used by the
virSecretGetSecretString call
Signed-off-by: John Ferlan <jferlan@redhat.com>
The API virConnectGetMaxVcpus doesn't really reflect the actual usable number
of cpus as the maximum limits can be different for kvm and/or qemu. So update
the documentation to use virConnectGetDomainCapabilities() instead.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
This kvmGetMaxVCPUs() needs to be used at two different places
so move it to utils with appropriate name and mark it as private
global now.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Disallowing them broke a use case of testing multipath configurations
for storage. Originally this was added as it was impossible to
use certain /dev/disk-by... links but the disks worked properly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1349895
In the unlikely case the iSCSI session path exists, but does not
contain an entry starting with "target", we would silently use
an initialized value.
Rewrite the function to correctly report errors.
On PPC the legacy passthrough is not supported and only
VFIO is supported. So, the checks at places to confirm if the
host is passthrough capable checks only legacy, fix it. This
is seen at only one place now.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
It may cause unwanted behaviour (of course, is there any wanted one for
that case?) so we should rather disable the possibility of doing so.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1320893
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Unfortunately, we can't just call qemuDomainMachineIsPSeries()
here, because we don't have a virDomainDef instance; that said,
the open-coded check should match said function as closely as
possible.
Use it in virNetServerClientGetInfo to switch back to using
the URI-format (separated by ':') instead of the SASL format
(separated by ';').
Also use it in the error message reported by virNetServerAddClient.
This partially reverts commit 9b45c9f049.
It changed the default format of socket address from the one SASL
requires, but did not adjust all the callers.
It also removed the test coverage for it.
Revert most of the changes except the virSocketAddrFormatFull support
for URI-formatted strings.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1345743 while
reverting the format used by virt-admin's client-info command from
the URI one to the SASL one.
https://bugzilla.redhat.com/show_bug.cgi?id=1345743
The directories we iterate over are unlikely to contain any entries
starting with a dot, other than '.' and '..' which is already skipped
by virDirRead.
Move to virsecret.c and rename to virSecretLookupParseSecret. Also convert
to usage xmlNodePtr and virXMLPropString rather than virXPathString.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the enum into a new src/util/virsecret.h, rename it to be
virSecretLookupType. Add a src/util/virsecret.h in order to perform
a couple of simple operations on the secret XML and virSecretLookupTypeDef
for clearing and copying.
This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Every driver provides a refreshPool impl, and many other critical
places in the code unconditionally call it without checking if
it exists, so this check is pointless
One can not issue monitor commands manually during async calls thru
designated API while this could be useful for testing/debugging purposes.
qemuDomainQemuMonitorCommand uses job of type QEMU_JOB_MODIFY and any async
call disable parallel execution of this type of job. The only state that is
changed is taint variable. AFAIU the only place we can mess is resetting
taint flag in qemuProcessStop routine under some async job. But this can not
happen thanx to both virDomainObjIsActive check in qemuDomainQemuMonitorCommand
and resetting active status in qemuProcessStop before taint flag.
Change job type to QEMU_JOB_QUERY and thus make the API call available for
most of async jobs.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
This code was attempting to handle some implicit <console> XML
formatting for manually assembled DomainDef, since previously the
console<->serial compat copying was only done at XML parse time.
Nowadays it's done via virDomainDefPostParse ->
virDomainDefAddConsoleCompat, which all manual DomainDef builders
already call, so we can drop this workaround.
When domXML contains only <console type='pty'> and no corresponding
<serial>, the console is "stolen" [1] and used as the first <serial>
device. When this "stolen" console is accessed from the libxl driver
(in libxlConsoleCallback and libxlDomainOpenConsole), check if the
targetType is VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL, and use the
"stolen" device in def->serials[0] instead. Prior to this change,
creating a domain with input XML containing only a <console> device
and subsequently attempting to access its console with
'virsh console' would fail
error: internal error: character device <null> is not using a PTY
[1] See comments associated with virDomainDefAddConsoleCompat() in
$LIBVIRT-SRC/src/conf/domain_conf.c:
Several places in the code update qemuMonitorMigrationParams structure
and qemuMigrationSetParams is then used to set them all at once.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We should not require any parameters to be present. After all we have
the *_set bools to express that some parameters were not set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Checking whether the function has anything to do is better done in the
function rather then requiring callers to do that.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Since virQEMUCapsNewForBinaryInternal was introduced,
virQEMUCapsNewForBinary is no longer used outside qemu_capabilities.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Allow gathering available vcpu ids, their state and offlinability via
the qemu guest agent. The maximum id was chosen arbitrarily and ought
to be enough for everybody.
Documentation for the "guest-set-vcpus" command describes a proper
algorithm how to set vcpus. This patch makes the following changes:
- state of cpus that has not changed is not updated
- if the command was partially successful the command is re-tried with
the rest of the arguments to get a proper error message
- code is more robust against malicious guest agent
- fix testsuite to the new semantics
To allow finer-grained control of vcpu state using guest agent this API
can be used to individually set the state of the vCPU.
This will allow to better control NUMA enabled guests and/or test
various vCPU configurations.
Add a rather universal API implemented via typed params that will allow
to query the guest agent for the state and possibly other aspects of
guest vcpus.
Since it's rather tedious to write the dispatchers for functions that
return an array of typed parameters (which are rather common) let's add
some rpcgen code to generate them.
Create a helper virStorageBackendCreateQemuImgSetOptions to set either
the qemu-img -o options or the previous mechanism using -F
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since we support QEMU 0.12 and later, checking for support of specific flags
added prior to that isn't necessary.
Thus start with the base of having the "-o options" available for the
qemu-img create option and then determine whether we have the compat
option for qcow2 files (which would be necessary up through qemu 2.0
where the default changes to compat 0.11).
Adjust test to no long check for NONE and FLAG options as well was removing
results of tests that would use that option.
Signed-off-by: John Ferlan <jferlan@redhat.com>
So far this is only useful for recalculating NUMA memory size,
which this function cannot parse.
This will let us generate USB addresses based on this flag.
In the case of chassisNr (used to set chassis_nr of a pci-bridge
controller), 0 is reserved for / used by the pci[e]-root bus. In the
base of busNr, a value of 0 would mean that the root bus had no places
available to plug in new buses, including the pxb itself (the
documentation I wrote for pxb even noted the limit of busNr as 1.254).
NB: oddly, the "chassis" attribute, which is used for pcie-root-port
and pcie-switch-downstream-port *can* be set to 0, since it's the
combination of {chassis, slot} that needs to be unique, not chassis by
itself (and slot 0 of pcie-root is reserved, while pcie-*-port can use
*only* slot 0).
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1342962
Since introduction of the DAC security driver we've documented that
seclabels with a leading + can be used with numerical uid. This would
not work though with the rest of libvirt if the uid was not actually
used in the system as we'd fail when trying to get a list of
supplementary groups for the given uid. Since a uid without entry in
/etc/passwd (or other user database) will not have any supplementary
groups we can treat the failure to obtain them as such.
This patch modifies virGetGroupList to not report the error for missing
users and makes it return an empty list or just the group specified in
@gid.
All callers will grant less permissions to a user in case of failure of
this function and thus this change is safe.
When loading status XMLs with following graphics definition:
<graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1' fromConfig='1'/>
<image compression='off'/>
</graphics>
libvirtd would leak a few bytes:
10 bytes in 1 blocks are definitely lost in loss record 71 of 1,127
at 0x4C2C000: malloc (vg_replace_malloc.c:299)
by 0x6789298: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
by 0x552AB0A: virXMLPropString (virxml.c:479)
by 0x5539536: virDomainGraphicsListensParseXML (domain_conf.c:11171)
by 0x553DD5E: virDomainGraphicsDefParseXMLSpice (domain_conf.c:11414)
by 0x553DD5E: virDomainGraphicsDefParseXML (domain_conf.c:11749)
by 0x5566061: virDomainDefParseXML (domain_conf.c:16939)
by 0x556953F: virDomainObjParseXML (domain_conf.c:17348)
by 0x556953F: virDomainObjParseNode (domain_conf.c:17513)
by 0x5569902: virDomainObjParseFile (domain_conf.c:17532)
by 0x5571E02: virDomainObjListLoadStatus (virdomainobjlist.c:514)
by 0x5571E02: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
by 0x26E0BDC8: qemuStateInitialize (qemu_driver.c:911)
by 0x55B1FDB: virStateInitialize (libvirt.c:770)
by 0x122039: daemonRunStateInit (libvirtd.c:960)
This will be used for the caller that needs to specify a separator.
Currently identical to virBitmapParse.
Also change one test case to use the new function.
The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.
However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.
Avoid it completely, like it's already happening for q35.
Commit 2a58ed0b added support for creating guests with USB
hostdevs. Commit fc21d10 later added support for hotplut of
USB hostdevs. Advertise support for USB hostdevs in the
domcapabilities.
In addition add the appropriate caps for USB support on
domaincapstest when libvirt is built on a Xen with
LIBXL_HAVE_PVUSB. Otherwise domaincapstest would fail i.e.
testing the wrong domain capabilities.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.
Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.
This is going to be important later when we received
DEVICE_DELETED event on the qemu monitor. If we do,
virDomainDefFindDevice() is called to find the device for given
device alias in the virDomainDef tree. When we enable removal for
redirdevs we need to include them in the lookup process too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Basically, there are just two functions introduced here:
virDomainRedirdevDefFind which looks up given redirdev in domain
definition, and virDomainRedirdevDefRemove which removes the
device at given index in the array of devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
There's currently just one limitation: redirdevs that want to go
on USB bus require a USB controller, surprisingly.
At the same time, since I'm using virDomainDefHasUSB() in this
new validator function, it has to be moved a few lines up and
also its header needed to be changed a bit: it is now taking a
const pointer to domain def since it's not changing anything in
there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Our current detection code uses just the number of CPU features which
need to be added/removed from the CPU model to fully describe the CPUID
data. The smallest number wins. But this may sometimes generate wrong
results as one can see from the fixed test cases. This patch modifies
the algorithm to prefer the CPU model with matching signature even if
this model results in a longer list of additional features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The CPU model was implemented in QEMU by commit f6f949e929.
The change to i7-5600U is wrong since it's a 5th generation CPU, i.e.,
Broadwell rather than Skylake, but that's just the result of our CPU
detection code (which is fixed by the following commit).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
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.
