There's only very little common code among the two operations. Split the
functions so that the internals are easier to understand and refactor
later.

With a very unfortunate timing, the agent might vanish before we do the
second call while the locks were down. Re-check that the agent is
available before attempting it again.

Separate the code so that qemuDomainSetVcpusFlags contains only code
relevant to hardware hotplug/unplug.

As in commit 88dc7e0c, the helper can be used in cases where the
function actually does not access anyting in the private data besides
the agent.

Later on this will also be used to track size of the vcpu data array.
Use size_t so that we can utilize the memory allocation helpers.

Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and
reusing it accross libvirt.

The new helper will simplify checking whether the domain config contains
inactive vCPUs.

The code can be unified into the new accessor rather than being
scattered accross the drivers.

Use the local variable rather than getting it all the time from the
struct. This will simplify further refactors.

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

We should make a copy of current definition to preserve a persistent
definition, because we later update the definition with live changes.
The live definition is discarded on domain shutdown and replaced by the
copy we make before starting the domain.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Only 'tsc' timer allows set mode and track is valid only for 'rtc' and
'platform' timers.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This function does not set an error. Make it obvious in its name
to discourage its usage without reporting an error in the caller.

Use the customary check '< 0' instead of checking for non-zero.

No functional change.

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

This reverts commit d2e5538b.

A migration regression was introduced by this commit. When migrating
a domain, its active XML is sent to the destination libvirtd, where
it is parsed as inactive XML. d2e5538b copied the libxl generated
interface name into the active config, which was being passed to the
migration destination and being parsed into inactive config. Attempting
to start the config could result in failure if an interface with the
same generated name already exists.

The qemu driver behaves similarly, but the parser contains a hack to
skip interface names starting with 'vnet' when parsing inactive XML.
We could extend the hack to skip names starting with 'vif' too, but a
better fix would be to expose these hypervisor-specific interface name
prefixes in capabilities. See the following discussion thread for more
details

https://www.redhat.com/archives/libvir-list/2015-December/msg00262.html

For the pending 1.3.0 release, it is best to revert d2e5538b. It can
be added again post release, after moving the prefix to capabilities.

When installing the libvirt-daemon RPM, we have a %post rule to
enable the libvirtd.service, virtlockd.socket and virtlogd.socket
files. This is only done, however, when the RPM is first installed,
not when upgrading RPMs. So virtlogd will not get activated on
upgrading, which is a problem as libvirt qemu driver will expect
it to be available by default.

This adds a trigger that is run when uninstalling libvirt-daemon
older than 1.3.0 that will enable & start virtlogd.socket if
libvirtd is enabled and/or started. Using the trigger rather
than %post ensures that it only runs once, allowing admins to
disable it explicitly thereafter without future upgrades
re-enabling it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When someone does 'systemctl enable libvirtd.service' we should
also enable virtlockd.socket/virtlogd.socket, so that they can
be auto-activated if libvirtd tries to access the sockets.

Without this, people have to manually enable the units themselves
via 'systemctl enable virtdlogd.socket'.

This also ensures that if distros uses  'systemctl preset' for
enabling 'libvirtd.service', then the virtdlogd.socket gets
enabled without having to wait for the distro to update their
presets file.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virtlogd RPC messages all have a flags parameter. For
sake of future error reporting we should be verifying
these are all 0 for now.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The current virtlogd RPC protocol provides the ability to
handle log files associated with QEMU stdout/err. The log
protocol messages take the virt driver, domain name and
use that to form a log file path. This is quite restrictive
as it prevents us re-using the same RPC protocol messages
for logging to char device backends where the filename
can be arbitrarily user specified. It is also bad because
it means we have 2 separate locations which have to decide
on logfile name.

This change alters the RPC protocol so that we pass the
desired log file path along when opening the log file
initially. Now the virt driver is exclusively in charge
of deciding the log filename
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virt driver, dom name and uuid associated with a log
file are important pieces of metadata to keep around for
sake of future enhancements to virtlogd. Currently we
discard them after opening the log file, but we should
preserve them, even across restarts.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemuDomainLogContextNew method leaks the "logfile" path
on the non-virtlogd code path.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

virDomainSetMemory is documented to change only runtime configuration of
running domain. However, that's not true of all hypervisors supported.
Seems as though when commit id '0f2e50be' added the current flag, the
function description should have been updated similar to when commit id
'c1795c52' updated the virDomainSetMaxMemory description. Especially since
commit id '80427f1d' updated the virsh 'setmem' description to indicate
"behavior is different depending on hypervisor."

This patch will update the description to match current functionality.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

When a SCSI disk is hotplugged to a domain that does not have the required
SCSI controller already defined and loaded the following internal error occurs

error: Failed to attach device from scsi_disk.xml
error: internal error: Could not find scsi controller with index 0 required for device

Commit 0260506c added in method qemuBuildDriveDevStr a lookup of the controller
alias. The internal error occurs because in method qemuDomainAttachSCSIDisk
the automatic creation of the potentially missing SCSI controller occurs after
calling qemuBuildDriveDevStr.

This patch reverses the calling sequence.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>

Often when debugging bug reports one is given a copy of the file
from /var/log/libvirt/qemu/$NAME.log along with other supporting
files. In a number of cases I've been given sets of files which
were from different machines. Including the hostname in the QEMU
log file will help identify when the bug reporter is providing
bad information.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The log file descriptor associated with the virRotatingFile
struct should be marked close-on-exec, as even when virtlogd
re-exec's itself it expect to open the log file fresh. It
does not need to preserve the logfile handles, only the network
client FDs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In the non-systemd case, without socket activation, we need to proper
ordering.

Since libvirt for dubious historical reasons stores memory size as
kibibytes, it's possible that the alignments done in the qemu code
overflow the the maximum representable size in bytes. The XML parser
code handles them in bytes in some stages. Prevent this by doing
overflow checks when alinging the size and add a test case.

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

Using more than 4TiB of memory per NUMA node would not be possible to
express in the XML without violating the schema. Not that such boxes
would be common, but we should use a longer type at this point.

The pattern is not necessary since libvirt redefines the type already in
basictypes.rng with the same pattern.

This patch reverts parts of commits 0d8b24f6 and 0785966d dealing with
the addition of a controller during virDomainHostdevAssignAddress. This
caused a regression for the hostdev hotplug path which assumes the
qemuDomainFindOrCreateSCSIDiskController will add the new controller
during qemuDomainAttachHostSCSIDevice to both the running domain and
the domain def controller list when the controller doesn't yet exist
(whether due to no SCSI controllers existing or the addition of a new
controller because existing ones are full).

Since commit id 0d8b24f6 will call virDomainHostdevAssignAddress during
virDomainDeviceDefPostParseInternal which is called either during domain
definition post processing (via an iterator during virDomainDefPostParse)
or directly from virDomainDeviceDefParse during hotplug, the change
broke the "side effect" of being able to add both a hostdev and controller
to the running domain.

The regression would only be seen if the running domain didn't have a
SCSI controller already defined or if the existing SCSI controller was
"full" of devices and a new controller needed to be created.

This patch will also add some extra comments to the code to avoid a
similar future change.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>

Instead of the custom error:
error: iothreadpin: invalid cpulist.

use vshCommandOptStringReq and let it report a more specific error:
error: Failed to get option 'cpulist': Option argument is empty

Several callers were using vshCommandOptString without setting an error.
Use vshCommandOptStringReq which sets the error.

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