Define the public API for (de-)registering network events
and the callbacks for receiving lifecycle events. The lifecycle
event includes a 'detail' parameter to match the domain lifecycle
event data, but this is currently unused.
The network events related code goes into its own set of internal
files src/conf/network_event.[ch]
This variable shadows the stat(2) function, which only became visible in
this scope as of commit 9cac8639. Rename the variable so it doesn't
conflict.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
When doing 'virsh vol-dumpxml' on a gluster pool's volume, the
resulting URI incorrectly omitted a slash between hostname and
path: gluster://192.168.122.206rhsvol1/fedora-19.img
This is fallout from me rebasing earlier versions of my patch
that ended up as commit efee1af; I had originally played with
always requiring the gluster volume to have a leading slash,
but it was easier to use the gluster API if the gluster volume
name was guaranteed to have no slash. While I got the URI of
the pool correct, I forgot to fix the URI of a libvirt volume.
* src/storage/storage_backend_gluster.c
(virStorageBackendGlusterRefreshVol): Use correct starting point
since uri construction requires leading slash.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1035955
There's a window when starting a qemu process between fork() and exec()
during which we are doing things that may fail but not tunnelling the
error to the daemon. This is basically all within qemuProcessHook().
So whenever we fail in something, e.g. placing a process onto numa node,
users are left with:
error: Child quit during startup handshake: Input/output error
while the original error is thrown into the domain log:
libvirt: error : internal error: NUMA memory tuning in 'preferred'
mode only supports single node
Hence, we should read the log file and search for the error message and
report it to users.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Each unique event ID will thus be composed by 1 byte for the namespace
and 1 byte for a namespace-specific ID. The namespace for domain event
needs to be 0 for compatibility reasons.
SIGHUP is commonly used to instruct a daemon to reload its config. For
now we should handle it in virtlockd just like SIGUSR1, rather than
having it kill the process.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
- Use SIGUSR1, not SIGHUP, on reload. At present, virtlockd only
responds to the former.
- Fix PID file for virtlockd.
- Do not start virtlockd in any runlevels by default. It needs to be
explicitly selected in libvirt's qemu.conf anyway, so there is no
need to have it running on all systems regardless.
- Fix chkconfig priorities to ensure virtlockd is started before
libvirtd is started, and stopped after libvirtd is stopped.
- Add "Should-Start: virtlockd" to the libvirtd initscript's LSB header,
for the same reason.
- Add "Default-Stop" to both libvirtd and virtlockd initscripts. LSB
does not guarantee that this defaults to the inverse of
"Default-Start".
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
- Pass VIRTLOCKD_ARGS through to virtlockd.
- Use SIGUSR1, not SIGHUP, in ExecReload. At present, virtlockd only
responds to the former.
- Have "systemctl enable virtlockd.service" enable virtlockd.socket,
rather than throw an error.
- Make virtlockd.socket wanted by sockets.target, rather than
multi-user.target. This is consistent with other socket units in
Fedora, and it ensures that the socket is available before libvirtd is
started.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
When changing memtune limits to unlimited with AFFECT_CONFIG, the
values in virDomainDef are set to PARAM_UNLIMITED, which causes the
whole <memtune> to be formatted. This can be changed in all drivers,
but it also makes sense to use the default (0) as another value for
"unlimited", since zero memory limit makes no sense.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
For dead domains that have no memtune limits, we return 0 instead of
"unlimited", this patch fixes it to return PARAM_UNLIMITED.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since kernel 3.12 (commit 34ff8dc08956098563989d8599840b130be81252 in
linux-stable.git in particular) the value for 'unlimited' in cgroup
memory limits changed from LLONG_MAX to ULLONG_MAX. Due to rather
unfortunate choice of our VIR_DOMAIN_MEMORY_PARAM_UNLIMITED constant
(which we transfer as an unsigned long long in Kibibytes), we ended up
with the situation described below (applies to x86_64):
- 2^64-1 (ULLONG_MAX) -- "unlimited" in kernel = 3.12
- 2^63-1 (LLONG_MAX) -- "unlimited" in kernel < 3.12
- 2^63-1024 -- our PARAM_UNLIMITED scaled to Bytes
- 2^53-1 -- our PARAM_UNLIMITED unscaled (in Kibibytes)
This means that when any number within (2^63-1, 2^64-1] is read from
memory cgroup, we are transferring that number instead of "unlimited".
Unfortunately, changing VIR_DOMAIN_MEMORY_PARAM_UNLIMITED would break
ABI compatibility and thus we have to resort to a different solution.
With this patch every value greater than PARAM_UNLIMITED means
"unlimited". Even though this may seem misleading, we are already in
such unclear situation when running 3.12 kernel with memory limits set
to 2^63.
One example showing most of the problems at once (with kernel 3.12.2):
# virsh memtune asdf --hard-limit 9007199254740991 --swap-hard-limit -1
# echo 12345678901234567890 >\
/sys/fs/cgroup/memory/machine/asdf.libvirt-qemu/memory.soft_limit_in_bytes
# virsh memtune asdf
hard_limit : 18014398509481983
soft_limit : 12056327051986884
swap_hard_limit: 18014398509481983
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We were unconditionally removing the device from the host list, when it
should only be done on error.
This fixes USB collision detection when hotplugging the same device to
two guests.
If we hit a collision, we free the USB device while it is still part
of our temporary USBDeviceList. When the list is unref'd, the device
is free'd again.
Make the initial device freeing dependent on whether it is present
in the temporary list or not.
Similar to what Jiri did for cgroup setup/teardown in 05e149f94, push
it all into the device handler functions so we can do the necessary prep
work before claiming the device.
This also fixes hotplugging USB devices by product/vendor (virt-manager's
default behavior):
https://bugzilla.redhat.com/show_bug.cgi?id=1016511
Currently, if virFileMakePath() fails, the @ret is left initialized from
virAsprintf() just a few lines above leading to a wrong return value of
zero whereas -1 should be returned.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1035108
When attempting to enable more vCPUs in the guest than is currently
enabled in the guest but less than the maximum count for the VM we
currently reported an unhelpful message:
error: internal error: guest agent reports less cpu than requested
This patch changes it to:
error: invalid argument: requested vcpu count is greater than the count
of enabled vcpus in the domain: 3 > 2
https://bugzilla.redhat.com/show_bug.cgi?id=1035118
When outputting the XML for the RNG device, the code didn't format the
PCI address info. Additionally the schema wasn't expecting the info
although it was being parsed and used internally. Fix those mistakes and
add test for the PCI info section.
When changing the parsing and formatting functions in commit
43f2ccdc73 I forgot to update the qemu
disk alignment function for snapshots that automatically adds snapshot
configs for disks that were not mentioned in the XML. The function
allocated a new disk snapshot definition but did not correctly
initialize the snapshot disk source type variable. This resulted into
the disks considered as block devices and invalid XML was generated.
Reported by John Ferlan.
In 78839da I am trying to join the worker threads. However, I can't
sipmly reuse pool->nWorkers (same applies for pool->nPrioWorkers),
because of the following flow that is currently implemented:
1) the main thread executing virThreadPoolFree sets pool->quit = true,
wakes up all the workers and wait on pool->quit_cond.
2) A worker is woken up and see quit request. It immediately jumps of
the while() loop and decrements pool->nWorkers (or pool->nPrioWorkers in
case of priority worker). The last thread signalizes pool->quit_cond.
3) Main thread is woken up, with both pool->nWorkers and
pool->nPrioWorkers being zero.
So there's a need to copy the original value of worker thread counts
into local variables. However, these need to set *after* the check for
pool being NULL (dereferencing a NULL is no no). And for safety they can
be set right after the pool is locked.
Reported-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When an error occurred in qemuAgentIO, it will be saved in mon->lastError,
but it will not be freed at the end. Present since commit c160ce33;
and compare to commit 9cc8a5af fixing the same problem in qemu_monitor.c.
==22219== 54 bytes in 1 blocks are definitely lost in loss record 982 of 1,379
==22219== at 0x4C26B9B: malloc (vg_replace_malloc.c:263)
==22219== by 0x8520521: strdup (in /lib64/libc-2.11.3.so)
==22219== by 0x52E99CB: virStrdup (virstring.c:554)
==22219== by 0x52B44C4: virCopyError (virerror.c:195)
==22219== by 0x52B5123: virCopyLastError (virerror.c:312)
==22219== by 0x10905877: qemuAgentIO (qemu_agent.c:660)
==22219== by 0x52B6122: virEventPollDispatchHandles (vireventpoll.c:501)
==22219== by 0x52B7AEA: virEventPollRunOnce (vireventpoll.c:647)
==22219== by 0x52B5C1B: virEventRunDefaultImpl (virevent.c:274)
==22219== by 0x54181FD: virNetServerRun (virnetserver.c:1112)
==22219== by 0x11EF4D: main (libvirtd.c:1513)
Signed-off-by: Zhou Yimin <zhouyimin@huawei.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
This patch fixes memory leaks reported by valgrind on running
qemuxml2argvtest; introduced in commit 0df53f04.
Most of them are of the form:
==24777== 15 bytes in 1 blocks are definitely lost in loss record 39 of 129
==24777== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==24777== by 0x341F485E21: strdup (strdup.c:42)
==24777== by 0x4CADE5F: virStrdup (virstring.c:554)
==24777== by 0x4362B6: qemuBuildDriveStr (qemu_command.c:3848)
==24777== by 0x43EF73: qemuBuildCommandLine (qemu_command.c:8500)
==24777== by 0x426670: testCompareXMLToArgvHelper (qemuxml2argvtest.c:350)
==24777== by 0x427C01: virtTestRun (testutils.c:138)
==24777== by 0x41DDB5: mymain (qemuxml2argvtest.c:658)
==24777== by 0x4282A2: virtTestMain (testutils.c:593)
==24777== by 0x341F421A04: (below main) (libc-start.c:225)
==24777==
Signed-off-by: Eric Blake <eblake@redhat.com>
Kill the use of atoi() and introduce syntax check to forbid it and it's
friends (atol, atoll, atof, atoq).
Also fix a typo in variable name holding the cylinders count of a disk
pool (apparently unused).
examples/domsuspend/suspend.c will need a larger scale refactor as the
whole example file is broken thus it will be exempted from the syntax
check for now.
Even though currently we are freeing the pool of worker threads at the
daemon very end, nothing holds us back in joining the worker threads.
Moreover, we avoid leaks like this:
==26697== 1,680 bytes in 5 blocks are possibly lost in loss record 913 of 942
==26697== at 0x4C2BDE4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26697== by 0x4011131: allocate_dtv (in /lib64/ld-2.16.so)
==26697== by 0x401176D: _dl_allocate_tls (in /lib64/ld-2.16.so)
==26697== by 0x8499602: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.16.so)
==26697== by 0x52F53E9: virThreadCreate (virthreadpthread.c:188)
==26697== by 0x52F5D4F: virThreadPoolNew (virthreadpool.c:221)
==26697== by 0x53F30DB: virNetServerNew (virnetserver.c:377)
==26697== by 0x11C6ED: main (libvirtd.c:1366)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Ever since the subcpusets(vcpu,emulator) were introduced, the parent
cpuset cannot be modified to remove the nodes that are in use by the
subcpusets.
The fix is to break the memory node modification into three steps:
1. assign new nodes into the parent,
2. change the nodes in the child nodes,
3. remove the old nodes on the parent node.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1009880
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The storageRegister() didn't check the return from the
virRegisterStorageDriver() like other callers did, so Coverity
flagged it. Just check the return and handle.
The x509dname is only set inside a WITH_GNUTLS conditional, so
when used/check later on for NULL, Coverity detects this is not
possible. Added WITH_GNUTLS around uses to remove message
The nwfilterStateInitialize() would only assign sysbus inside
a WITH_DBUS conditional, thus leaving a subsequent check for sysbus
and nwfilterDriverInstallDBusMatches() as a no-op
Rather than try to add WITH_DBUS conditions which ended up conflicting
with the usage of HAVE_FIREWALLD conditionals, just remove the WITH_DBUS
since virdbus.c has entry points for with and without conditions.
The make inserts six spaces instead of four:
GEN access/viraccessapichecklxc.h
GEN hyperv/hyperv_wmi.generated.h
GEN access/viraccessapichecklxc.c
GEN hyperv/hyperv_wmi.generated.c
GEN hyperv/hyperv_wmi_classes.generated.typedef
GEN hyperv/hyperv_wmi_classes.generated.h
GEN hyperv/hyperv_wmi_classes.generated.c
GEN libvirt_access_qemu.xml
GEN libvirt_access.syms
GEN libvirt_access_lxc.xml
GEN libvirt_access_qemu.syms
GEN libvirt_access_lxc.syms
GEN libvirt_qemu.def
GEN esx/esx_vi_types.generated.typedef
GEN esx/esx_vi_types.generated.typeenum
GEN esx/esx_vi_types.generated.typetostring
GEN esx/esx_vi_types.generated.typefromstring
GEN esx/esx_vi_types.generated.h
GEN esx/esx_vi_types.generated.c
GEN esx/esx_vi_methods.generated.h
GEN esx/esx_vi_methods.generated.c
GEN esx/esx_vi_methods.generated.macro
GEN esx/esx_vi.generated.h
GEN esx/esx_vi.generated.c
GEN libvirt_lxc.def
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1029732
The BZ asked for the capability to change the number of queues used by
a virtio-net device while the device is in use. Because the number of
queues can only be set at the time the device is created, that isn't
possible. However, libvirt also shouldn't be silently reporting
success when someone tries to change the number of queues. So this
patch flags that as an error (just as attempts to change any of the
other virtio-specific parameters already do).
This resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=888635
(which was already closed as CANTFIX because the qemu "-boot strict"
commandline option wasn't available at the time).
Problem: you couldn't have a domain that used PXE to boot, but also
had an un-bootable disk device *even if that disk wasn't listed in the
boot order*, because if PXE timed out (e.g. due to the bridge
forwarding delay), the BIOS would move on to the next target, which
would be the unbootable disk device (again - even though it wasn't
given a boot order), and get stuck at a "BOOT DISK FAILURE, PRESS ANY
KEY" message until a user intervened.
The solution available since sometime around QEMU 1.5, is to add
"-boot strict=on" to *every* qemu command. When this is done, if any
devices have a boot order specified, then QEMU will *only* attempt to
boot from those devices that have an explicit boot order, ignoring the
rest.
This patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1035188
Commit f094aaac48 changed the PCI device assignment in qemu domains
to default to using VFIO rather than legacy KVM device assignment
(when VFIO is available). It didn't change which driver was used by
default for virNodeDeviceDetachFlags(), though, so that API (and the
virsh nodedev-detach command) was still binding to the pci-stub
driver, used by legacy KVM assignment, by default.
This patch publicizes (only within the qemu module, though, so no
additions to the symbol exports are needed) the functions that check
for presence of KVM and VFIO device assignment, then uses those
functions to decide what to do when no driver is specified for
virNodeDeviceDetachFlags(); if the vfio driver is loaded, the device
will be bound to vfio-pci, or if legacy KVM assignment is supported on
this system, the device will be bound to pci-stub; if neither method
is available, the detach will fail.
Currently the snapshot code did not check if it actually supports
snapshots on various disk backends for domains. To avoid future problems
add checkers that whitelist the supported configurations.
This patch adds function qemuGetDriveSourceString to produce
qemu-compatible disk source strings that will enable to reuse the code
and refactors building of the qemu commandline of disks to use this new
helper.
Automatically assign secret type from the disk source definition and
pull in adding of the comma. Then update callers to keep generated
output the same.
Before this patch, the translation function still needs a second ugly
helper function to actually format the command line for qemu. But if we
do the right stuff in the translation function, we don't have to bother
with the second function any more.
This patch removes the messy qemuBuildVolumeString function and changes
qemuTranslateDiskSourcePool to set stuff up correctly so that the
regular code paths meant for volumes can be used to format the command
line correctly.
For this purpose a new helper "qemuDiskGetActualType()" is introduced to
return the type of the volume in a pool.
As a part of the refactor the qemuTranslateDiskSourcePool function is
fixed to do decisions based on the pool type instead of the volume type.
This allows to separate pool-type-specific stuff more clearly and will
ease addition of other pool types that will require certain other
operations to get the correct pool source.
The previously fixed tests should make sure that we don't break stuff
that was working before.
Though trying to destroy a physical HBA doesn't make sense at all,
it's still a bit misleading with saying "only works for HBA".
Signed-off-by: Osier Yang <jyang@redhat.com>
The virDomainGetBlockJobInfo method did not zero out the
virDomainBlockJobInfo pointer arg, so when block jobs were
not active it would return garbage for the bandwidth/cur/end
fields.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When doing an internal snapshot on a VM with sheepdog or RBD disks we
would not set a flag to mark the domain is using internal snapshots and
might end up creating a mixed snapshot. Move the setting of the variable
to avoid this problem.
Consider the following valid snapshot XML as the <driver> element is
allowed to be empty in the domainsnapshot.rng schema:
$ cat snap.xml
<domainsnapshot>
<disks>
<disk name='vda' snapshot='external'>
<source file='/tmp/foo'/>
<driver/>
</disk>
</disks>
</domainsnapshot>
produces the following error:
$ virsh snapshot-create domain snap.xml
error: internal error: unknown disk snapshot driver '(null)'
The driver type is parsed as NULL from the XML as the attribute is not
present and then directly used to produce the error message.
With this patch the attempt to parse the driver type is skipped if not
present to avoid changing the schema to forbid the empty driver element.
Disk source elements for snapshots were using separate code from our
config parser. As snapshots can be stored on more than just regular
files, we will need the universal parser to allow us to expose a variety
of snapshot disk targets. This patch reuses the config parsers and
formatters to do the job.
This initial support only changes the code without any visible XML
change.
Avoid if statements when used with virBufferEscapeString which
automaticaly omits the whole string. Also add some line breaks to
visualy separate the code.
The <source> element formatting function was expecting a
virDomainDiskDefPtr to store the data. As snapshots are not using this
data structure to hold the data, we need to add an internal function
which splits out individual fields separately.
The original code ignored errors of virDomainHostdevDefAlloc,
however, we should properly do error return from the function
if it occurs.
The fix pulls out virDomainHostdevDefAlloc from the loop and
executes it all together before the loop. So we can easily
return on errors without the notion of other memory allocations
in the loop.
The deallocation code is separated from the allocation code
because it will be used by a further patch for fixing other error
handlings.
Reported-by: Laine Stump <laine@laine.org>
Signed-off-by: Ryota Ozaki <ozaki.ryota@gmail.com>
The fixed loop used logical OR to combine two conditions, however,
it is apparently incorrect and logical AND is correct.
We can fix it by replacing OR with AND, but this patch instead
fixes the problem by getting rid of the first conditional
statement: USBFilterCount < def->nhostdevs. It isn't needed
because USBFilterCount will never be greater than or equal to
def->nhostdevs.
def->nhostdevs is calculated in the following code
above the loop in question like this:
for (i = 0; i < deviceFilters.count; i++) {
PRBool active = PR_FALSE;
IUSBDeviceFilter *deviceFilter = deviceFilters.items[i];
deviceFilter->vtbl->GetActive(deviceFilter, &active);
if (active) {
def->nhostdevs++;
}
}
And the loop is constructed as like this:
for (i = 0; (USBFilterCount < def->nhostdevs) || (i < deviceFilters.count); i++) {
PRBool active = PR_FALSE;
(snip)
deviceFilter->vtbl->GetActive(deviceFilter, &active);
if (!active)
continue;
(snip)
USBFilterCount++;
}
So def->nhostdevs is the number of active device filters and
USBFilterCount is counted up only when a device filter is active.
Thus, we can remove USBFilterCount < def->nhostdevs safely.
Reported-by: Laine Stump <laine@laine.org>
Signed-off-by: Ryota Ozaki <ozaki.ryota@gmail.com>
While running nwfilterxml2xmltest, it was found that valgrind pointed out the
following error...
==7466== 16 bytes in 1 blocks are definitely lost in loss record 26 of 90
==7466== at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==7466== by 0x4C651AD: virAlloc (viralloc.c:142)
==7466== by 0x4D0450D: virNWFilterDefParseNode (nwfilter_conf.c:2575)
==7466== by 0x4D05D84: virNWFilterDefParse (nwfilter_conf.c:2647)
==7466== by 0x401FDE: testCompareXMLToXMLHelper (nwfilterxml2xmltest.c:39)
==7466== by 0x402DE1: virtTestRun (testutils.c:138)
==7466== by 0x4018E9: mymain (nwfilterxml2xmltest.c:111)
==7466== by 0x403482: virtTestMain (testutils.c:593)
==7466== by 0x341F421A04: (below main) (libc-start.c:225)
...21 times, which are related to 21 tests in nwfilterxml2xmltest.c which sent
EXPECT_WARN = false. There were two scenarios in virNWFilterDefParseXML(),
when the variable 'entry' was malloc'ed, but not freed.
This patch fixes the memory leaks found while running qemuxml2argvtest
==8260== 3 bytes in 1 blocks are definitely lost in loss record 1 of
129
==8260== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==8260== by 0x341F485E21: strdup (strdup.c:42)
==8260== by 0x4CADCFF: virStrdup (virstring.c:554)
==8260== by 0x4CBB839: virXPathString (virxml.c:90)
==8260== by 0x4CE753A: virDomainDefParseXML (domain_conf.c:11478)
==8260== by 0x4CEB4FE: virDomainDefParseNode (domain_conf.c:12742)
==8260== by 0x4CEB675: virDomainDefParse (domain_conf.c:12684)
==8260== by 0x425958: testCompareXMLToArgvHelper (qemuxml2argvtest.c:107)
==8260== by 0x427111: virtTestRun (testutils.c:138)
==8260== by 0x41D3FE: mymain (qemuxml2argvtest.c:452)
==8260== by 0x4277B2: virtTestMain (testutils.c:593)
==8260== by 0x341F421A04: (below main) (libc-start.c:225)
==8260==
==8260== 4 bytes in 1 blocks are definitely lost in loss record 5 of
129
==8260== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==8260== by 0x341F485E21: strdup (strdup.c:42)
==8260== by 0x4CADCFF: virStrdup (virstring.c:554)
==8260== by 0x4CBB839: virXPathString (virxml.c:90)
==8260== by 0x4CE753A: virDomainDefParseXML (domain_conf.c:11478)
==8260== by 0x4CEB4FE: virDomainDefParseNode (domain_conf.c:12742)
==8260== by 0x4CEB675: virDomainDefParse (domain_conf.c:12684)
==8260== by 0x425958: testCompareXMLToArgvHelper (qemuxml2argvtest.c:107)
==8260== by 0x427111: virtTestRun (testutils.c:138)
==8260== by 0x41D39A: mymain (qemuxml2argvtest.c:451)
==8260== by 0x4277B2: virtTestMain (testutils.c:593)
==8260== by 0x341F421A04: (below main) (libc-start.c:225)
==8260==
When setting up filesystems backed by block devices or file
images, the SELinux mount options must be used to ensure the
correct context is set
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1035336
The basic problem is that during a network update, the required
iptables rules sometimes change, and this was being handled by simply
removing and re-adding the rules. However, the removal of the old
rules was done based on the *new* state of the network, which would
mean that some of the rules would not match those currently in the
system, so the old rules wouldn't be removed.
This patch removes the old rules prior to updating the network
definition then adds the new rules as soon as the definition is
updated. Note that this could lead to a stray packet or two during the
interim, but that was already a problem before (the period of limbo is
now just slightly longer).
While moving the location for the rules, I added a few more sections
that should result in the iptables rules being redone:
DHCP_RANGE and DHCP_HOST - these are needed because adding/removing a dhcp
host entry could lead to the dhcp service being started/stopped, which
would require that the mangle rule that fixes up dhcp response
checksums sould need to be added/removed, and this wasn't being done.
The code for extracting sub-mounts would just do a STRPREFIX
check on the mount. This was flawed because if there were
the following mounts
/etc/aliases
/etc/aliases.db
and '/etc/aliases' was asked for, it would return both even
though the latter isn't a sub-mount.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
