Add support for HVM direct kernel boot in libxl.  Also add a
test to verify domXML <-> native conversions.
Signed-off-by: NChunyan Liu <cyliu@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

In xl config, hvmloader is implied for hvm guests.  It is not
specified with the "kernel" option like xm config.  The "kernel"
option, along with "ramdisk" and "extra", is used for HVM direct
kernel boot.  Instead of using "kernel" option to populate
virDomainDef object's os.loader->path, use hvmloader discovered
when gathering capabilities.

This change required fixing initialization of capabilities in
the test utils and removing 'kernel = "/usr/lib/xen/boot/hvmloader"'
from the test config files.

xl and xm differ a bit in how <os> configuration is represented.
E.g. xl config supports <os><nvram .../></os> via its "bios"
setting.

Move the xenParseOS and xenFormatOS functions from xen_common.c
and copy to xen_xl.c and xen_xm.c so they can be customized for
xm vs xl config.  An unfortunate fallout is reordering of entries
in the test config files.

device_model is parsed in xenParseOS(), then later in
xenParseConfigCommon().  <emulator> is not part of <os>,
so makes sense to remove the parsing in xenParseOS().

Export xenConfigCopyString for use outside of xen_common.c
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

On rhel-6 is broken gcc that reports this warning:

util/virbuffer.c:500: error: logical '&&' with non-zero constant will
    always evaluate as true [-Wlogical-op]

Move the pragma directive before function virBufferEscapeString because
since commit aeb5262e this function uses 'strchr' too.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Invert the logical of retval and clean up code paths, especially goto's
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

ts.tv_nsec was off by a factor of 1000, making timeouts less than a
second in the future often expiring immediately.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Among all the monitor APIs some where checking if mon is NULL and some
were not. Since it's possible to have mon equal to NULL in case a second
call is attempted once entered the monitor. This requires that every
single API checks for the monitor.

This patch adds a macro that helps checking the state of the monitor and
either refactors existing checking code to use the macro or adds it in
case it was missing.

Apparently, files in /usr/lib/sysctl.d are usually prefixed with numbers
for easier ordering. Let's be consistent with this. I chose 60 for
libvirtd so that it goes after 50-default.conf.

https://bugzilla.redhat.com/show_bug.cgi?id=1084876Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Rather than erroring out make the best attempt to retrieve other data if
disks are inaccessible or missing. The failure will still be logged
though.

Since the bulk stats API is called on multiple domains an error like
this makes the API unusable. This regression was introduced by commit
596a1371

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

The <inbound/> element to <bandwidth/> has several attributes from
which two are mandatory. Well, from two at least one has to be
present: @average or @floor or both. Instead of inventing crazy RNG
schema, let's make all the attributes optional there and rely on our
parsing code to correctly handle the situation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The comment is describing arguments passed to the function.
However, there's no @ifmac argument. In 955af4d4 it was replaced
with @ifmac_ptr.  Unfortunately, the comment wasn't updated.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

gcc 4.1.2 (hello RHEL 5) on 32-bit platforms complains:

vircgrouptest.c: In function 'testCgroupGetPercpuStats':
vircgrouptest.c:627: warning: integer constant is too large for 'long' type
vircgrouptest.c:628: warning: this decimal constant is unsigned only in ISO C90
vircgrouptest.c:634: warning: integer constant is too large for 'long' type
vircgrouptest.c:635: warning: this decimal constant is unsigned only in ISO C90
vircgrouptest.c:636: warning: this decimal constant is unsigned only in ISO C90
vircgrouptest.c:644: warning: integer constant is too large for 'long' type

* tests/vircgrouptest.c (testCgroupGetPercpuStats): Use ULL suffix.
Signed-off-by: NEric Blake <eblake@redhat.com>

These cannot be represented in XML.

We have been stripping them, but only if the string had
characters that needed escaping: <>"'&

Extend the strcspn check to include control codes, and strip
them even if we don't do any escaping.

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

To prevent generating invalid XML.

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

Including them in the XML makes them unparsable.

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

Add virStringHasControlChars that checks if the string has
any control characters other than \t\r\n,
and virStringStripControlChars that removes them in-place.

For reuse with other Strip* functions.

Only for devices that have an alias.

The counterpart to VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED.

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

Throughout the code, we have several places need to construct a path
somewhere in /sys/class/net/... They are not consistent and nearly
each code piece invents its own way how to do it. So unify this by:

1) use virNetDevSysfsFile() wherever possible

2) At least use common macro SYSFS_NET_DIR declared in virnetdev.h at
   the rest of places which can't go with 1)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In one of my previous commits (49ed6cff) I've introduced a test
among with some files stored under virnetdevtestdata folder.
While this works perfectly within a git tree, the folder was not
getting into .tar.gz and therefore the dist-check would fail.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id 'b77ce18a' added a new bitmap, but neglected to virBitmapFree it

Commit a0670aef caused a regression in 'virsh event' and
'virsh qemu-monitor-event' - if a user tries to filter the
command to a specific domain, an error message is printed:

$ virsh event dom --loop
error: internal error: virsh qemu-monitor-event: no domain VSH_OT_DATA option

and then the command continues as though no domain had been
supplied (giving events for ALL domains, instead of the
requested one).  This is because the code was incorrectly
assuming that all "domain" options would be supplied via a
mandatory VSH_OT_DATA, even though "domain" is optional for
these two commands, so we had changed them to VSH_OT_STRING
to quit failing for other reasons (ever since it was decided
that VSH_OT_DATA and VSH_OT_STRING should no longer be
synonyms).

In looking at the situation, though, the code for looking up
a domain was making a pointless check for whether the option
exists prior to finding the option's string value, as
vshCommandOptStringReq does just fine at reporting any errors
when looking up a string whether or not the option was present.

So this is a case of regression fixing by pure code deletion :)

* tools/virsh-domain.c (vshCommandOptDomainBy): Drop useless filter.
* tools/virsh-interface.c (vshCommandOptInterfaceBy): Likewise.
* tools/virsh-network.c (vshCommandOptNetworkBy): Likewise.
* tools/virsh-nwfilter.c (vshCommandOptNWFilterBy): Likewise.
* tools/virsh-secret.c (vshCommandOptSecret): Likewise.
* tools/virsh.h (vshCmdHasOption): Drop unused function.
* tools/virsh.c (vshCmdHasOption): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

All the called functions already report an error.

If a virAsprintf() within the function fails, we call VIR_FREE()
over @rundir variable and jump onto cleanup label, where it is
freed again.  It doesn't hurt, but not make much sense too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit f6563bc3 introduced HMP impl of the function (so that a different
uglier function could be removed). Before the HMP code is called there's
a leftover check that the monitor is JSON which inhibits the code from
working.

Add the attribute and remove the check.

Quite a lot places set the 'ret' variable just once right before
returning it's value. Remove such usage.

Fix line spacing between functions, ensure that function return type is
on a separate line and reflow arguments for VIR_DEBUG statements.

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

Even though we have a mutex mechanism so that two clients don't spawn
two daemons, it's not strong enough. It can happen that while one
client is spawning the daemon, the other one fails to connect.
Basically two possible errors can happen:

  error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': Connection refused

or:

  error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': No such file or directory

The problem in both cases is, the daemon is only starting up, while we
are trying to connect (and fail). We should postpone the connecting
phase until the daemon is started (by the other thread that is
spawning it). In order to do that, create a file lock 'libvirt-lock'
in the directory where session daemon would create its socket. So even
when called from multiple processes, spawning a daemon will serialize
on the file lock. So only the first to come will spawn the daemon.
Tested-by: NRichard W. M. Jones <rjones@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Two non-static functions in virjson.c were missing their export info in
libvirt_private.syms, so they couldn't be used anywhere it the code (and
that's about to get changed).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It already had a virMutex inside, so this is just a cleanup.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Luckily we are allocating structs as clean memory and
PTHREAD_MUTEX_INITIALIZER is "{ 0 }", so nothing happened, but it should
still be created as lockable object.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The first two were a bit off.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Check proposed pool definitions to ensure they aren't trying to use the
same devices as currently defined definitions - disallow the duplicate