The target= setting in xl disk configuration can be used to encode
meta info that is meaningful to a backend. Leverage this fact to
support qdisk network disk types such as rbd. E.g. <disk> config
such as

   <disk type='network' device='disk'>
     <driver name='qemu' type='raw'/>
     <source protocol='rbd' name='pool/image'>
       <host name='mon1.example.org' port='6321'/>
       <host name='mon2.example.org' port='6322'/>
       <host name='mon3.example.org' port='6322'/>
     </source>
     <target dev='hdb' bus='ide'/>
     <address type='drive' controller='0' bus='0' target='0' unit='1'/>
   </disk>

can be converted to the following xl config (and vice versa)

  disk = [ "format=raw,vdev=hdb,access=rw,backendtype=qdisk,
            target=rbd:pool/image:auth_supported=none:mon_host=mon1.example.org\\:6321\\;mon2.example.org\\:6322\\;mon3.example.org\\:6322"
         ]

Note that in xl disk config, a literal backslash in target= must
be escaped with a backslash. Conversion of <auth> config is not
handled in this patch, but can be done in a follow-up patch.

Also add a test for the conversions.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The most formal form of xl disk configuration uses key=value
syntax to define each configuration item, e.g.

format=raw, vdev=xvda, access=rw, backendtype=phy, target=disksrc

Change the xl disk formatter to produce this syntax, which allows
target= to contain meta info needed to setup a network-based
disksrc (e.g. rbd, nbd, iscsi). For details on xl disk config
format, see  $xen-src/docs/misc/xl-disk-configuration.txt

Update the disk config in the tests to use the formal syntax.
But add tests to ensure disks specified with the positional
parameter syntax are correctly converted to <disk> XML.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

While at it, improve a few comments. No functional change.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Mostly labels names and whitespace.

No functional changes.

Since we have the macro there's no need for us to unwind it by
hand and check for mutually exclusive flags ourselves.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have macros that check and reject mutually exclusive
parameters to our commands. Use those instead of if-else tree.
At the same time, the variable @current becomes useless therefore
it is dropped.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It may be useful in some cases to call TristateSwitch helper with TristateBool.
Document that enum values equivalency in the code.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

In case you will specify graphics like this:

<graphics type='spice' port='-1'/>

or

<graphics type='spice' port='-1' tlsPort='6000'/>

libvirt will automatically add autoport='no'.  This leads to an issue
that in qemuProcessStop() we don't release that port because we are
releasing both port if autoport=yes or only port marked as reserved.

If autoport=no but we request to generate port via '-1' we need to mark
that port as reserved in order to release it.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1299696Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Checking whether x > 0 before looping over [0..x] items doesn't make
sense and multi-line body must have curly brackets around it.

Best viewed with '-w'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This does nothing more than adding the new device and capability.
The device is present since QEMU 2.6.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There's a check if a domain definition has any graphics card and
if so, we iterate over each one of them. This makes no sense,
because even if it has none we can still iterate over.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When getting a list of servers registered for a daemon, it's
returned as a dynamically allocated array filled in with pointers
to constant strings. Because the array is dynamic, it should be
freed when no longer needed (but not the strings!). Even the
function that creates the array suggests that.

==19446== 48 bytes in 3 blocks are definitely lost in loss record 821 of 1,034
==19446==    at 0x4C2C28E: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19446==    by 0x54BAFC8: virReallocN (viralloc.c:245)
==19446==    by 0x54BB0BE: virExpandN (viralloc.c:294)
==19446==    by 0x54BB391: virInsertElementsN (viralloc.c:436)
==19446==    by 0x164E3D: virNetDaemonGetServerNames (virnetdaemon.c:217)
==19446==    by 0x15616F: adminDaemonListServers (admin_server.c:52)
==19446==    by 0x155B8C: adminDispatchConnectListServers (admin.c:151)
==19446==    by 0x155FD8: adminDispatchConnectListServersHelper (admin_dispatch.h:101)
==19446==    by 0x568E862: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==19446==    by 0x568E3C3: virNetServerProgramDispatch (virnetserverprogram.c:307)
==19446==    by 0x5687B5B: virNetServerProcessMsg (virnetserver.c:135)
==19446==    by 0x5687C1B: virNetServerHandleJob (virnetserver.c:156)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

GIC v2 is the default, but checking against that specific version when
we want to know whether the default has been selected is potentially
error prone; using an alias instead makes it safer.

Recent changes to the handling of GIC version, specifically commit
2a7b11ea, have clearly defined what values are acceptable for the
version attribute of the <gic> element. Update the documentation
accordingly.

Similarly to VM startup always set the legacy affinity. Additionally we
don't need to report an explicit error since virProcessSetAffinity
reports them themselves.

Similarly to VM startup always set the legacy affinity. Additionally we
don't need to report an explicit error since virProcessSetAffinity
reports them themselves.

PostParse handles it for us now.

This causes some test suite churn; qemu's custom PostParse could is
now invoked before the generic AddImplicitControllers, so PCI
controllers end up sequentially in the XML before the generically
added IDE controllers. So it's just some XML reordering

Everywhere else in qemu driver code 'qemuCaps' is a virQEMUCapsPtr,
and virCapsPtr is generally named just 'caps'. Rename the offenders

Seems like the natural fit, since we are already adding other XML bits
in the PostParse routine.

Previously AddImplicitControllers was only called at the end of XML
parsing, meaning code that builds a DomainDef by hand had to manually
call it. Now those PostParse callers get it for free.

There's some test churn here; xen xm and sexpr test suite bits weren't
calling this before, but now they are, so you'll see new IDE controllers.
I don't think this will cause problems in practice, since the code already
needs to handle these implicit controllers like in the case when a user
defines their own XML.

virDomainObjWait is designed to be called in a loop. Make sure we break
the loop in case the domain dies to avoid waiting for an event which
will never happen.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Calling qemuProcessStop without a job opens a way to race conditions
with qemuDomainObjExitMonitor called in another thread. A real world
example of such a race condition:

  - migration thread (A) calls qemuMigrationWaitForSpice
  - another thread (B) starts processing qemuDomainAbortJob API
  - thread B signals thread A via qemuDomainObjAbortAsyncJob
  - thread B enters monitor (qemuDomainObjEnterMonitor)
  - thread B calls qemuMonitorSend
  - thread A awakens and calls qemuProcessStop
  - thread A calls qemuMonitorClose and sets priv->mon to NULL
  - thread B calls qemuDomainObjExitMonitor with priv->mon == NULL
  => monitor stays ref'ed and locked

Depending on how lucky we are, the race may result in a memory leak or
it can even deadlock libvirtd's event loop if it tries to lock the
monitor to process an event received before qemuMonitorClose was called.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Stopping a domain without a job risks a race condition with another
thread which started a job a which does not expect anyone else to be
messing around with the same domain object.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Only a small portion of processGuestPanicEvent was enclosed within a
job, let's make sure we use the job for all operations to avoid race
conditions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

When destroying a domain we need to make sure we will be able to start a
job no matter what other operations are running or even stuck in a job.
This is done by killing the domain before starting the destroy job.

Let's introduce qemuProcessBeginStopJob which combines killing a domain
and starting a job in a single API which can be called everywhere we
need a job to stop a domain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Ending a nested job is no different from ending any other (non-async)
job, after all the code in qemuDomainBeginJobInternal does not handle
them differently either. Thus we should call qemuDomainObjEndJob to stop
nested jobs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

qemuDomainHelperGetVcpus would correctly return an array of
virVcpuInfoPtr structs for online vcpus even for sparse topologies, but
the loop that fills the returned typed parameters would number the vcpus
incorrectly. Fortunately sparse topologies aren't supported yet.

VM startup and CPU hotplug always set the affinity regardless of cgroups
support. Use the same approach for the pinning API.

Both errors from the cgroups code and from the affinity code would be
overwritten by the API. Report the more specific error.

Use the helper that does not return errors to fix spuriously looking
dead return of -1.

Rather than setting flags to -1 if none were specified, move the logic
to use the old API to the place where we need to decide. It simplifies
the logic a bit.

Since commit 51045df0, the QEMU_CAPS_DEVICE capability is enabled
automatically and shouldn't be passed as an argument to DO_TEST();
however, commit 998a936c accidentally introduced few such uses.

When virt-admin is run with valgrind, this kind of output can be obtained:

HEAP SUMMARY:
  in use at exit: 134,589 bytes in 1,031 blocks
  total heap usage: 2,667 allocs, 1,636 frees, 496,755 bytes allocated

88 bytes in 1 blocks are definitely lost in loss record 82 of 128
 at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 by 0x52F6D1F: virAllocVar (viralloc.c:560)
 by 0x5350268: virObjectNew (virobject.c:193)
 by 0x53503E0: virObjectLockableNew (virobject.c:219)
 by 0x4E3BBCB: virAdmConnectNew (datatypes.c:832)
 by 0x4E38495: virAdmConnectOpen (libvirt-admin.c:209)
 by 0x10C541: vshAdmConnect (virt-admin.c:107)
 by 0x10C7B2: vshAdmReconnect (virt-admin.c:163)
 by 0x10CC7C: cmdConnect (virt-admin.c:298)
 by 0x110838: vshCommandRun (vsh.c:1224)
 by 0x10DFD8: main (virt-admin.c:862)

 LEAK SUMMARY:
    definitely lost: 88 bytes in 1 blocks
    indirectly lost: 0 bytes in 0 blocks
    possibly lost: 0 bytes in 0 blocks
    still reachable: 134,501 bytes in 1,030 blocks
    suppressed: 0 bytes in 0 blocks

This is because virNetClientSetCloseCallback was being reinitialized
incorrectly. By resetting the callbacks in a proper way, the leak is fixed.

A login session with the vSphere API might expire after some idle time.
The esxVI_EnsureSession function uses the SessionIsActive function to
check if the current session has expired and a relogin needs to be done.

But the SessionIsActive function needs the Sessions.ValidateSession
privilege that is considered as an admin level privilege.

Only vCenter actually provides the SessionIsActive function. This results
in requiring an admin level privilege even for read-only operations on
a vCenter server.

ESX and VMware Server don't provide the SessionIsActive function and
the code already works around that. Use the same workaround for vCenter
again.

This basically reverts commit 5699034b.

Commit f1a89a8b allowed parsing configs from /etc/libvirt
without validating the emulator capabilities.

Check for the presence of os->type.machine even if the
VIR_DOMAIN_DEF_PARSE_SKIP_OSTYPE_CHECKS flag is set,
otherwise the daemon can crash on carelessly crafted input
in the config directory.

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