Cleanup code in prlsdkLoadDomain doesn't take into account the fact
if private domain structure along with freeing function is assigned
or not. In case it is, we shouldn't call it manually because
virDomainObjListRemove calls it and frees pdom.
Also, allocated def structure should be freed only if it's not
assigned to domain. Otherwise it will be called twice: one time by
virDomainObjListRemove and the second by prlsdkLoadDomain itself.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

It is better to get all necessary parameters and check them on newly
created configuration before actually creating a domain with them or
applying them to an existing domain.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

Some virsh commands have a size parameter, which is handled as scaled
integer.  We don't have any *feature* that would allow to use '-1' as
maximum size, so it's safe to reject any negative values for those
commands.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1159171Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In the upstream discussion on creating a github mirror [1], it turned
out that there are some read-only mirrors of our repository. Lets
advertise them on our downloads page. But do it wisely and discourage
people in sending a pull requests on GitHub.

1: https://www.redhat.com/archives/libvir-list/2015-May/msg00775.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

To silence Coverity just add a 'p &&' in front of the check in
networkFindUnusedBridgeName after the strchr() call.  Even though
we know it's not possible to have strchr return NULL since the only
way into the function is if there is a '%' in def->bridge or it's NULL.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Even though it's been pointed out they are false positives:

http://www.redhat.com/archives/libvir-list/2015-May/msg00301.html

and

http://www.redhat.com/archives/libvir-list/2015-May/msg00302.html

these still show up as Coverity issues. In order to silence Coverity
add an 'sa_assert' prior to check failure.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Coverity points out it's possible for one of the virCommand{Output|Error}*
API's to have not allocated 'output' and/or 'error' in which case the
strstr comparison will cause a NULL deref
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit c4d27bdd dropped output of owner/group -1.

Update zfs tests accordingly.

Build with gcc 4.8 fails with:

bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyve/bhyve_monitor.c:51:18: error: missing initializer for field 'tv_sec' of 'const struct timespec' [-Werror=missing-field-initializers]
     const struct timespec zerowait = {};

Explicitly initialize zerowait to fix the build.

Fixes build problems on x86_64-cygwin host for aarch64 target:
  CC       lxc/libvirt_driver_lxc_impl_la-lxc_monitor_protocol.lo
In file included from lxc/lxc_monitor_protocol.c:7:0:
lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory

  CC       rpc/libvirt_setuid_rpc_client_la-virnetmessage.lo
In file included from rpc/virnetmessage.h:24:0,
                 from rpc/virnetmessage.c:26:
rpc/virnetprotocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory

  CC       lxc/libvirt_lxc-lxc_monitor_protocol.o
In file included from lxc/lxc_monitor_protocol.c:7:0:
lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>

If the firewalld backend wasn't available and libvirt decides to try
setting up a "direct" backend, it checks for the presence of iptables,
ip6tables, and ebtables. If they are not found, a message like this is logged:

  error : virFirewallValidateBackend:193 : direct firewall backend
          requested, but /usr/sbin/ip6tables is not available:
          No such file or directory

But then at a later time if an attempt is made to use the virFirewall
API, failure will be indicated with:

  error : virFirewallApply:936 : out of memory

This patch changes virFirewallApply to first check if a firewall
backend hadn't been successfully setup, and logs a slightly more
informative message in that case:

  error : virFirewallApply:940 : internal error:
          Failed to initialize a valid firewall backend

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1223876

As of netcf-0.2.8, netcf supports configuring multipl IPv4 addresses,
as well as simultaneously configuring dhcp and static IPv4 addresses,
on a single interface. This patch updates libvirt's interface.rng to
allow such configurations.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1223688

If an SRIOV PF is offline, the kernel won't complain if you set the
mac address and vlan tag for a VF via this PF, and it will even let
you assign the VF to a guest using PCI device assignment or macvtap
passthrough. But in this case (the PF isn't online), the device won't
be usable in the guest.

Silently setting the PF online would solve the connectivity problem,
but as pointed out by Dan Berrange, when an interface is set online
with no associated config, the kernel will by default turn on IPv6
autoconf, which could create unexpected security problems for the
host. For this reason, this patch instead logs an error and fails the
operation.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=893738

Originally filed against RHEL6, but present in every version of
libvirt until today.

-1 is just an internal placeholder and is meaningless to output in the XML.

commit ffc40b63 changed uniond _virNodeDevCapData into a typedef
named virNodeDevCapData with a struct that contains the union as well
as a type enum. This change necessitated changing every reference to
"caps->type" into "caps->data.type", but the author of that patch
failed to test a build "WITH_HAL". This patch fixes the one place in
the hal backend that needed changing.

Due to a kernel commit (b4b8f770e), cpuinfo format has changed on
ARMs. Firstly, 'Processor: ...' may not be reported, it's
replaced by 'model name: ...'. Secondly, the "Processor" string
may occur in CPU name, e.g. 'ARMv7 Processor rev 5 (v7l)'.
Therefore, we must firstly look for 'model name' and then for
'Processor' if not found.
Moreover, lines in the cpuinfo file are shuffled, so we better
not manipulate the pointer to start of internal buffer as we may
lost some info.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every chardev is plugged onto virtio-serial bus. However, the
code introduced in 89e991a2 assumes that. Incorrectly.
With previous patches we have three options where a chardev can
be plugged: virtio-serial, USB and PCI. This commit fixes the
detach part. However, since we are not auto allocating USB
addresses yet, I'm just marking the place where appropriate code
should go.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every chardev is plugged onto virtio-serial bus. However, the
code introduced in 89e991a2 assumes that. Incorrectly.
With previous patches we have three options where a chardev can
be plugged: virtio-serial, USB and PCI. This commit fixes the
attach part.  However, since we are not auto allocating USB
addresses yet, I'm just marking the place where appropriate code
should go.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Like usb-serial, the pci-serial device allows a serial device to be
attached to PCI bus. An example XML looks like this:

  <serial type='dev'>
    <source path='/dev/ttyS2'/>
    <target type='pci-serial' port='0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </serial>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Old compilers whine:
src/util/virutil.c: In function 'virMemoryMaxValue':
src/util/virutil.c:2612: error: declaration of 'ulong' shadows a global declaration [-Wshadow]
/usr/include/sys/types.h:151: error: shadowed declaration is here [-Wshadow]

s/ulong/capped/ to work around the problem

Base-64 encode the password and pass it to the guest agent
via the 'guest-set-user-password' command.

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

Expose the virDomainSetUserPassword API in virsh:
virsh set-user-password dom user 123456

For setting passwords of users inside the domain.

With the VIR_DOMAIN_PASSWORD_ENCRYPTED flag set, the password
is assumed to be already encrypted by the method required
by the guest OS.

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

Using joinable threads does not help anything, but it can lead to memory
leaks.

When a worker thread exits, it decreases nWorkers or nPrioWorkers and
once both nWorkers and nPrioWorkers are zero (i.e., the last worker is
gone), quit_cond is signaled. When freeing the pool we first tell all
threads to die and then we are waiting for both nWorkers and
nPrioWorkers to become zero. At this point we already know all threads
are gone. So the only reason for calling virThreadJoin of all workers is
to free the memory allocated for joinable threads. If we avoid
allocating this memory, we don't need to take care of freeing it.

Moreover, any memory associated with a worker thread which died before
we asked it to die (e.g., because virCondWait failed in the thread)
would be lost anyway since virThreadPoolFree calls virThreadJoin only
for threads which were running at the time virThreadPoolFree was called.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Most virDomainDiskIndexByName callers do not care about the index; what
they really want is a disk def pointer.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Sometimes the only thing we need is the pointer to virDomainDiskDef and
having to call virDomainDiskIndexBy* APIs, storing the disk index, and
looking it up in the disks array is ugly. After this patch, we can just
call virDomainDiskBy* and get the pointer in one step.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When starting a domain, if a domain specifies security drivers we do not have
loaded, we fail. However we don't check for this during
reconnect, so any operation relying on security driver functionality would fail.
If someone e.g. starts a domain with selinux driver loaded, then they change
the security driver to 'none' in config, restart the daemon and call dump/save/..,
QEMU will return an error.
As we shouldn't kill the domain, we should at least log an error to let the
user know that domain reconnect wasn't completely clean.

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

After parsing the memory device XML the function would not restore the
XML parser context causing invalid XPath starting point for the rest of
the elements. This is a regression since 3e4230d2.

The test case addition uses the <idmap> element that is currently unused
by qemu, but parsed after the memory device definition and formatted
always.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1223631Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

virDomainParseMemory parses the size and then rounds up while converting
it to kibibytes. Since the number is limit-checked before the rounding
it's possible to use a number that would be correctly parsed the first
time, but not the second time. For numbers not limited to 32 bit systems
the magic is 9223372036854775807 bytes. That number then can't be parsed
back in kibibytes.

To solve the issue add a second overflow check for the few values that
would cause the problem. Since virDomainParseMemory is used in config
parsing, this avoids vanishing VMs.

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

So far, we are not reporting if numatune was even defined. The
value of zero is blindly returned (which maps onto
VIR_DOMAIN_NUMATUNE_MEM_STRICT). Unfortunately, we are making
decisions based on this value. Instead, we should not only return
the correct value, but report to the caller if the value is valid
at all.

For better viewing of this patch use '-w'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

For a domain configured using the host cdrom, we should taint the domain
due to problems encountered when the host and guest try to control the tray.

The only two virDirCreate callers already use it

I screwed this up in the previous (post 1.2.16) commits

Since af2a1f05,
qemuDomainGetNumaParameters() returns invalid value for a running
guest.  The problem is that it is getting the information from cgroups,
but the parent cgroup is being left alone since the mentioned commit.
Since the running guest's XML is in sync with cgroups, there is no need
to look into cgroups (unless someone changes the configuration behind
libvirt's back).  Returning the info from the definition fixes a bug and
is also a cleanup.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1221047Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

From xl.cfg950 man page:

spiceagent_mouse=BOOLEAN
Whether SPICE agent is used for client mouse mode. The default is
true (1) (turn on)

spicevdagent=BOOLEAN
Enables spice vdagent. The Spice vdagent is an optional component for
enhancing user experience and performing guest-oriented management
tasks. Its features includes: client mouse mode (no need to grab
mouse by client, no mouse lag), automatic adjustment of screen
resolution, copy and paste (text and image) between client and domU.
It also requires vdagent service installed on domU o.s. to work.
The default is 0.

spice_clipboard_sharing=BOOLEAN
Enables Spice clipboard sharing (copy/paste). It requires spicevdagent
enabled. The default is false (0).

So if spiceagent_mouse is enabled (client mouse mode) or
spice_clipboard_sharing is enabled, spicevdagent must be enabled.
Along with this change, s/spicedvagent/spicevdagent, set
spiceagent_mouse correctly, and add a test for these spice
features.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The logic related to spicedisable_ticketing and spicepasswd was
inverted.  As per man xl.cfg(5), 'spicedisable_ticketing = 1'
means no passwd is required.  On the other hand, a passwd is
required if 'spicedisable_ticketing = 0'.  Fix the logic and
produce and error if 'spicedisable_ticketing = 0' but spicepasswd
is not provided.  Also fix the spice cfg test file.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Move formating of spice listenAddr to the section of code
where spice ports are formatted.  It is more logical to
format address and ports together.  Account for the change
in spice cfg test file by moving 'spicehost'.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

'graphics->' is a bit easier to read and type, and makes for
shorter lines than 'def->graphics[0]->'.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Both the hal and udev drivers call virPCI*() functions to the the
SRIOV VF/PF info about PCI devices, and the UDEV backend calls
virPCI*() to get IOMMU group info. Since there is now a single
function call in node_device_linux_sysfs.c to do all of this, replace
all that code in the two backends with calls to
nodeDeviceSysfsGetPCIRelatedDevCaps().

Note that this results in the HAL driver (probably) unnecessarily
calling virPCIDevieAddressGetIOMMUGroupNum(), but in the case that the
host doesn't support IOMMU groups, that function turns into a NOP (it
returns -2, which causes the caller to skip the call to
virPCIDeviceAddressGetIOMMUGroupAddresses()). So in the worst case it
is a few extra cycles spent, and in the best case a mythical platform
that supported IOMMU groups but used HAL rather than UDEV would gain
proper reporting of IOMMU group info.