Use the custom emulator pin setting with the highest priority same as
with vcpupin.

If this enviroment variable is set, the virTestCompareToFile helper
will overwrite the file content we are comparing against, if the
file doesn't exist or it doesn't match the expected input.

This is useful when adding new test cases, or making changes that
generate a lot of output churn.

Replaces a common pattern used in many test files

To remove a bunch of TestGetDebug()/TestGetVerbose() checks

Commit 2a530a3e is not portable to mingw, which intentionally
avoids declaring the obsolete index().  See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1214605

* src/util/virstring.c (virStringStripControlChars): Use strchr.
Signed-off-by: NEric Blake <eblake@redhat.com>

CT stands for containers, i.e. def->os.type should be compared with VIR_DOMAIN_OSTYPE_EXE
rather than VIR_DOMAIN_OSTYPE_HVM
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Instead of each API copying the same lines of code, lets use the
generic function designed just for that purpose.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of each API copying the same lines of code, lets use the
generic function designed just for that purpose. At the same time,
drop useless connection object locking in some functions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function is practically copied over from qemu driver. Its
only purpose in life is to lookup a domain object and print an
error if no object is found.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The pointer does not change throughout the while life of a
parallels connection. Mark it as such.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The PortNumber data type is declared to derive from 'short'.
Unfortunately this is an signed type, so validates the range
[-32,768, 32,767] which excludes valid port numbers between
32767 and 65535.

We can't use 'unsignedShort', since we need -1 to be a valid
port number too.

This change is to use 'int' and set an explicit max boundary
instead of relying on the data types' built-in max.

One of the existing tests is changed to use a high port number
to validate the schema.

https://bugzilla.redhat.com/show_bug.cgi?id=1214664Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

just as what b8e25c35 did, we
fall back to the ACPI method when the guest agent is unresponsive
in qemuDomainReboot().
Signed-off-by: NYueWenyuan <yuewenyuan@huawei.com>
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 835cf84b dropped expectedVirtTypes argument for
virDomainDefParse*() functions, however bhyve tests still try to pass
that to virDomainDefParseFile(), therefore build fails.

Fix build by fixing virDomainDefParseFile() usage.

Fedora doesn't ship OVMF/AAVMF builds in its repos due to licensing
issues, so the recommended way to consume these bits is via Gerd's
nightly repo: https://www.kraxel.org/repos

Let's teach fedora builds about the loader/nvram pairs these packages
installed, so users don't need to edit qemu.conf to get virt-manager
UEFI support.

Some hypervisors like Xen do not have PIDs associated with domains.
Relax the requirement for PID != 0 in the locking code so it can
be used by hypervisors that do not represent domains as a process
running on the host.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Also a typo is fixed (s/detached/attached/)

Signed-off-by: Maxim Nestratov mnestratov@parallels.com

When running on FreeBSD, there's a bug in virCommandProcessIO
polling that is triggered by the commandtest.

A test that triggers EPIPE in commandtest (named "test20") hungs
forever on FreeBSD.

Apparently, this happens because FreeBSD sets POLLHUP flag on revents
when stdin in closed. And as the current implementation only checks for
POLLOUT and POLLERR, it ends up looping forever inside
virCommandProcessIO and not trying to do one more write() that would
trigger EPIPE.

To fix that check for the POLLHUP flag along with POLLOUT and POLLERR.

When a user would specify a backing chain index that is above the start
point libvirt would report a rather unhelpful error:

invalid argument: could not find backing store 1 in chain for 'sub/link2'

This patch adds an explicit check that the index is below start point in
the backing store and reports the following error if not:

invalid argument: requested backing store index 1 is above 'sub/../qcow2' in chain for 'sub/link2'

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

Some storage protocols allow to have the @path field in struct
virStorageSource set to NULL. Add NULLSTR() wrappers to handle this
possibility until I finish the storage source error formatter.

virCommandNewArgList can use virCommandNewVAList.

The hostdev check can error out right away.

Build fails on non-Linux systems with this error:

  CC       util/libvirt_util_la-virnetdev.lo
util/virnetdev.c:364:1: error: unused function 'virNetDevReplaceMacAddress' [-Werror,-Wunused-function]
virNetDevReplaceMacAddress(const char *linkdev,
^
util/virnetdev.c:406:1: error: unused function 'virNetDevRestoreMacAddress' [-Werror,-Wunused-function]
virNetDevRestoreMacAddress(const char *linkdev,
^
2 errors generated.

The virNetDev{Restore,Replace}MacAddress() functions are only used
by VF-related routines that are available on Linux only. So move these
functions under the same #ifdef.

Because packets going through the egress from a bridge (where our
bandwidth limiting takes place) have no information about which
interface they came from, the QoS rules that we create instead
use the source MAC address of the packets to make their decisions
about which QDisc the packet should be in.

One flaw in this is that when a guest changed the MAC address it
used, packets from the guest would no longer be put into the
correct QDisc, but would instead be put in an "unprivileged"
class, resulting in the bandwidth "floor" (minimum guaranteed)
being no longer honored.

Now that libvirt has infrastructure to capture and respond to
RX_FILTER_CHANGE events from qemu (sent whenever a guest
interface modifies its MAC address, among other things), we can
notice when a guest MAC address changes, and update the QoS rules
accordingly, so that bandwidth floor is honored even after a
guest MAC address change.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In one of my previous patches (b68a56bc) I made class_id to
format more frequently. Well, now it's formatting way too
frequent - even for regular active XML. Users don't need to see
it, so lets format it only for the status XML where it's really
needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

qemuDomainSetMemoryFlags() would allow to set the initial memory greater
than the <maxMemory> field. While the configuration would not work as
memory hotplug requires NUMA to be enabled and the
qemuDomainSetMemoryFlags() API does not work on NUMA guests this just
fixes a corner case.

The fix is still worth though as it allows to induce an invalid
configuration and make the VM vanish on libvirt restart.

Additionally this tweaks error message to be more accurate.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Introduce libxl.conf configuration file, adding the 'autoballoon'
setting as the first knob for controlling the libxl driver.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

A further fix for:

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

Since there is no possibility that any type of macvtap will work if
the parent physdev it's attached to is offline, we should bring the
physdev online at the same time as the macvtap. When taking the
macvtap offline, it's also necessary to take the physdev offline for
macvtap passthrough mode (because the physdev has the same MAC address
as the macvtap device, so could potentially cause problems with
misdirected packets during migration, as outlined in commits 829770
and 879c13). We can't set the physdev offline for other macvtap modes
1) because there may be other macvtap devices attached to the same
physdev (and/or the host itself may be using the device) in the other
modes whereas passthrough mode is exclusive to one macvtap at a time,
and 2) there's no practical reason to do so anyway.

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

When we set the MAC address of a network device as a part of setting
up macvtap "passthrough" mode (where the domain has an emulated netdev
connected to a host macvtap device that has exclusive use of the
physical device, and sets the device MAC address to match its own,
i.e. "<interface type='direct'> <source mode='passthrough' .../>"), we
use ioctl(SIOCSIFHWADDR) giving it the name of that device. This is
true even if it is an SRIOV Virtual Function (VF).

But, when we are setting the MAC address / vlan ID of a VF in
preparation for "hostdev network" passthrough (this is where we set
the MAC address and vlan id of the VF after detaching the host net
driver and before assigning the device to the domain with PCI
passthrough, i.e. "<interface type='hostdev'>", we do the setting via
a netlink RTM_SETLINK message for that VF's Physical Function (PF),
telling it the VF# we want to change. This sets an "administratively
changed MAC" flag for that VF in the PF's driver, and from that point
on (until the PF driver is reloaded, *not* merely the VF driver) that
VF's MAC address can't be changed using ioctl(SIOCSIFHWADDR) - the
only way to change it is via the PF with RTM_SETLINK.

This means that if a VF is used for hostdev passthrough, it will have
the admin flag set, and future attempts to use that VF for macvtap
passthrough will fail.

The solution to this problem is to check if the device being used for
macvtap passthrough is actually a VF; if so, we use the netlink
RTM_SETLINK message to the PF to set the VF's mac address instead of
ioctl(SIOCSIFHWADDR) directly to the VF; if not, behavior does not
change from previously.

There are three pieces to making this work:

1) virNetDevMacVLan(Create|Delete)WithVPortProfile() now call
   virNetDev(Replace|Restore)NetConfig() rather than
   virNetDev(Replace|Restore)MacAddress() (simply passing -1 for VF#
   and vlanid).

2) virNetDev(Replace|Restore)NetConfig() check to see if the device is
   a VF. If so, they find the PF's name and VF#, allowing them to call
   virNetDev(Replace|Restore)VfConfig().

3) To prevent mixups when detaching a macvtap passthrough device that
   had been attached while running an older version of libvirt,
   virNetDevRestoreVfConfig() is potentially given the preserved name
   of the VF, and if the proper statefile for a VF can't be found in
   the stateDir (${stateDir}/${pfname}_vf${vfid}),
   virNetDevRestoreMacAddress() is called instead (which will look in
   the file named ${stateDir}/${vfname}).

This problem has existed in every version of libvirt that has both
macvtap passthrough and interface type='hostdev'. Fortunately people
seem to use one or the other though, so it hasn't caused any real
world problem reports.

- Remove all qemu emulators
- Restart libvirtd
- Install qemu emulators
- Call 'virsh version' -> errors

The only thing that will force the qemu driver to refresh it's cached
capablities info is an explict API call to GetCapabilities.

However in the case when the initial caps lookup at driver connect didn't
find a single qemu emulator to poll, the driver is effectively useless
and really can't do anything until it's populated some qemu capabilities
info.

With the above steps, the user would have to either know about the
magic refresh capabilities call, or restart libvirtd to pick up the
changes.

Instead, this patch changes things so that every time a part of th
driver requests access to capabilities info, check to see if
we've previously seen any emulators. If not, force a refresh.

In the case of 'still no emulators found', this is still very quick, so
I can't think of a downside.

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

When building without lxc support enabled, build fails with:

CLD     vircapstest
vircapstest.o: In function `test_virCapsDomainDataLookupLXC':
vircapstest.c:(.text+0x9ef): undefined reference to `testLXCCapsInit'

Fix that by hiding LXC tests under appropriate #ifdef. Same applies
for QEMU and XEN.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Adjust the processLU error returns to be a bit more logical. Currently,
the calling code cannot determine the difference between a non disk/lun
volume and a processed/found disk/lun. It can also not differentiate
between perhaps real/fatal error and one that won't necessarily stop
the code from finding other volumes.

After this patch virStorageBackendSCSIFindLUsInternal will stop processing
as soon as a "fatal" message occurs rather than continuting processing
for no apparent reason. It will also only set the *found value when
at least one of the processLU's was successful.

With the failed return, if the reason for the stop was that the pool
target path did not exist, was /dev, was /dev/, or did not start with
/dev, then iSCSI pool startup and refresh will fail.

Rather than passing/returning a pointer to a boolean to indicate that
perhaps we should try again - adjust the return of the call to return
the count of LU's found during processing, then let the caller decide
what to do with that value.

Use virStorageBackendPoolUseDevPath API to determine whether creation of
stable target path is possible for the volume.

This will differentiate a failed virStorageBackendStablePath which won't
need to be fatal. Thus, we'll add a -2 return value to differentiate that
the failure was a result of either the inability to find the symlink for
the device or failure to open the target path directory

Fix the if (!STRPREFIX(path, "/dev")) to be if (!STRPREFIX(path, "/dev/"))
to ensure a path such as "/device" isn't declared stable.

For virStorageBackendStablePath, in order to make decisions in other code
split out the checks regarding whether the pool's target is empty, using /dev,
using /dev/, or doesn't start with /dev