Due to a copy and paste error, the scheduler 'cap' parameter
was over-writing the 'weight' parameter when preparing the
return parameters in libxlDomainGetSchedulerParametersFlags.
As a result, the scheduler weight was never shown when getting
schedinfo and setting the weight failed as well

virsh  schedinfo testvm
Scheduler      : credit
cap            : 0

virsh  schedinfo testvm --cap 50 --weight 500
Scheduler      : credit
error: invalid scheduler option: weight

The obvious fix is to assign the 'caps' parameter to the correct
item in the parameter list.
Reported-by: NVolo M. <vm@vovs.net>

Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Acked-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Add support for formating/parsing libxl channels.

Syntax on xen libxl goes as following:
channel=["connection=pty|socket,path=/path/to/socket,name=XXX",...]
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Acked-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

And allow libxl to handle channel element which creates a Xen
console visible to the guest as a low-bandwitdh communication
channel. If type is PTY we also fetch the tty after boot using
libxl_channel_getinfo to fetch the tty path. On socket case,
we autogenerate a path if not specified in the XML. Path autogenerated
is slightly different from qemu driver: qemu stores also on
"channels/target" but it creates then a directory per domain with
each channel target name. libxl doesn't appear to have a clear
definition of private files associated with each domain, so for
simplicity we do it slightly different. On qemu each autogenerated
channel goes like:

channels/target/<domain-name>/<target name>

Whereas for libxl:

channels/target/<domain-name>-<target name>

Should note that if path is not specified it won't persist,
existing only on live XML, unless user had initially specified it.
Since support for libxl channels only came on Xen >= 4.5 we therefore
need to conditionally compile it with LIBXL_HAVE_DEVICE_CHANNEL.

After this patch and having a qemu guest agent:
 $ cat domain.xml | grep -a1 channel | head -n 5 | tail -n 4
 <channel type='unix'>
   <source mode='bind' path='/tmp/channel'/>
   <target type='xen' name='org.qemu.guest_agent.0'/>
 </channel>

 $ virsh create domain.xml
 $ echo '{"execute":"guest-network-get-interfaces"}' | socat
 stdio,ignoreeof  unix-connect:/tmp/channel

 {"execute":"guest-network-get-interfaces"}
 {"return": [{"name": "lo", "ip-addresses": [{"ip-address-type": "ipv4",
 "ip-address": "127.0.0.1", "prefix": 8}, {"ip-address-type": "ipv6",
 "ip-address": "::1", "prefix": 128}], "hardware-address":
 "00:00:00:00:00:00"}, {"name": "eth0", "ip-addresses":
 [{"ip-address-type": "ipv4", "ip-address": "10.100.0.6", "prefix": 24},
 {"ip-address-type": "ipv6", "ip-address": "fe80::216:3eff:fe40:88eb",
 "prefix": 64}], "hardware-address": "00:16:3e:40:88:eb"}, {"name":
 "sit0"}]}
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

So far only guestfwd and virtio were supported. Add an additional
for Xen as libxl channels create a Xen console visible to the guest.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with
caps == NULL, causing the following crash:

    Program received signal SIGSEGV, Segmentation fault.
    #0  0x00007ffff788775f in virQEMUCapsInitHostCPUModel
        (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at
        src/qemu/qemu_capabilities.c:2969
    #1  0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal
        (caps=caps@entry=0x0, binary=<optimized out>,
        libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0,
        runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295,
        qmpOnly=true) at src/qemu/qemu_capabilities.c:4039
    #2  0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at
        tests/qemucapsprobe.c:73

Caused by v2.2.0-182-g68c70118.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

So far, when it comes to 'virsh update-device --config' of disks
we are limiting ourselves for just the disk source update and
just for CDROMs and floppies. This makes no sense. Especially if
you look around and see that we already allow full update to
graphics and net devices. So let's just take whatever XML user
wants to have there and replace our internal definition with it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

libxl events are delivered to libvirt via the libxlDomainEventHandler
callback registered with libxl. Documenation in
$xensrc/tools/libxl/libxl_event.h states that the callback "may occur
on any thread in which the application calls libxl". This can result
in deadlock since many of the libvirt callees of libxl hold a lock on
the virDomainObj they are working on. When the callback is invoked, it
attempts to find a virDomainObj corresponding to the domain ID provided
by libxl. Searching the domain obj list results in locking each obj
before checking if it is active, and its ID equals the requested ID.
Deadlock is possible when attempting to lock an obj that is already
locked further up the call stack. Indeed, Max Ustermann reported an
instance of this deadlock

https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html

Guido Rossmueller also recently stumbled across it

https://www.redhat.com/archives/libvir-list/2016-September/msg00287.html

Fix the deadlock by moving the lookup of virDomainObj to the
libxlDomainShutdownThread. After this patch, libxl events are
enqueued on the libvirt side and processed by dedicated thread,
avoiding the described deadlock.
Reported-by: NMax Ustermann <ustermann78@web.de>
Reported-by: NGuido Rossmueller <Guido.Rossmueller@gdata.de>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

enum types are unsigned and the qemuGetCompressionProgram
function can return -1 on error. It is therefore inappropriate
to return an enum type. This fixes a build error where the
internal 'ret' variable was used in a comparison with -1

../../src/qemu/qemu_driver.c: In function 'qemuGetCompressionProgram':
../../src/qemu/qemu_driver.c:3280:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
../../src/qemu/qemu_driver.c:3289:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
cc1: all warnings being treated as errors
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

When creating a copy of virDomainDef we save ourselves the
trouble of writing deep-copy functions and just format and parse
back domain/device XML. However, the XML we are parsing was
already fully formatted - there is no reason to run post parse
callbacks (which fill in blanks - there are none!).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is an internal flag that prevents our two entry points to
XML parsing (virDomainDefParse and virDomainDeviceDefParse) from
running post parse callbacks. This is expected to be used in
cases when we already have full domain/device XML and we are just
parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We can't rely on def->emulator path. It may be provided by user
as we give them opportunity to provide their own XML for
migration. Therefore the path may point to just whatever binary
(or even to a non-existent file). Moreover, this path is meant
for destination, but the capabilities lookup is done on source.
What we can do is to assume same capabilities for post parse
callbacks as the running domain has. They will be used just to
add some default models/controllers/devices/... anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseString.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseXML and subsequently virDomainDefPostParse too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Remove unnessary translated message marker _()
for the VIR_WARN messages.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Based upon a patch from Chen Hanxiao <chenhanxiao@gmail.com>, rather than
need to call virFindFileInPath twice, let's just save the path and pass it
along with the compressed type. (NB: the second call would be in virExec as
called from virCommandRunAsync which is called from qemuMigrationToFile
using the argument 'compressor' which up to this point would be the string
from the cfg file that isn't the fully qualified path).

Since we now have the path, we can remove qemuCompressProgramName which
would return NULL or the string representation of the compress type.

There's only one caller and the code is duplicitous just converting the
recently converted cfg image name back into it's string value in order to
get/find the path to the image.  A subsequent patch can return this path.

Let's do some more code reuse - there are 3 other callers that care to
check/get the compress program. Each of those though cares whether the
requested cfg image is valid and exists. So, add a parameter to handle
those cases.

NB: We won't need to initialize the returned value in the case where
the cfg image doesn't exist since the called program will handle that.

Add a new parameter 'styleFormat' to be used when printing the
warning message so that it's "clearer" what style of compression
call caused the error. Add that style to both messages as a paremter.

Also a VIR_WARN error message doesn't need to be translated
 (e.g. inside _()), so remove the need for the translation.

There's only one caller now anyway... Besides it's just a shell for
getting the compress type.  Subsequent patches will return the path
to the compression program.

Split out the guts of getCompressionType to perform the same functionality
in the new helper program with a subsequent patch goal to be reusable for
other callers making similar checks/calls to ensure the compression type
is valid and that the compression program cannot be found.

Rather than calling getCompressionType from each of the callers, just call
it from doCoreDump.  A subsequent patch will be adjust the code even more.

A subsequent patch will adjust the 3 callers to just call from doCoreDump.

qemu-bridge-helper is only called from libvirtd, it has to be moved
from the qemu domain abstraction to the usr.sbin.libvirtd profile.

If passing an empty usbdevice_list to libxl, qemu will always get an
-usb parameter for HVM guests with only non-USB input devices. This
causes qemu to crash when passing pvusb device on HVM guests.

The solution is to allocate the list only when an item to put in it
is found.

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

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>