John Ferlan [Thu, 15 Dec 2016 11:39:42 +0000 (06:39 -0500)]
storage: Clean up logical pool devices on build failure
If the build fails, then we need to ensure that we've run pvremove
on any devices which we've run pvcreate on; otherwise, a subsequent
build could fail since running pvcreate twice on a device requires
special force arguments.
John Ferlan [Thu, 15 Dec 2016 20:45:01 +0000 (15:45 -0500)]
storage: Adjust disk label found to match labels
Currently as long as the disk is formatted using a known parted format
type, the algorithm is happy to continue. However, that leaves a scenario
whereby a disk formatted using "pc98" could be used by a pool that's defined
using "dvh" (or vice versa). Alter the check to be match and different
and adjust the caller.
John Ferlan [Wed, 14 Dec 2016 23:34:24 +0000 (18:34 -0500)]
storage: Move and rename disk backend label checking
Rather than have the Disk code having to use PARTED to determine if
there's something on the device, let's use the virStorageBackendDeviceProbe.
and only fallback to the PARTED probing if the BLKID code isn't built in.
This will also provide a mechanism for the other current caller (File
System Backend) to utilize a PARTED parsing algorithm in the event that
BLKID isn't built in to at least see if *something* exists on the disk
before blindly trying to use. The PARTED error checking will not find
file system types, but if there is a partition table set on the device,
it will at least cause a failure.
Move virStorageBackendDiskValidLabel and virStorageBackendDiskFindLabel
to storage_backend and rename/rework the code to fit the new model.
Update the virsh.pod description to provide a more generic description
of the process since we could now use either blkid or parted to find
data on the target device.
John Ferlan [Wed, 14 Dec 2016 23:03:20 +0000 (18:03 -0500)]
storage: Add writelabel bool for virStorageBackendDeviceProbe
It's possible that the API could be called from a startup path in
order to check whether the label on the device matches what our
format is. In order to handle that condition, add a 'writelabel'
boolean to the API in order to indicate whether a write or just
read is about to happen.
This alters two "error" conditions that would care about knowing.
John Ferlan [Wed, 14 Dec 2016 22:45:20 +0000 (17:45 -0500)]
storage: Add partition type checks for BLKID probing
A device may be formatted using some sort of disk partition format type.
We can check that using the blkid_ API's as well - so alter the logic to
allow checking the device for both a filesystem and a disk partition.
Commit id '27758859' introduced the "NO_OVERWRITE" flag check for
file system backends; however, the implementation, documentation,
and algorithm was inconsistent. For the "flag" description for the
API the flag was described as "Do not overwrite existing pool";
however, within the storage backend code the flag is described
as "it probes to determine if filesystem already exists on the
target device, renurning an error if exists".
The code itself was implemented using the paradigm to set up the
superblock probe by creating a filter that would cause the code
to only search for the provided format type. If that type wasn't
found, then the algorithm would return success allowing the caller
to format the device. If the format type already existed on the
device, then the code would fail indicating that the a filesystem
of the same type existed on the device.
The result is that if someone had a file system of one type on the
device, it was possible to overwrite it if a different format type
was specified in updated XML effectively trashing whatever was on
the device already.
This patch alters what NO_OVERWRITE does for a file system backend
to be more realistic and consistent with what should be expected when
the caller requests to not overwrite the data on the disk.
Rather than filter results based on the expected format type, the
code will allow success/failure be determined solely on whether the
blkid_do_probe calls finds some known format on the device. This
adjustment also allows removal of the virStoragePoolProbeResult
enum that was under utilized.
If it does find a formatted file system different errors will be
generated indicating a file system of a specific type already exists
or a file system of some other type already exists.
In the original virsh support commit id 'ddcd5674', the description
for '--no-overwrite' within the 'pool-build' command help output
has an ambiguous "of this type" included in the short description.
Compared to the longer description within the "Build a given pool."
section of the virsh.pod file it's more apparent that the meaning
of this flag would cause failure if a probe of the target already
has a filesystem.
So this patch also modifies the short description to just be the
antecedent of the 'overwrite' flag, which matches the API description.
This patch also modifies the grammar in virsh.pod for no-overwrite
as well as reworking the paragraph formats to make it easier to read.
qemuDomainCreateNamespace: move mkdir to qemuDomainBuildNamespace
Again, there is no need to create /var/lib/libvirt/$domain.*
directories in CreateNamespace(). It is sufficient to create them
as soon as we need them which is in BuildNamespace. This way we
don't leave them around for the whole lifetime of domain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
qemuDomainGetPreservedMounts: Do not special case /dev
The c1140eb9e got me thinking. We don't want to special case /dev
in qemuDomainGetPreservedMounts(), but in all other places in the
code we special case it anyway. I mean,
/var/run/libvirt/$domain.dev path is constructed separately just
so that it is not constructed here. It makes only a little sense
(if any at all).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If something goes wrong in this function we try a rollback. That
is unlink all the directories we created earlier. For some weird
reason unlink() was called instead of rmdir().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 15 Dec 2016 15:47:15 +0000 (16:47 +0100)]
qemu: Use transactions from security driver
So far if qemu is spawned under separate mount namespace in order
to relabel everything it needs an access to the security driver
to run in that namespace too. This has a very nasty down side -
it is being run in a separate process, so any internal state
transition is NOT reflected in the daemon. This can lead to many
sleepless nights. Therefore, use the transaction APIs so that
libvirt developers can sleep tight again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 14 Dec 2016 09:14:49 +0000 (10:14 +0100)]
security driver: Introduce transaction APIs
With our new qemu namespace code in place, the relabelling of
devices is done not as good is it could: a child process is
spawned, it enters the mount namespace of the qemu process and
then runs desired API of the security driver.
Problem with this approach is that internal state transition of
the security driver done in the child process is not reflected in
the parent process. While currently it wouldn't matter that much,
it is fairly easy to forget about that. We should take the extra
step now while this limitation is still fresh in our minds.
Three new APIs are introduced here:
virSecurityManagerTransactionStart()
virSecurityManagerTransactionCommit()
virSecurityManagerTransactionAbort()
The Start() is going to be used to let security driver know that
we are starting a new transaction. During a transaction no
security labels are actually touched, but rather recorded and
only at Commit() phase they are actually updated. Should
something go wrong Abort() aborts the transaction freeing up all
memory allocated by transaction.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The code at the very bottom of the DAC secdriver that calls
chown() should be fine with read-only data. If something needs to
be prepared it should have been done beforehand.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Fri, 21 Oct 2016 09:50:15 +0000 (11:50 +0200)]
qemu: Use virtio-pci by default for mach-virt guests
virtio-pci is the way forward for aarch64 guests: it's faster
and less alien to people coming from other architectures.
Now that guest support is finally getting there (Fedora 24,
CentOS 7.3, Ubuntu 16.04 and Debian testing all support
virtio-pci out of the box), we'd like to start using it by
default instead of virtio-mmio.
Users and applications can already opt-in by explicitly using
<address type='pci'/>
inside the relevant elements, but that's kind of cumbersome and
requires all users and management applications to adapt, which
we'd really like to avoid.
What we can do instead is use virtio-mmio only if the guest
already has at least one virtio-mmio device, and use virtio-pci
in all other situations.
That means existing virtio-mmio guests will keep using the old
addressing scheme, and new guests will automatically be created
using virtio-pci instead. Users can still override the default
in either direction.
Existing tests such as aarch64-aavmf-virtio-mmio and
aarch64-virtio-pci-default already cover all possible
scenarios, so no additions to the test suites are necessary.
Peter Krempa [Mon, 9 Jan 2017 12:50:26 +0000 (13:50 +0100)]
qemu: setvcpus: Properly coldplug vcpus when hotpluggable vcpus are present
When coldplugging vcpus to a VM that already has a few hotpluggable
vcpus the code might generate invalid configuration as
non-hotpluggable cpus need to be clustered starting from vcpu 0.
This fix forces the added vcpus to be hotpluggable in such case.
Fixes a corner case described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1370357
Laine Stump [Tue, 3 Jan 2017 19:41:33 +0000 (14:41 -0500)]
docs: fix list of domain states in virsh manpage
The virsh manpage lists "shutdown" and "dying" as two of the possible
domain states that could be listed in the output of the "virsh list"
command. However, a domain that is being shutdown will be listed as
"in shutdown", and the "dying" state doesn't even exist (and never
has, as far as I can tell from looking through git history - it was
shown in the original import of the virsh.pod file in 2006; there was
no VIR_DOMAIN_DYING state then, there wasn't one when those lines of
virsh.pod were tweaked in 2008, and there still isn't one
today. Apparently it was just something that sounded like a good idea
to someone at some time, but was never implemented...)
Nitesh Konkar [Thu, 5 Jan 2017 06:05:10 +0000 (11:35 +0530)]
docs: Reword virsh manpage for --uuid --name --table options
The virsh manpage lists options --uuid and --name as
mutually exclusive along option --table when actually
the option --table is mutually exclusive and can't go
with options --uuid and/or --name. This patch rewords the
virsh manpage to state the correct meaning.
Nitesh Konkar [Wed, 28 Dec 2016 11:36:22 +0000 (17:06 +0530)]
virsh: Display perf enabled/disabled message for set operations
When setting perf events, the enabled/disabled perf events are not
listed. Since we know which events were changed it's possible to
print out the values on successful set, such as :
Created a helper to print the messages - use the vshPrintExtra to
adhere to the --quiet|-q option being set by some script. This will
cause the get code to print nothing, but will return success/failure.
conf: simplify internal virSecretDef handling of usage
The public virSecret object has a single "usage_id" field
but the virSecretDef object has a different 'char *' field
for each usage type, but the code all assumes every usage
type has a corresponding single string. Get rid of the
pointless union in virSecretDef and just use "usage_id"
everywhere. This doesn't impact public XML format, only
the internal handling.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
remote: fix struct for device removal failed event
The handler for the device removal failed event was using
the struct for the device added event. Fortunately the
layout was the same, so this was harmless.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When changing the metadata via virDomainSetMetadata, we now
emit an event to notify the app of changes. This is useful
when co-ordinating different applications read/write of
custom metadata.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
lxc: ensure libvirt_lxc and qemu-nbd move into systemd machine slice
Currently when spawning containers with systemd, the container PID 1
will get moved into the systemd machine slice. Libvirt then manually
moves the libvirt_lxc and qemu-nbd processes into the cgroups associated
with the slice, but skips the systemd controller cgroup. This means that
from systemd's POV, libvirt_lxc and qemu-nbd are still part of the
libvirtd.service unit.
On systemctl daemon-reload, it will notice that libvirt_lxc & qemu-nbd
are in the libvirtd.service unit for the systemd controller, but in the
machine cgroups for resources. Systemd will thus move them back into
the libvirtd.service resource cgroups next time libvirtd is restarted.
This causes libvirtd to kill off the container due to incorrect cgroup
placement.
The solution is to ensure that when moving libvirt_lxc & qemu-nbd, we
also move the systemd cgroup controller placement. Normally this is
not something we ever want todo, but this is a special case as we are
intentionally wanting to move them to a different systemd unit.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
virutil: Provide non-linux impl for virGetFCHostNameByFabricWWN
Currently, there's only linux implementation for
virGetFCHostNameByFabricWWN(). Since the symbol is exported in
our private symbols we ought to have implementation for other
platforms too. This also triggers compilation error on FreeBSD:
../src/.libs/libvirt_driver_storage_impl.a(libvirt_driver_storage_impl_la-storage_backend_scsi.o): In function `createVport':
/usr/home/jenkins/libvirt-master/systems/libvirt-freebsd/build/src/../../src/storage/storage_backend_scsi.c:740: undefined reference to `virGetFCHostNameByFabricWWN'
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Maxim Nestratov [Fri, 9 Dec 2016 14:28:06 +0000 (17:28 +0300)]
tests: Add "no-kvm-pit-device" testcase
Add a test case for when the QEMU_CAPS_NO_KVM_PIT capability is set.
This capability is mutually exclusive to QEMU_CAPS_KVM_PIT_TICK_POLICY
and results in the same output regardless of whether "discard" or
"delay" was specified in the guest XML for 'tickpolicy'.
Maxim Nestratov [Fri, 9 Dec 2016 14:28:04 +0000 (17:28 +0300)]
qemu: Fix pit timer tick policy=delay
By a mistake, for the VIR_DOMAIN_TIMER_TICKPOLICY_DELAY qemu
command line creation, 'discard' was used instead of 'delay'
in commit id '1569fa14'.
Test "kvm-pit-delay" is fixed accordingly to show the correct
option being generated.
Remove the (now) redundant kvm-pit-device tests. As it turns
out there is no need to specify both QEMU_CAPS_NO_KVM_PIT and
QEMU_CAPS_KVM_PIT_TICK_POLICY since they are mutually exclusive
and "kvm-pit-device" becomes just the same as "kvm-pit-delay".
As it turns out using only the 'parent' to achieve the goal of a
consistent vHBA parent has issues with reboots where the scsi_hostX
parent could change to scsi_hostY causing either failure to create
the vHBA or usage of the wrong HBA for our vHBA.
Thus add the ability to search for the "parent" by the parent wwnn/
wwpn values or just a fabric_name if someone only cares to ensure
usage of the same SAN for the vHBA.
John Ferlan [Thu, 17 Nov 2016 22:48:35 +0000 (17:48 -0500)]
conf: Add more fchost search fields for storage pool vHBA creation
Add new fields to the fchost structure to allow creation of a vHBA via
the storage pool when a parent_wwnn/parent_wwpn or parent_fabric_wwn is
supplied in the storage pool XML.
When creating a vHBA, the process is to feed XML to nodeDeviceCreateXML
that lists the <parent> scsi_hostX to use to create the vHBA. However,
between reboots, it's possible that the <parent> changes its scsi_hostX
to scsi_hostY and saved XML to perform the creation will either fail or
create a vHBA using the wrong parent.
So add the ability to provide "wwnn" and "wwpn" or "fabric_wwn" to
the <parent> instead of a name of the scsi_hostN that is the parent.
The allowed XML will thus be:
<parent>scsi_host3</parent> (current)
or
<parent wwnn='$WWNN' wwpn='$WWPN'/>
or
<parent fabric_wwn='$WWNN'/>
Using the wwnn/wwpn or fabric_wwn ensures the same 'scsi_hostN' is
selected between hardware reconfigs or host reboots. The fabric_wwn
Using the wwnn/wwpn pair will provide the most specific search option,
while fabric_wwn will at least ensure usage of the same SAN, but maybe
not the same scsi_hostN.
This patch will add the new fields to the nodedev.rng for input purposes
only since the input XML is essentially thrown away, no need to Format
the values since they'd already be printed as part of the scsi_host
data block.
New API virNodeDeviceGetParentHostByWWNs will take the parent "wwnn" and
"wwpn" in order to search the list of devices for matching capability
data fields wwnn and wwpn.
New API virNodeDeviceGetParentHostByFabricWWN will take the parent "fabric_wwn"
in order to search the list of devices for matching capability data field
fabric_wwn.
qemu: command: Support new cpu feature argument syntax
Qemu has abandoned the +/-feature syntax in favor of key=value. Some
architectures (s390) do not support +/-feature. So we update libvirt to handle
both formats.
If we detect a sufficiently new Qemu (indicated by support for qmp
query-cpu-model-expansion) we use key=value else we fall back to +/-feature.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Jiri Denemark [Fri, 6 Jan 2017 07:52:22 +0000 (08:52 +0100)]
qemu-caps: Get host model directly from Qemu when available
When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Jason J. Herne [Sun, 18 Dec 2016 19:22:22 +0000 (14:22 -0500)]
s390-cpu: Remove nodeData and decode
On s390, the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: Jiri Denemark <jdenemar@redhat.com>
Jason J. Herne [Sun, 18 Dec 2016 19:22:21 +0000 (14:22 -0500)]
s390: Cpu driver support for update and compare
Implement compare for s390. Required to test the guest against the host for
guest cpu model runnability checking. We always return IDENTICAL to bypass
Libvirt's checking. s390 will rely on Qemu to perform the runnability checking.
Implement update for s390. required to support use of cpu "host-model" mode.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Acked-by: Jiri Denemark <jdenemar@redhat.com>
qemuDomainGetPreservedMounts: Fetch list of /dev/* mounts dynamically
With my namespace patches, we are spawning qemu in its own
namespace so that we can manage /dev entries ourselves. However,
some filesystems mounted under /dev needs to be preserved in
order to be shared with the parent namespace (e.g. /dev/pts).
Currently, the list of mount points to preserve is hardcoded
which ain't right - on some systems there might be less or more
items under real /dev that on our list. The solution is to parse
/proc/mounts and fetch the list from there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Our STREQ_NULLABLE and STRNEQ_NULLABLE macros are too
complicated. This was a result of some broken version of gcc.
However, that is long gone and therefore we can simplify the
macros.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
qemu: snapshot: restart CPUs when recover from interrupted snapshot job
If we restart libvirtd while VM was doing external memory snapshot, VM's
state be updated to paused as a result of running a migration-to-file
operation, and then VM will be left as paused state. In this case we must
restart the VM's CPUs to resume it.
John Ferlan [Fri, 18 Nov 2016 12:44:52 +0000 (07:44 -0500)]
scsi: Change order of checks in createVport
Move the check for an already existing vHBA to the top of the function.
No sense in first decoding a provided parent if the next thing we're going
to do is fail if a provided wwnn/wwpn already exists.
John Ferlan [Wed, 16 Nov 2016 22:50:09 +0000 (17:50 -0500)]
nodedev: Add ability to find a vport capable vHBA
If a <parent> is not supplied in the XML used to create a non-persistent
vHBA, then instead of failing, let's try to find a "vports" capable node
device and use that.
John Ferlan [Thu, 17 Nov 2016 20:03:00 +0000 (15:03 -0500)]
nodedev: Create helpers to search for vport capable nodedevs
Extract out code from virNodeDeviceGetParentHost into helpers - it's
going to be reused in upcoming patches to search on more fields
Create virNodeDeviceFindVPORTCapDef in order to return a virNodeDevCapsDefPtr
of the VPORT_OPS and virNodeDeviceFindFCParentHost to use the function and
generate an error message if the device doesn't have the capability.
Also clean up the processing in virNodeDeviceGetParentHost to remove
need for goto's.
Peter Krempa [Wed, 4 Jan 2017 12:23:31 +0000 (13:23 +0100)]
qemu: snapshot: Resume VM after live snapshot
Commit 4b951d1e38259ff5d03e9eedb65095eead8099e1 missed the fact that the
VM needs to be resumed after a live external checkpoint (memory
snapshot) where the cpus would be paused by the migration rather than
libvirt.
When generating the plain text version of the contributor
guidelines we add a ludicrous amount of vertical whitespace
in some spots. Tweak the XSLT stylesheet and regenerate the
now much better looking file.
qemuDomainCreateDevice: Be more careful about device path
Again, not something that I'd hit, but there is a chance in
theory that this might bite us. Currently the way we decide
whether or not to create /dev entry for a device is by marching
first four characters of path with "/dev". This might be not
enough. Just imagine somebody has a disk image stored under
"/devil/path/to/disk". We ought to be matching against "/dev/".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
qemuDomainAttachDeviceMknodHelper: Don't unlink() so often
Not that I'd encounter any bug here, but the code doesn't look
100% correct. Imagine, somebody is trying to attach a device to a
domain, and the device's /dev entry already exists in the qemu
namespace. This is handled gracefully and the control continues
with setting up ACLs and calling security manager to set up
labels. Now, if any of these steps fail, control jump on the
'cleanup' label and unlink() the file straight away. Even when it
was not us who created the file in the first place. This can be
possibly dangerous.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Imagine you have a domain configured in such way that you are
assigning two PCI devices that fall into the same IOMMU group.
With mount namespace enabled what happens is that for the first
PCI device corresponding /dev/vfio/X entry is created and when
the code tries to do the same for the second mknod() fails as
/dev/vfio/X already exists:
2016-12-21 14:40:45.648+0000: 24681: error :
qemuProcessReportLogError:1792 : internal error: Process exited
prior to exec: libvirt: QEMU Driver error : Failed to make device
/var/run/libvirt/qemu/windoze.dev//vfio/22: File exists
Worse, by default there are some devices that are created in the
namespace regardless of domain configuration (e.g. /dev/null,
/dev/urandom, etc.). If one of them is set as backend for some
guest device (e.g. rng, chardev, etc.) it's the same story as
described above.
Weirdly, in attach code this is already handled.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Some of the <li> elements in the "General tips for contributing
patches" section were missing the corresponding inner <p> element,
so they ended up all lumped together.
Clang 3.9 refuses to compile the existing code with the
following error:
util/virfirewall.c:425:20: error: passing an object that undergoes
default argument promotion to 'va_start'
has undefined behavior [-Werror,-Wvarargs]
va_start(args, layer);
^
util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer'
is declared here
virFirewallLayer layer,
^
This happens because 'layer' is of type virFirewallLayer, which
is an enum type and not a standard type such as eg. void* or int.
To solve the issue, turn virFirewallAddRule() from a very thin
wrapper around virFirewallAddRuleFullV() to a macro that expands
to a call to virFirewallAddRuleFull() - itself a very thin wrapper
around the aforementioned virFirewallAddRuleFullV() - with no loss
of functionality or type safety.
If a secret was not provided for what was determined to be a LUKS
encrypted disk (during virStorageFileGetMetadata processing when
called from qemuDomainDetermineDiskChain as a result of hotplug
attach qemuDomainAttachDeviceDiskLive), then do not attempt to
look it up (avoiding a libvirtd crash) and do not alter the format
to "luks" when adding the disk; otherwise, the device_add would
fail with a message such as:
"unable to execute QEMU command 'device_add': Property 'scsi-hd.drive'
can't find value 'drive-scsi0-0-0-0'"
because of assumptions that when the format=luks that libvirt would have
provided the secret to decrypt the volume.
Access to unlock the volume will thus be left to the application.
Michal Privoznik [Sun, 25 Dec 2016 16:56:22 +0000 (17:56 +0100)]
bhyvexml2argvdata: Fix <drive/> addresses
After c07d1c1c4f got merged it uncovered couple of broken domain
XMLs for bhyvexml2argv test. Some disk drives had incompatible
type of address configured.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Sun, 25 Dec 2016 16:02:50 +0000 (17:02 +0100)]
networkxml2conftest: s/lo/lo0/ on non-Linux
After 478ddedc12 a bug is fixed where we wrongly presumed loopack
device name on non-Linux systems. It's lo0. However, the fix is
not reflected in the tests which are failing now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Sun, 25 Dec 2016 15:00:15 +0000 (16:00 +0100)]
tests: Move test_libraries a bit higher
In the Makefile in tests/ we initialize couple of variables like
test_programs, test_libraries and test_helpers. These variables
contain all the targets that we need to build in order to run
the test suite. So we initialize test_programs and test_helpers
and then conditionally add targets to them depending on what we
are building with. Then we repeat the same process with
test_libraries. It makes no sense to have two separate if-endif
sequences.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Due to nature of operations we do over the string list (more
precisely due to how virStringListRemove() works), it is not the
best idea to use dataFree callback. Problem is, on MAC address
remove, the string list remove function modifies the original
list in place. Then, virHashUpdateEntry() is called which frees
all the data stored in the list rendering @newMacsList point to
freed data.
==16002== Invalid read of size 8
==16002== at 0x50BC083: virFree (viralloc.c:582)
==16002== by 0x513DC39: virStringListFree (virstring.c:251)
==16002== by 0x51089B4: virMacMapHashFree (virmacmap.c:67)
==16002== by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352)
==16002== by 0x50EF4FD: virHashUpdateEntry (virhash.c:415)
==16002== by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129)
==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002== by 0x403F15: virTestRun (testutils.c:180)
==16002== by 0x4032C4: mymain (virmacmaptest.c:205)
==16002== by 0x405A3B: virTestMain (testutils.c:992)
==16002== by 0x403D87: main (virmacmaptest.c:237)
==16002== Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd
==16002== at 0x4C2AD6F: realloc (vg_replace_malloc.c:693)
==16002== by 0x50BB99B: virReallocN (viralloc.c:245)
==16002== by 0x513DC0B: virStringListRemove (virstring.c:235)
==16002== by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124)
==16002== by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002== by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002== by 0x403F15: virTestRun (testutils.c:180)
==16002== by 0x4032C4: mymain (virmacmaptest.c:205)
==16002== by 0x405A3B: virTestMain (testutils.c:992)
==16002== by 0x403D87: main (virmacmaptest.c:237)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In virMacMapRemoveLocked() we have two variables: @macsList and
@newMacsList. Obviously, @newMacsList is supposed to hold pointer
to modified list but in fact it holds pointer to the old list.
It's confusing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
projects / libvirt.git / log