So that a domain xml which doesn't have "placement" specified, but
"cpuset" is specified, could be parsed. And in this case, the
"placement" mode will be set as "static".

If console[0] is an alias for serial[0], do not enforce the former to
have a PTY source type. This breaks serial consoles on stdio and makes
no sense.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

When using the xm/xend stack to manage instances there is a bug
that causes the emulated interfaces to be unusable when the vif
config contains type=ioemu.

The current code already has a special quirk to not use this
keyword if no specific model is given for the emulated NIC
(defaulting to rtl8139).
Essentially it works because regardless of the type argument,i
the Xen stack always creates emulated and paravirt interfaces and
lets the guest decide which one to use. So neither xl nor xm stack
actually require the type keyword for emulated NICs.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

'omitted' was mispelt 'commited' twice. One of the sentences with
the typo was also missing an 'is' ('each VCPU *is* pinned to all...')
which I added in this commit while I was at it.

It's vznet.conf not vznetctl.conf, see e.g.:

http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetcfg.in;h=e91f5c4a0744c1ea149e1b8c241b666052e10b12;hb=HEAD

lvcreate want's the parent pool's name, not the pool path
lvchange and lvremove want lv specified as $vgname/$lvname

This largely worked before because these commands strip off a
starting /dev. But https://bugzilla.redhat.com/show_bug.cgi?id=714986
is from a user using a 'nested VG' that was having problems.

I couldn't find any info on nested LVM and the reporter never responded,
but I reproduced with XML that specified a valid source name, and
set target path to a symlink.

As explained in previous patch, numad will balance the affinity
dynamically, so reflecting the cpuset from numad at the first
time doesn't make much case, and may just could cause confusion.
(cherry picked from commit 8fb2164c)

Instead of returning a CPUs list, numad returns NUMA node
list instead, this patch is to convert the node list to
cpumap before affinity setting. Otherwise, the domain
processes will be pinned only to CPU[$numa_cell_num],
which will cause significiant performance losses.

Also because numad will balance the affinity dynamically,
reflecting the cpuset from numad back doesn't make much
sense then, and it may just could produce confusion for
the users. Thus the better way is not to reflect it back
to XML. And in this case, it's better to ignore the cpuset
when parsing XML.

The codes to update the cpuset is removed in this patch
incidentally, and there will be a follow up patch to ignore
the manually specified "cpuset" if "placement" is "auto",
and document will be updated too.
(cherry picked from commit ccf80e36)

since this isn't available on older kernels such as Debian Squeeze's
2.6.32. This make --with-macvtap=check work as expected.
(cherry picked from commit a2996926)

The linux-2.6.32 kernel header does not yet define IFLA_VF_MAX and others,
which breaks compiling a new libvirt on old systems like Debian Squeeze.

(I also have to add --without-macvtap --disable-werror --without-virtualport to
 ./configure to get it to compile.)
Signed-off-by: NPhilipp Hahn <hahn@univention.de>
(cherry picked from commit d7451bdd)

Although it should be harmless to do:
    disk = disk = def->disks[i]
some not-so-wise compilers may fool around.
Besides, such assignment is useless here.
(cherry picked from commit e14d6571)

If placement mode is AUTO, on some return paths char *cpumap or
char *nodeset are leaked.
(cherry picked from commit 354e6d4e)

On newer xend (v3.x and after) there is no state and domid reported
for inactive domains. When initially creating connections this is
handled in various places by assigning domain->id = -1.
But once an instance has been running, the id is set to the current
domain id. And it does not change when the instance is shut down.
So when querying the domain info, the hypervisor driver, which gets
asked first will indicate it cannot find information, then the
xend driver is asked and will set the status to NOSTATE because it
checks for the -1 domain id.
Checking domain/status for 0 seems to be more reliable for that.

One note: I am not sure whether the domain->id also should get set
back to -1 whenever any sub-driver thinks the instance is no longer
running.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=746007
BugLink: http://bugs.launchpad.net/bugs/929626Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit 26e9ef47)

This patch adds a netlink callback when migrating a VEPA enabled
virtual machine.  It fixes a Bug where a VM would not request a port
association when it was cleared by lldpad.

This patch requires the latest git version of lldpad to work.
Signed-off-by: ND. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
(cherry picked from commit 997366ca)

If dynamic_ownership is off and we are creating a file on NFS
we force chown. This will fail as chown/chmod are not supported
on NFS. However, with no dynamic_ownership we are not required
to do any chown.
(cherry picked from commit b1256816)

* daemon/libvirtd-config.c (daemonConfigFree): fix memory leaks.

How to reproduce?

% make && make -C tests check TESTS=libvirtdconftest
% cd tests && valgrind -v --leak-check=full ./libvirtdconftest

actual result:

==11008== 185 bytes in 5 blocks are definitely lost in loss record 3 of 5
==11008==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==11008==    by 0x39CF07F6E1: strdup (strdup.c:43)
==11008==    by 0x406626: daemonConfigLoadOptions (libvirtd-config.c:438)
==11008==    by 0x406800: daemonConfigLoadData (libvirtd-config.c:492)
==11008==    by 0x403CCF: testCorrupt (libvirtdconftest.c:110)
==11008==    by 0x404FAD: virtTestRun (testutils.c:145)
==11008==    by 0x403A34: mymain (libvirtdconftest.c:219)
==11008==    by 0x404687: virtTestMain (testutils.c:700)
==11008==    by 0x39CF01ECDC: (below main) (libc-start.c:226)
==11008==
==11008== LEAK SUMMARY:
==11008==    definitely lost: 185 bytes in 5 blocks
Signed-off-by: NAlex Jia <ajia@redhat.com>
(cherry picked from commit d0eaf4b1)

Conflicts:

	daemon/libvirtd-config.c

The new safe console handling introduced a possibility to deadlock the
qemu driver when a new console connection forcibly disconnects a
previous console stream that belongs to an already closed connection.

The virStreamFree function calls subsequently a the virReleaseConnect
function that tries to lock the driver while discarding the connection,
but the driver was already locked in qemuDomainOpenConsole.

Backtrace of the deadlocked thread:
0  0x00007f66e5aa7f14 in __lll_lock_wait () from /lib64/libpthread.so.0
1  0x00007f66e5aa3411 in _L_lock_500 () from /lib64/libpthread.so.0
2  0x00007f66e5aa322a in pthread_mutex_lock () from/lib64/libpthread.so.0
3  0x0000000000462bbd in qemudClose ()
4  0x00007f66e6e178eb in virReleaseConnect () from/usr/lib64/libvirt.so.0
5  0x00007f66e6e19c8c in virUnrefStream () from /usr/lib64/libvirt.so.0
6  0x00007f66e6e3d1de in virStreamFree () from /usr/lib64/libvirt.so.0
7  0x00007f66e6e09a5d in virConsoleHashEntryFree () from/usr/lib64/libvirt.so.0
8  0x00007f66e6db7282 in virHashRemoveEntry () from/usr/lib64/libvirt.so.0
9  0x00007f66e6e09c4e in virConsoleOpen () from /usr/lib64/libvirt.so.0
10 0x00000000004526e9 in qemuDomainOpenConsole ()
11 0x00007f66e6e421f1 in virDomainOpenConsole () from/usr/lib64/libvirt.so.0
12 0x00000000004361e4 in remoteDispatchDomainOpenConsoleHelper ()
13 0x00007f66e6e80375 in virNetServerProgramDispatch () from/usr/lib64/libvirt.so.0
14 0x00007f66e6e7ae11 in virNetServerHandleJob () from/usr/lib64/libvirt.so.0
15 0x00007f66e6da897d in virThreadPoolWorker () from/usr/lib64/libvirt.so.0
16 0x00007f66e6da7ff6 in virThreadHelper () from/usr/lib64/libvirt.so.0
17 0x00007f66e5aa0c5c in start_thread () from /lib64/libpthread.so.0
18 0x00007f66e57e7fcd in clone () from /lib64/libc.so.6

* src/qemu/qemu_driver.c: qemuDomainOpenConsole()
        -- unlock the qemu driver right after acquiring the domain
        object
(cherry picked from commit 3d3de46a)

I noticed these compiler warnings when building for the s390 architecture.

* src/node_device/node_device_udev.c (udevDeviceMonitorStartup):
Mark unused variable.
* src/nodeinfo.c (linuxNodeInfoCPUPopulate): Avoid unused variable.
(cherry picked from commit 9011a494)

The documentation for the flag doesn't clearly state that the flag only
enhances the output and the user needs to specify other flags to list
inactive domains, that are enhanced by this flag.
(cherry picked from commit cc510065)

(cherry picked from commit 20171c8d)

Below code failed to compile on a 32 bit machine with error

typewrappers.c: In function 'libvirt_intUnwrap':
typewrappers.c:135:5: error: logical 'and' of mutually exclusive tests is always false [-Werror=logical-op]
cc1: all warnings being treated as errors

The patch fixes this error.

(cherry picked from commit 4e9bb1df)

I found typo in UML driver.

MATSUDA Daiki
(cherry picked from commit 257191c9)

Leak introduced in commit 0436d328.  If we allocate an actions array,
but fail early enough to never consume it with the qemu monitor
transaction call, we leaked memory.

But our semantics of making the transaction command free the caller's
memory is awkward; avoiding the memory leak requires making every
intermediate function in the call chain check for error.  It is much
easier to fix things so that the function that allocates also frees,
while the call chain leaves the caller's data intact.  To do that,
I had to hack our JSON data structure to make it easy to protect a
portion of an arbitrary JSON tree from being freed.

* src/util/json.h (virJSONType): Name the enum.
(_virJSONValue): New field.
* src/util/json.c (virJSONValueFree): Use it to protect a portion
of an array.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONTransaction): Avoid
freeing caller's data.
* src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive):
Free actions array on failure.
(cherry picked from commit 14135609)

We can tell qemuDomainSnapshotFSThaw if we want it to report errors or
not. However, if we don't want to and an error has been already set by
previous qemuReportError() we must keep copy of that error not just a
pointer to it. Otherwise, it get overwritten if FSThaw reports an error.
(cherry picked from commit 650da0e9)

This causes an implicit vkbd device to be added which takes
6min to finally fail being initialized in the guest.

http://lists.xen.org/archives/html/xen-devel/2012-04/msg00409.htmlSigned-off-by: NStefan Bader <stefan.bader@canonical.com>
(cherry picked from commit fb98da00)

gcc 4.7 warns about uninitialized struct members

* tests/testutilsqemu.c (testQemuCapsInit): Populate new members.
* tests/viruritest.c (mymain): Likewise.
(cherry picked from commit 72505073)

When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
three of the tests failed to compile.

cputest.c and qemuxml2argvtest.c had non-static structs defined
inside the macro that was being repeatedly invoked. Due to some so-far
unidentified change in gcc, the stack space used by variables defined
inside { } is not recovered/re-used when the block ends, so all these
structs have become additive (this is the same problem worked around
in commit cf57d345). Fortunately, these two files could be fixed with
a single line addition of "static" to the struct definition in the
macro.

virnettlscontexttest.c was a bit different, though. The problem structs
in the do/while loop of macros had non-constant initializers, so it
took a bit more work and piecemeal initialization instead of member
initialization to get things to be happy.

In an ideal world, none of these changes should be necessary, but not
knowing how long it will be until the gcc regressions are fixed, and
since the code is just as correct after this patch as before, it makes
sense to fix libvirt's build for -O0 while also reporting the gcc
problem.
(cherry picked from commit 06a1a45c)

This got dropped with 300e60e1

Cheers,
 -- Guido
(cherry picked from commit 4eb1c256)

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

rpm builds for i686 were failing with a segfault in
networkxml2argvtest. Running under valgrind showed that a region of
memory was being referenced after it had been freed (as the result of
realloc - see the valgrind report in the BZ).

The problem (in replaceTokens() - added in commit 22ec60, meaning this
bug was in 0.9.10 and 0.9.11) was that the pointers token_start and
token_end were being computed based on the value of *buf, then *buf
was being realloc'ed (potentially moving it), then token_start and
token_end were used without recomputing them to account for movement
of *buf.

The solution is to change the code so that token_start and token_end
are offsets into *buf rather than pointers. This way there is only a
single pointer to the buffer, and nothing needs readjusting after a
realloc. (You may note that some uses of token_start/token_end didn't
need to be changed to add in "*buf +" - that's because there ended up
being a +*buf and -*buf which canceled each other out).

DV gets the credit for finding this bug and pointing out the valgrind
report.
(cherry picked from commit bde32b1a)

Detected by valgrind. Leaks are introduced in commit b22eaa75.

* src/conf/domain_conf.c (virDomainDiskDefParseXML): fix memory leaks.

How to reproduce?

% make && make -C tests check TESTS=qemuxml2argvtest
% cd tests && valgrind -v --leak-check=full ./qemuxml2argvtest

actual result:

==2143== 12 bytes in 2 blocks are definitely lost in loss record 74 of 179
==2143==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==2143==    by 0x39D90A67DD: xmlStrndup (xmlstring.c:45)
==2143==    by 0x4F5EC0: virDomainDiskDefParseXML (domain_conf.c:3438)
==2143==    by 0x502F00: virDomainDefParseXML (domain_conf.c:8304)
==2143==    by 0x505FE3: virDomainDefParseNode (domain_conf.c:9080)
==2143==    by 0x5069AE: virDomainDefParse (domain_conf.c:9030)
==2143==    by 0x41CBF4: testCompareXMLToArgvHelper (qemuxml2argvtest.c:105)
==2143==    by 0x41E5DD: virtTestRun (testutils.c:145)
==2143==    by 0x416FA3: mymain (qemuxml2argvtest.c:399)
==2143==    by 0x41DCB7: virtTestMain (testutils.c:700)
==2143==    by 0x39CF01ECDC: (below main) (libc-start.c:226)
Signed-off-by: NAlex Jia <ajia@redhat.com>
(cherry picked from commit 80d476a9)

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

Basically, openvz dropped strict version numbering (3.1 vs 3.1.0),
which caused parsing to fail.
(cherry picked from commit 37075dfe)

* configure.ac: Set WITH_SYSCTL only on Linux hosts
* daemon/Makefile.am: Conditionalize install-sysctl using WITH_SYSCTL
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Cc: Jason Helfman <jhelfman@e-e.com>
(cherry picked from commit e7eca6e4)

Every now & then, with parallel builds, we get a failure to
validate hvsupport.html.in.  I eventually noticed that this
is because we get 2 instances of the generator running at
once.

We already list hvsupport.html.in in BUILT_SOURCES but this
was not working. It turns out the flaw is that we were
adding deps to the 'all:' target instead of the 'all-am:'
target. BUILT_SOURCES is a dep of 'all', so any custom
targets written in Makefile.am must use 'all-am:' so that
they don't get run until BUILT_SOURCES are completely
generated

* docs/Makefile.am: s/all/all-am/
(cherry picked from commit 4f4b496e)

(cherry picked from commit f94d9c57)

This symbol is used in the test suites
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 06180ca4)

Some of the test suites use fprintf with format specifiers
that are not supported on Win32 and are not fixed by gnulib.

The mingw32 compiler also has trouble detecting ssize_t
correctly, complaining that 'ssize_t' does not match
'signed size_t' (which it expects for %zd). Force the
cast to size_t to avoid this problem

* tests/testutils.c, tests/testutils.h: Fix printf
  annotation on virTestResult. Use virVasprintf
  instead of vfprintf
* tests/virhashtest.c: Use VIR_WARN instead of fprintf(stderr).
  Cast to size_t to avoid mingw32 compiler bug
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit f48de0f1)

If the daemon is restarted it will lose list of active
USB devices assigned to active domains. Therefore we need
to rebuild this list on qemuProcessReconnect().
(cherry picked from commit ea3bc548)

To prevent assigning one USB device to two domains,
we keep a list of assigned USB devices. On domain
startup - qemuProcessStart() - we insert devices
used by domain into the list but remove them only
on detach-device. Devices are, however, released
on qemuProcessStop() as well.
(cherry picked from commit e2f5dd61)

and add debug message when adding USB device
to the list of active devices.
(cherry picked from commit b2c7b9ee)