Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We have several cases when a VM has multiple disks in the test files so
having another one without any interesting configuration is not
necessary.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move the authentication and ipv6 cases into the main test file. To allow
removal of the separate testing of the secure credential passing via the
'secret' object in qemu, use the DO_TEST_CAPS_VER macro with version
2.5.0 when the secret object is not supported by qemu.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The xml2argv variant was unused. The xml2xml variant is redundant in
other tests for RBD.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move various different iSCSI configuration into one test file.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move the 'unsafe' cache test into 'disk-cache' and remove all the
individual cases for one cache mode each.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We'll aggregate testing of all cache modes in this test later on.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This test also excercises options of 'discard'.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Test empty cdroms along with cdroms with medium.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Unify most of the tests into a common test named disk-cdrom-network by
adding multiple cdroms. The 'http' test is dropped since there can be
only 4 cdroms.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Few disk tests were testing support for pure -drive command line
generation for disks now that we assume it for all qemu versions the
cases are obsolete.

Replacements:
disk-readonly-no-device -> disk-readonly-disk
disk-floppy-tray-no-device -> disk-floppy-tray
disk-cdrom-tray-no-device -> disk-cdrom-tray
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We also have disk-copy_on_read.xml which also tests the command line.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We finally get rid of the strncpy()-like semantics
and implement our own, more sensible ones instead.

As a bonus, this also fixes compilation on MinGW.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We're going to change virStrncpy() in a way that
requires the source string to be NULL-terminated, so
we'll no longer be able to use in this context.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Currently, the functions return a pointer to the
destination buffer on success or NULL on failure.

Not only does this kind of error handling look quite
alien in the context of libvirt, where most functions
return zero on success and a negative int on failure,
but it's also somewhat pointless because unless there's
been a failure the returned pointer will be the same
one passed in by the user, thus offering no additional
value.

Change the functions so that they return an int
instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The strncpy() function has this quirk where it will copy
*up* to the requested number of bytes, that is, it will
stop early if it encounters a NULL byte in the source
string.

This makes it legal to pass the size of the destination
buffer (minus one byte needed for the string terminator)
as the number of bytes to copy and still get something
somewhat reasonable out of the operation; unfortunately,
it also makes the function difficult to reason about
and way too easy to misuse.

We want to move away from the way strncpy() behaves and
towards better defined semantics, where virStrncpy()
will always copy *exactly* the number of bytes it's
been asked to copy; before we can do that, though, we
have to change a few of the callers.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

virStrncpy() allows us to copy a substring, but if we're
going to copy the entire thing it's much more convenient
to use virStrcpy() instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

virStrcpy() and friends are useful when the destination
buffer has already been allocated, eg. as part of a struct;
if we have to allocate it on the spot, VIR_STRDUP() is a
better choice.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

This convenience macro was created for the simple cases
where the length of the source string and the size of the
destination buffer can be figued out with strlen() and
sizeof() respectively, so we should use it wherever
possible instead of open-coding parts of it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The way virStrncpy() is called here will never result in
buffer overflow, but it won't prevent or detect truncation
either, despite what the error message might suggest. Use
virStrcpyStatic(), which does all of the above, instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

All our supported RHEL and Fedora versions include systemd, so we can
assume it is always present in the spec.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We no longer build on RHEL-6, so can bump min required RHEL to 7
removing many conditions.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When gnutls negotiates TLS 1.3 instead of 1.2, the order of messages
sent by the handshake changes. This exposed a logic bug in the test
suite which caused us to wait for the server to see handshake
completion, but not wait for the client to see completion. The result
was the client didn't receive the certificate for verification and the
test failed.

This is exposed in Fedora 29 rawhide which has just enabled TLS 1.3 in
its GNUTLS builds.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Add --alias to support custom alias in virsh attach-interface.
Signed-off-by: NHan Han <hhan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add --alias to support custom disk alias in virsh attach-disk.
Signed-off-by: NHan Han <hhan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1603025

Commit b57a9aec neglected to VIR_FREE(binding->filtername) as seen
in the following valgrind report

==6423== 17,328 bytes in 1,083 blocks are definitely lost in loss record 2,275 of 2,297
==6423==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==6423==    by 0x83B20C9: strdup (in /usr/lib64/libc-2.17.so)
==6423==    by 0x533C144: virStrdup (virstring.c:977)
==6423==    by 0x54BDD53: virGetNWFilterBinding (datatypes.c:865)
==6423==    by 0x318D633C: nwfilterBindingCreateXML (nwfilter_driver.c:767)
==6423==    by 0x54F3FC5: virNWFilterBindingCreateXML (libvirt-nwfilter.c:701)
==6423==    by 0x539CE29: virDomainConfNWFilterInstantiate (domain_nwfilter.c:116)
==6423==    by 0x31E516C2: qemuInterfaceBridgeConnect (qemu_interface.c:589)
==6423==    by 0x31D98B56: qemuBuildInterfaceCommandLine (qemu_command.c:8418)
==6423==    by 0x31D9F783: qemuBuildNetCommandLine (qemu_command.c:8673)
==6423==    by 0x31D9F783: qemuBuildCommandLine (qemu_command.c:10354)
==6423==    by 0x31DE355F: qemuProcessLaunch (qemu_process.c:6292)
==6423==    by 0x31DE7881: qemuProcessStart (qemu_process.c:6686)

and

==6423== 17,328 bytes in 1,083 blocks are definitely lost in loss record 2,276 of 2,297
==6423==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==6423==    by 0x83B20C9: strdup (in /usr/lib64/libc-2.17.so)
==6423==    by 0x533C144: virStrdup (virstring.c:977)
==6423==    by 0x54BDD53: virGetNWFilterBinding (datatypes.c:865)
==6423==    by 0x318D641F: nwfilterBindingLookupByPortDev (nwfilter_driver.c:678)
==6423==    by 0x54F3B63: virNWFilterBindingLookupByPortDev (libvirt-nwfilter.c:593)
==6423==    by 0x539CBC5: virDomainConfNWFilterTeardownImpl.isra.0 (domain_nwfilter.c:136)
==6423==    by 0x539CFA5: virDomainConfVMNWFilterTeardown (domain_nwfilter.c:170)
==6423==    by 0x31DE5651: qemuProcessStop (qemu_process.c:6912)
==6423==    by 0x31E37974: qemuDomainDestroyFlags (qemu_driver.c:2229)
==6423==    by 0x54C24BB: virDomainDestroy (libvirt-domain.c:475)
==6423==    by 0x1589A2: remoteDispatchDomainDestroy (remote_daemon_dispatch_stubs.h:4827)
==6423==    by 0x1589A2: remoteDispatchDomainDestroyHelper (remote_daemon_dispatch_stubs.h:4803)
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The include guard should match the file name and comment.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Hypervisor drivers (e.g. QEMU) assume that they run in a separate
thread from the main event loop thread otherwise deadlocks can
occur. Therefore let's report an error if max_workers < 1 is set in
the libvirtd configuration file.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

...since maxWorkers=0 is only intended for virtlockd or virlogd which
must not be multithreaded.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

@srv must be unlocked for the call virNetServerProcessMsg otherwise a
deadlock can occur.

Since the pointer 'srv->workers' will never be changed after
initialization and the thread pool has it's own locking we can release
the lock of 'srv' earlier. This also fixes the deadlock.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>