The github project was renamed from libvirtproject to libvirt

Recent changes to the -M/--machine processing code in qemuParseCommandLine
caused Coverity to determine there was a possible resource leak with how
the 'list' is managed. Rather than try to add virStringFreeList calls
everywhere - just promote list to the top of the variables and free it
within the error processing code. Also required a couple of other tweaks
in order to avoid double free's.

Commit id '73eda710' added virDomainKeyWrapDefParseXML which uses
virXPathNodeSet, but does not handle a -1 return thus causing a possible
loop condition exit problem later when the return value is used.

Change the logic to return the value from virXPathNodeSet if <= 0

Only set directory permissions at pool build time, if:

- User explicitly requested a mode via the XML
- The directory needs to be created
- We need to do the crazy NFS root-squash workaround

This allows qemu:///session to call build on an existing directory
like /tmp.

The XML parser sets a default <mode> if none is explicitly passed in.
This is then used at pool/vol creation time, and unconditionally reported
in the XML.

The problem with this approach is that it's impossible for other code
to determine if the user explicitly requested a storage mode. There
are some cases where we want to make this distinction, but we currently
can't.

Handle <mode> parsing like we handle <owner>/<group>: if no value is
passed in, set it to -1, and adjust the internal consumers to handle
it.

- Don't redocument the permissions fields for backingstore, just point to
  the volume docs.
- Clarify that owner/group are inherited from the parent directory at
  volume create/pool build time.
- Clarify that <permissions> fields report runtime values too

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