We call VIR_INSERT_ELEMENT_INPLACE either with 0 (for primary video)
or def->nvideos (for the rest).
Use a variable with more semantic name, since j is usually used
for iterating.
We start with both i and def->nvideos at 0 and increment both
after every successful iteration.
Use i directly, instead of passing the def->nvideos value through j.
Commit 119cd06 started setting the primary bool for the first
user-specified video even if user omitted the 'primary' attribute.
However this was done before the addition of the implicit device.
This broke startup of transient qemu domains with no <video>:
https://bugzilla.redhat.com/show_bug.cgi?id=1325757
Move this default to virDomainDefPostParseInternal,
after the addition of the implicit video device, to catch the implicit
video as well.
Quite straigthforward as vz sdk memory setting function makes
just what we want to that is set "amount of physical memory
allocated to a domain".
'useflags' is introduced for non flag function implementation.
We can't just use combination of flags like "live | config" or
we fail for inactive domains. Other combinations have drawbacks
too.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Actually this is not pure refactoring. Part of common code is
replaced with virDomainObjUpdateModificationImpact and this
a good replacement. It includes removed check of inactive
domain and active flags set. Additionally we resolve
current flag in accordance with current state of domain.
Thus it becames possible to attach/detach devices for
inactive domains if this flag is set.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Commit dc98a5bc refactored the code a lot and forget about checking if
listen attribute is specified. This ensures that listen attribute and
first listen element are compared only if both exist.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
fdstream.c: In function 'virFDStreamWrite':
fdstream.c:390:29: error: logical 'or' of equal expressions [-Werror=logical-op]
if (errno == EAGAIN || errno == EWOULDBLOCK) {
^~
Fedora rawhide now uses gcc 6.0 and there is a bug with -Wlogical-op
producing false warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Use GCC pragma push/pop and ignore -Wlogical-op for GCC that supports
push/pop pragma and also has this bug.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Replace the nonsensical debug statement by adding the expected event
code into the existing debug statement.
Since the monitor code always notifies the agent on guest
reboot/shutdown even if that was not initiated by the agent the warning
emitted later is bogus and pollutes the logs in such cases. Delete it
and keep just the original debug message where this info can be
inferred.
Move including of gnutls/gnutls.h in qemu/qemu_domain.c under the
"ifdef WITH_GNUTLS" check because otherwise it fails like this:
CC qemu/libvirt_driver_qemu_impl_la-qemu_domain.lo
qemu/qemu_domain.c:50:10: fatal error: 'gnutls/gnutls.h' file not found
in case if gnutls is not installed on the system.
Some places already check for "virt-" prefix as well as plain "virt".
virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices
having assigned the same unnumbered "pci" alias.
Add a test for the "virt-2.6" machine type which also omits the
<model type='virtio'/> in <interface>, to check if
qemuDomainDefaultNetModel works too.
https://bugzilla.redhat.com/show_bug.cgi?id=1325085
virSocketAddrFormat() wants a single pointer, not a double pointer.
Fixes the following compilation error on FreeBSD:
util/virnetdev.c:1448:72: error: incompatible pointer types passing
'virSocketAddr **' to parameter of type 'const virSocketAddr *';
remove & [-Werror,-Wincompatible-pointer-types]
if (VIR_SOCKET_ADDR_VALID(peer) && !(peerstr = virSocketAddrFormat(&peer)))
^~~~~
./util/virsocketaddr.h:92:48: note: passing argument to parameter 'addr' here
char *virSocketAddrFormat(const virSocketAddr *addr);
^
FreeBSD lacks ENODATA, and viruuid.c redefines it to EIO, but it's not
actually using it. On the other hand, we have virrandom.c that's using
ENODATA. So make this re-definition common by moving it to internal.h,
so all the current and possible future users don't need to care about
that.
In the latest libxenlight code, libxl_domain_create_restore accepts a
new argument. Update libvirt's libxl driver for that. Use the macro
provided by libxenlight to detect which version should be used.
The new parameter (send_back_fd) is set to -1 because libvirt provides
no such fd.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Message-id: 1459866012-27081-1-git-send-email-wei.liu2@citrix.com
Our use of gnutls_rnd(), introduced with commit ad7520e8, is
conditional to the availability of the <gnutls/crypto.h> header
file.
Such check, however, turns out not to be strict enough, as there
are some versions of GnuTLS (eg. 2.8.5 from CentOS 6) that provide
the header file, but not the function itself, which was introduced
only in GnuTLS 2.12.0.
Introduce an explicit check for the function.
As usual we try to deal correctly with vz domains that were
created by other means and thus can have all range of SDK domain
parameters. If vz domain boot order can't be represented
in libvirt os boot section let's give warning and make os boot section
represent SDK to some extent.
1. Os boot section supports up to 4 boot devices. Here we just
cut SDK boot order up to this limit. Not too bad.
2. If there is a floppy in boot order let's just skip it.
Anyway we don't show it in the xml. Not too bad too.
3. SDK boot order with unsupported disks order. Say we have "hdb, hda" in
SDK. We can not present this thru os boot order. Well let's just
give warning but leave double <boot dev='hd'/> in xml. It's
kind of misleading but we warn you!
SDK boot order have an extra parameters 'inUse' and 'sequenceIndex'
which makes our task more complicated. In realitly however 'inUse'
is always on and 'sequenceIndex' is not less than 'boot position index'
which simplifies out task back again! To be on a safe side let's explicitly
check for this conditions!
We have another exercise here. We want to check for unrepresentable
condition 3 (see above). The tricky part is that in contrast to
domains defined thru this driver 3-rd party defined domains can
have device ordering different from default. Thus we need
some id to check that N-th boot disk of os boot section is same as
N-th boot disk of SDK boot. This is what prlsdkBootOrderCheck
for. It uses disks sources paths as id for disks and iface names
for network devices.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
We want to report boot order in dumpxml for vz domains.
Thus we want disks devices to be sorted in output compatible with boot
ordering specification. So let's just use virDomainDiskInsert
which makes appropriate sorting.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
The patch makes some refactoring of the existing code. Current boot order spec code
makes very simple thing in somewhat obscure way. In case of VMs
it sets the first hdd as the only bootable device. In case of CTs it
doesn't touch the boot order at all if one of the filesystems is mounted to root.
Otherwise like in case of VMs it sets the first hdd as the only bootable
device and additionally sets this device mount point to root. Refactored
code makes all this explicit.
The actual boot order support is simple. Common libvirt domain xml parsing
code makes the exact ordering of disks devices as described in docs
for boot ordering (disks are sorted by bus order first, device target
second. Bus order is the order of disk buses appearence in original
xml. Device targets order is alphabetical). We add devices in the
same order and SDK designates device indexes sequentially for each
device type. Thus device index is equal to its boot index. For
example N-th cdrom in boot specification refers to sdk cdrom with
it's device index N.
If there is no boot spec in xml the parsing code will add <boot dev='hdd'>
for HVMs automatically and we backward compatibly set fist hdd as
bootable.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
The new perf code didn't bother to clear a pointer in 'priv' causing a
double free or other memory corruption goodness if a VM failed to start.
Clear the pointer after freeing the memory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324757
For device hotplug, the new alias ID needs to be checked in the list
rather than using the count of devices. Unplugging a device that is not
last in the array will make further hotplug impossible due to alias
collision.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324551
For device hotplug, the new alias ID needs to be checked in the list
rather than using the count of devices. Unplugging a device that is not
last in the array will make further hotplug impossible due to alias
collision.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324551
Commit id 'fb2bd208' essentially copied the qemuGetSecretString
creating an libxlGetSecretString. Rather than have multiple copies
of the same code, create src/secret/secret_util.{c,h} files and
place the common function in there.
Modify the the build in order to build the module as a library
which is then pulled in by both the qemu and libxl drivers for
usage from both qemu_command.c and libxl_conf.c
If the -object secret capability exists, then get the path to the
masterKey file and provide that to qemu. Checking for the existence
of the file before passing to qemu could be done, but causes issues
in mock test environment.
Since the qemuDomainObjPrivate is not available when building the
command line, the qemuBuildHasMasterKey API will have to suffice
as the primary arbiter for whether the capability exists in order
to find/return the path to the master key for usage.
Created the qemuDomainGetMasterKeyAlias API which will be used by
later patches to define the 'keyid' (eg, masterKey) to be used by
other secrets to provide the id to qemu for the master key.
Add a masterKey and masterKeyLen to _qemuDomainObjPrivate to store a
random domain master key and its length in order to support the ability
to encrypt/decrypt sensitive data shared between libvirt and qemu. The
key will be base64 encoded and written to a file to be used by the
command line building code to share with qemu.
New API's from this patch:
qemuDomainGetMasterKeyFilePath:
Return a path to where the key is located
qemuDomainWriteMasterKeyFile: (private)
Open (create/trunc) the masterKey path and write the masterKey
qemuDomainMasterKeyReadFile:
Using the master key path, open/read the file, and store the
masterKey and masterKeyLen. Expected use only from qemuProcessReconnect
qemuDomainGenerateRandomKey: (private)
Generate a random key using available algorithms
The key is generated either from the gnutls_rnd function if it
exists or a less cryptographically strong mechanism using
virGenerateRandomBytes
qemuDomainMasterKeyRemove:
Remove traces of the master key, remove the *KeyFilePath
qemuDomainMasterKeyCreate:
Generate the domain master key and save the key in the location
returned by qemuDomainGetMasterKeyFilePath.
This API will first ensure the QEMU_CAPS_OBJECT_SECRET is set
in the capabilities. If not, then there's no need to generate
the secret or file.
The creation of the key will be attempted from qemuProcessPrepareHost
once the libDir directory structure exists.
The removal of the key will handled from qemuProcessStop just prior
to deleting the libDir tree.
Since the key will not be written out to the domain object XML file,
the qemuProcessReconnect will read the saved file and restore the
masterKey and masterKeyLen.
Using the existing virUUIDGenerateRandomBytes, move API to virrandom.c
rename it to virRandomBytes and add it to libvirt_private.syms.
This will be used as a fallback for generating a domain master key.
Add a capability bit for the qemu secret object.
Adjust the 2.6.0-1 caps/replies to add the secret object. For the
.replies it's take from the '{"execute":"qom-list-types"}' output.
When a hostdev is attached to the guest (and removed from the host),
the order of operations is call qemuHostdevPreparePCIDevices to remove
the device from the host, call qemuSetupHostdevCgroup to setup the cgroups,
and virSecurityManagerSetHostdevLabel to set the labels.
When the device is removed from the guest, the code didn't use the
reverse order leading to possible issues (especially if the path to
the device no longer exists). This patch will move the call to
qemuTeardownHostdevCgroup to prior to reattaching the device to
the host.
When a hostdev is attached to the guest (and removed from the host),
the order of operations is call qemuHostdevPreparePCIDevices to remove
the device from the host, call qemuSetupHostdevCgroup to setup the cgroups,
and virSecurityManagerSetHostdevLabel to set the labels.
When the device is removed from the guest, the code didn't use the
reverse order leading to possible issues (especially if the path to
the device no longer exists). This patch will move the call to
virSecurityManagerRestoreHostdevLabel to prior to reattaching the
device to the host.
Commit id '3992ff14' added the prototype for networkGetActualType
with 1 parameter, but added 2 ATTRIBUTE_NONNULL's (assume from a
cut-n-paste), just remove (2).
