The dbus_bus_get() function returns a shared bus connection that
all libraries in a process can use. You are forbidden from calling
close on this connection though, since you can never know if any
other code might be using it.

Add an option to use private dbus bus connections, if the app
wants to be able to close the connection.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Fix the improper comment for the "release" hook.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

s/occcurred/occurred

Since 5a468b38 we use SOL_LOCAL for the 2nd argument of getsockopt()
however Lion added the define SOL_LOCAL set to 0, which is the value to
the 2nd argument of getsockopt() for Unix sockets on Mac OS X. So
instead of using the define just pass 0 so we restore compatibility
with Snow Leopard and Leopard.

Reported at https://github.com/mxcl/homebrew/pull/23141

Do VMware version detection earlier as future patches will need the
version information to populate capabilities correctly.

Rather than walking the possible driver backends by handle, use a helper
function. Additionally I've done a bit of refactoring in the code over
the past few commits so add myself to the copyright line.

After my patches, some functions gained one more argument
(@listenAddress) which wasn't included in debug printing of
arguments they were called with. Functions in question are:
qemuMigrationPrepareDirect and qemuMigrationPerform.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu
died too quickly = in Prepare phase. What is happening here is:

1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling
qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor()
and qemuConnectMonitor(). So far so good. The qemuMonitorOpen()
succeeds, however switching monitor to QMP mode fails as qemu died
meanwhile. That is qemuMonitorSetCapabilities() returns -1.

2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0
2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1
2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13
...
2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"}
 fd=-1
2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s)

2) [Thread 3262] The event loop is trying to do the talking to monitor.
However, qemu is dead already, remember?

2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer
2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25
...
2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem:

3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the
'endjob' label and subsequently to the 'cleanup'. Since the domain is
not persistent and ret is -1, the qemuDomainRemoveInactive() is called.
This has an (unpleasant) effect of virObjectUnref()-in the @vm object.
Unpleasant because the event loop which is about to trigger EOF callback
still holds a pointer to the @vm (not the reference). See the valgrind
output below.

4) [Thread 3262] So the event loop starts triggering EOF:

2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback
2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10'

And the monitor is cleaned up. This results in calling
qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is
kept in qemuMonitor struct.

==3262== Thread 1:
==3262== Invalid read of size 4
==3262==    at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so)
==3262==    by 0x52FAA06: virMutexLock (virthreadpthread.c:85)
==3262==    by 0x52E3891: virObjectLock (virobject.c:320)
==3262==    by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296)
==3262==    by 0x11642593: qemuMonitorIO (qemu_monitor.c:730)
==3262==    by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501)
==3262==    by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648)
==3262==    by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274)
==3262==    by 0x542D3D9: virNetServerRun (virnetserver.c:1112)
==3262==    by 0x11F368: main (libvirtd.c:1513)
==3262==  Address 0x14549128 is 24 bytes inside a block of size 136 free'd
==3262==    at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3262==    by 0x529B1FF: virFree (viralloc.c:580)
==3262==    by 0x52E3703: virObjectUnref (virobject.c:270)
==3262==    by 0x531557E: virDomainObjListRemove (domain_conf.c:2355)
==3262==    by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061)
==3262==    by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450)
==3262==    by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626)
==3262==    by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309)
==3262==    by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266)
==3262==    by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797)
==3262==    by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741)
==3262==    by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435)

The mon->vm is set in qemuMonitorOpenInternal() which is the correct
place to increase @vm ref counter. The correct place to decrease the ref
counter is then qemuMonitorDispose().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The helper function virCompareLimitUlong compares limit values,
where value of 0 is equal to unlimited. If the latter parameter is 0,
it should return -1 instead of 1, hence the user can only set hard_limit when
swap_hard_limit currently is unlimited.

Worse, all callers pass 2 64-bit values, but on 32-bit platforms,
the second argument was silently truncated to 32 bits, which
could lead to incorrect computations.
Signed-off-by: NBing Bu Cao <mars@linux.vnet.ibm.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

The enum for virNetDevVPort is declared in the header file
virnetdevvportprofile.h, but for some reason the impl is
in netdev_vport_profile_conf.c.

This causes a dep from src/util onto src/conf which is not
allowed. Move the enum impl into virnetdevvportprofile.c
to break the circle.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This configuration knob is there to override default listen address for
-incoming for all qemu domains.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function takes exactly one argument: an address to check.
It returns true, if the address is an IPv4 or IPv6 address in numeric
format, false otherwise (e.g. for "examplehost").
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Whenever we check for ABI stability, we have new xml (e.g. provided by
user, or obtained from snapshot, whatever) which we compare to old xml
and see if ABI won't break. However, if the new xml was produced via
virDomainGetXMLDesc(..., VIR_DOMAIN_XML_MIGRATABLE) it lacks some
devices, e.g. 'pci-root' controller. Hence, the ABI stability check
fails even though it is stable. Moreover, we can't simply fix
virDomainDefCheckABIStability because removing the correct devices is
task for the driver. For instance, qemu driver wants to remove the usb
controller too, while LXC driver doesn't. That's why we need special
qemu wrapper over virDomainDefCheckABIStability which removes the
correct devices from domain XML, produces MIGRATABLE xml and calls the
check ABI stability function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id '532fef36' added a call to fallocate() and some error
handling based on whether or not the function existed. This new
call resulted in libvirt-cim/cimtest failures when attempting to
create a volume with "0" (zero) allocation value. The failure is
logged as:

Oct  9 07:51:33 localhost libvirtd[8030]: cannot allocate 0 bytes in
file '/var/lib/libvirt/images/cimtest-vol.img': Invalid argument

This can also be seen with virsh vol-create-as:

error: Failed to create vol test
error: cannot allocate 0 bytes in file '/home/vm-images/test': Invalid
argument

error: Failed to create vol test
error: cannot allocate 0 bytes in file '/home/vm-images/test': Invalid
argument

It turns out fallocate() will return EINVAL when the incoming 'len'
(or allocation) value is 0 (or less).

At the beginning of the function qemuPrepareHostdevPCICheckSupport() is
called. After that @pcidevs is initialized. However, if the very first
command fails, we go to 'cleanup' label where virObjectUnref(pcidevs) is
called. Obviously, it is called before @pcidevs was able to get
initialized. Compiler warns about it:

  CC       qemu/libvirt_driver_qemu_impl_la-qemu_hostdev.lo
qemu/qemu_hostdev.c: In function 'qemuPrepareHostdevPCIDevices':
qemu/qemu_hostdev.c:824:19: error: 'pcidevs' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virObjectUnref(pcidevs);
                   ^
cc1: all warnings being treated as errors

Prefer using VFIO (if available) to the legacy KVM device passthrough.

With this patch a PCI passthrough device without the driver configured
will be started with VFIO if it's available on the host. If not legacy
KVM passthrough is checked and error is reported if it's not available.

Add code to check availability of PCI passhthrough using VFIO and the
legacy KVM passthrough and use it when starting VMs and hotplugging
devices to live machine.

Avoid mixed brace style in an if statement and fix formatting of error
messages.

Since 76b644c3 when the support for RAM filesystems was introduced,
libvirt accepted the following XML:
<source usage='1024' unit='KiB'/>

This was parsed correctly and internally stored in bytes, but it
was formatted as (with an extra 's'):
<source usage='1024' units='KiB'/>
When read again, this was treated as if the units were missing,
meaning libvirt was unable to parse its own XML correctly.

The usage attribute was documented as being in KiB, but it was not
scaled if the unit was missing. Transient domains still worked,
because this was balanced by an extra 'k' in the mount options.

This patch:
Changes the parser to use 'units' instead of 'unit', as the latter
was never documented (fixing persistent domains) and some programs
(libvirt-glib, libvirt-sandbox) already parse the 'units' attribute.

Removes the extra 'k' from the tmpfs mount options, which is needed
because now we parse our own XML correctly.

Changes the default input unit to KiB to match documentation, fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=1015689

s/shoule/should
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

Commit 532fef36 added two-state 'need_alloc' and exposed
'want_sparse' which also only has two states.

Change their type from int to bool.

Commit 2d74822a renamed
"freebsdNodeGetCPUCount" to "appleFreebsdNodeGetCPUCount", leaving one
call to "freebsdNodeGetCPUCount".  Fix this other case.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

To simplify future patches dealing with this code, simplify and refactor
some conditions to switch statements.

We currently have other error codes in singular form, e.g.
VIR_ERR_NETWORK_EXIST. Cleanup the previous patch to match the form.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

I created a storage volume(eg: test) from a storage pool(eg:vg10) using
the following command:"virsh vol-create-as --pool vg10 --name test --capacity 300M."
When I re-executed the above command, the output was as the following:
"error: Failed to create vol test
 error: Storage volume not found: storage vol 'test' already exists"

I think the output "Storage volume not found" is not appropriate. Because in fact storage
vol test has been found at this time. And then I think virErrorNumber should includes
VIR_ERR_STORAGE_EXIST which can also be used elsewhere. So I make this patch. The result
is as following:
"error: Failed to create vol test
 error: storage volume 'test' exists already"

The virConnectPtr is passed around loads of nwfilter code in
order to provide it as a parameter to the callback registered
by the virt drivers. None of the virt drivers use this param
though, so it serves no purpose.

Avoiding the need to pass a virConnectPtr means that the
nwfilterStateReload method no longer needs to open a bogus
QEMU driver connection. This addresses a race condition that
can lead to a crash on startup.

The nwfilter driver starts before the QEMU driver and registers
some callbacks with DBus to detect firewalld reload. If the
firewalld reload happens while the QEMU driver is still starting
up though, the nwfilterStateReload method will open a connection
to the partially initialized QEMU driver and cause a crash.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The nwfilter driver only needs a reference to its private
state object, not a full virConnectPtr. Update the domUpdateCBStruct
struct to have a 'void *opaque' field instead of a virConnectPtr.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

None of the virNWFilterDefParse* methods require a virConnectPtr
arg, so just drop it
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 27e81517 set the payload size to 256 KB, which is
actually the max packet size, including the size of the header.

Reduce this by VIR_NET_MESSAGE_HEADER_MAX (24) and set
VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX to 262120, which was the original
value before increasing the limit in commit eb635de1.

This fixes the following error:
  error : nodeGetInfo:933 : this function is not supported
  by the connection driver: node info not implemented on this platform

The freebsdNodeGetCPUCount was renamed to appleFreebsdNodeGetCPUCount
in order to make more visible the fact, that it works on Mac OS X too.

Mac OS X can use sysctlbyname as same as FreeBSD to get the CPU
frequency. However, the MIB style name is different from FreeBSD's.
And the unit of the return frequency is also different.
Signed-off-by: NRyota Ozaki <ozaki.ryota@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This fixes the following error:
  error : virGetUserEnt:703 : Failed to find user record for uid '32654'

'32654' (it's random and varies) comes from getsockopt with
LOCAL_PEERCRED option. getsockopt returns w/o error but seems
to not set any value to the buffer for uid.

For Mac OS X, LOCAL_PEERCRED has to be used with SOL_LOCAL level.
With SOL_LOCAL, getsockopt returns a correct uid.

Note that SOL_LOCAL can be found in
/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/un.h.
Signed-off-by: NRyota Ozaki <ozaki.ryota@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

On RHEL 5, compilation fails with:

storage/storage_backend.c: In function 'createRawFile':
storage/storage_backend.c:339: warning: implicit declaration of function 'fallocate'
storage/storage_backend.c:339: warning: nested extern declaration of 'fallocate' [-Wnested-externs]

But:

$ grep HAVE_FALLOCATE config.h
/* #undef HAVE_FALLOCATE */

Huh? It turns out that in kernels that old, fallocate() is not
implemented (config.h is correct), but <linux/fs.h> defines
HAVE_FALLOCATE as an empty witness macro for a completely
different purpose.  Since storage_backend.c is including
<linux/fs.h> on RHEL 5, we are hosed by the kernel definition.
Newer kernels no longer pollute the namespace, and it's fairly
easy to convert to an expression that works with both the old
kernel witness and the new-style config.h (undefined or 1).

Problem introduced in commit 532fef36.

* src/storage/storage_backend.c (createRawFile): Avoid namespace
pollution from kernel, by checking HAVE_FALLOCATE for a value.
Signed-off-by: NEric Blake <eblake@redhat.com>

I tried to test ./configure --without-lxc --without-remote.
First, the build failed with some odd errors, such as an
inability to build xen, or link failures for virNetTLSInit.
But when you think about it, once there is no remote code,
all of libvirtd is useless, any stateful driver that depends
on libvirtd is also not worth compiling, and any libraries
used only by RPC code are not needed.  So I patched
configure.ac to make for some saner defaults when an
explicit disable is attempted.  Similarly, since we have
migrated virnetdevbridge into generic code, the workaround
for Linux kernel stupidity must not depend on stateful
drivers being in use.

Then there's 'make check' that needs segregation.

Wow - quite a bit of cleanup to make --without-remote useful :)

* configure.ac: Let --without-remote toggle defaults on stateful
drivers and other libraries.  Pick up Linux kernel workarounds
even when qemu and lxc are not being compiled.
* tests/Makefile.am (test_programs): Factor out programs that
require remote.
* src/libvirt_private.syms (rpc/virnet*.h): Move...
* src/libvirt_remote.syms: ...into new file.
* src/Makefile.am (SYM_FILES): Ship new syms file.
Signed-off-by: NEric Blake <eblake@redhat.com>

Fixed the safezero call for allocating the rest of the file after cloning
an existing volume; it used to always use a zero offset, causing it to
only allocate the beginning of the file.

Also modified file creation to try to use fallocate(2) to pre-allocate
disk space before copying any data to make sure it fails early on if disk
is full and makes sure we can skip zero blocks when copying file contents.

If fallocate isn't available we will zero out the rest of the file after
cloning and only use sparse cloning if client requested a lower allocation
than the input volume's capacity.
Signed-off-by: NOskari Saarenmaa <os@ohmu.fi>

My previous commit 7dc1d4ab was supposed to change safezero to allocate
1 megabyte at maximum, but had the logic reversed and will allocate 1
megabyte at minimum (and a lot more at maximum.)
Signed-off-by: NOskari Saarenmaa <os@ohmu.fi>

When starting the VM the guest balloon driver is not loaded at that
time. We need to ask numad for placement of the complete VM.