The error count statistic is not supported by qemu, so there's no need
to pass the variables around if the result is ignored anyways.

All the setters are the same code except for parameter name and
variable, so they can be converted to a macro to save a ton of
duplicated code.

Error messages are already set in all code paths returning -1 from
networkGetNetworkAddress, so we don't want to overwrite them.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When creating qemu capabilities, a dummy virDomainObj is created just
because our monitor code expects that. However, the object is created
locked already. Then, under cleanup label, we simply unref the object
which results in whole domain object to be disposed. The object lock
is destroyed subsequently, but hey - it's still locked:

==24845== Thread #14's call to pthread_mutex_destroy failed
==24845==    with error code 16 (EBUSY: Device or resource busy)
==24845==    at 0x4C3024E: pthread_mutex_destroy (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==24845==    by 0x531F72E: virMutexDestroy (virthread.c:83)
==24845==    by 0x5302977: virObjectLockableDispose (virobject.c:237)
==24845==    by 0x5302A89: virObjectUnref (virobject.c:265)
==24845==    by 0x1DD37866: virQEMUCapsInitQMP (qemu_capabilities.c:3397)
==24845==    by 0x1DD37CC6: virQEMUCapsNewForBinary (qemu_capabilities.c:3481)
==24845==    by 0x1DD381E2: virQEMUCapsCacheLookup (qemu_capabilities.c:3609)
==24845==    by 0x1DD30F8A: virQEMUCapsInitGuest (qemu_capabilities.c:744)
==24845==    by 0x1DD31889: virQEMUCapsInit (qemu_capabilities.c:1020)
==24845==    by 0x1DD7DD36: virQEMUDriverCreateCapabilities (qemu_conf.c:888)
==24845==    by 0x1DDC57C0: qemuStateInitialize (qemu_driver.c:803)
==24845==    by 0x53DC743: virStateInitialize (libvirt.c:777)
==24845==
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 4bbe1029 fixed a problem in commit f7afeddc by moving the call
to virNetDevGetIndex() to a location common to all interface types (so
that the nicindex array would be filled in for macvtap as well as tap
interfaces), but the location was *too* common, as the original call
to virNetDevGetIndex() had been in a section qualified by "if
(cfg->privileged)". The result was that the "fixed" libvirtd would try
to call virNetDevGetIndex() even for session mode libvirtd, and end up
failing with the log message:

  Unable to open control socket: Operation not permitted

To remedy that, this patch qualifies the call to virNetDevGetIndex()
in its new location with cfg->privileged.

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

Follow-up to the IOThread review on CPU affinity map manipulation:

http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html

indicates that the GetEmulatorPinInfo could use similar algorithm adjustments
which is what this patch does.

Follow-up to the IOThread review on CPU affinity map manipulation:

http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html

indicates that the GetVcpuPinInfo could use similar algorithm adjustments
which is what this patch does.

By adding a call and check of return of virBitmapToData to the
IOThreads code, my Coverity checker lets me know qemuDomainHelperGetVcpus
also needs to check the status...

Based on review:

http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html

Adjust how the cpumap and cpumaplen to be returned are generated

Depending on the flags passed, either attempt to return the active/live
IOThread data for the domain or the config data.

The active/live path will call into the Monitor in order to get the
IOThread data and then correlate the thread_id's returned from the
monitor to the currently running system/threads in order to ascertain
the affinity for each iothread_id.

The config path will map each of the configured IOThreads and return
any configured iothreadspin data
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

There was a mess in the way how we store unlimited value for memory
limits and how we handled values provided by user.  Internally there
were two possible ways how to store unlimited value: as 0 value or as
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED.  Because we chose to store memory
limits as unsigned long long, we cannot use -1 to represent unlimited.
It's much easier for us to say that everything greater than
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED means unlimited and leave 0 as valid
value despite that it makes no sense to set limit to 0.

Remove unnecessary function virCompareLimitUlong.  The update of test
is to prevent the 0 to be miss-used as unlimited in future.

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

Pass the TPM file descriptor to QEMU via command line.
Instead of passing /dev/tpm0 we now pass /dev/fdset/10 and the additional
parameters -add-fd set=10,fd=20.

This addresses the use case when QEMU is started with non-root privileges
and QEMU cannot open /dev/tpm0 for example.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Move the TPM command line build code into its own function.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

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

There's been a bug report appearing on the qemu-devel list, that
libvirt is unable to pass spaces in disk serial number [1]. Not only
our RNG schema forbids that, the code is not prepared either. However,
with a bit of escaping (if needed) we can allow spaces there.

1: https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg04041.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

When the domain's source disk type is network, if source protocol is rbd
or sheepdog, the 'if().. break' will end the current case, which lead to
miss check the driver type is raw or qcow2. Libvirt will allow to create
internal snapshot for a running domain with raw format disk which based
on rbd storage.

While both protocols support internal snapshots of the disk qemu is not
able to use it as it requires some place to store the memory image. The
check if the disk is backed by a qcow2 image needs to be executed
always.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1179533Signed-off-by: NShanzhi Yu <shyu@redhat.com>

Inactive domains can still be stuck in a job or other problems. Add a
way to detect it.

Previously when a domain would get stuck in a domain job due to a
programming mistake we'd report the following control state:

$ virsh domcontrol domain
occupied (1424343406.150s)

The timestamp is invalid as the monitor was not entered for that domain.
We can use that to detect that the domain has an active job and report a
better error instead:

$ virsh domcontrol domain
error: internal (locking) error

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

So, libvirt uses pid file to track pid of started qemus. Whenever
a domain is started, its pid is put into corresponding pid file.
The pid file path is generated based on domain name and stored
into domain object internals. However, it's not stored in the
status XML and therefore lost on daemon restarts. Hence, later,
when domain is being shut down, the daemon does not know which
pid file to unlink, and the correct pid file is left behind. To
avoid this, lets generate the pid file path again in
qemuProcessReconnect().
Reported-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of checking defaultMode for every channel that has no mode
configured, test it only once outside of channel loop.  This fixes a bug
that in case all possible channels are fore example set to insecure, but
defaultMode is set to secure, we wouldn't auto-generate TLS port.  This
results in failure while starting a guest.

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

We have two different places that needs to be updated while touching
code for allocation spice ports.  Add a bool option to
'qemuProcessSPICEAllocatePorts' function to switch between true and fake
allocation so we can use this function also in qemu_driver to generate
native domain definition.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Since adding the support for scheduler policy settings in commit
8680ea97, there are two enums with the same information.  That was
caused by rewriting the patch since first draft.

Find out thanks to clang, but there was no impact whatsoever.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The problem here was that when opening a channel, we were checking
whether the channel given is alias (can't be NULL for running domain) or
it's name, which can be NULL (for example with spicevmc).  In case of
such domain qemuDomainOpenChannel() made the daemon crash.
STREQ_NULLABLE() is safe to use since the code in question is wrapped in
"if (name)" and is more readable, so use that instead of checking for
non-NULL "vm->def->channels[i]->target.name".
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

This patch resolves a situation where the same "<target dev='$name'...>"
can be used for multiple disks in the domain.

While the $name is "mostly" advisory regarding the expected order that
the disk is added to the domain and not guaranteed to map to the device
name in the guest OS, it still should be unique enough such that other
domblk* type operations can be performed.

Without the patch, the domblklist will list the same Target twice:

$ virsh domblklist $dom
Target     Source
------------------------------------------------
sda        /var/lib/libvirt/images/file.qcow2
sda        /var/lib/libvirt/images/file.img

Additionally, getting domblkstat, domblkerror, domblkinfo, and other block*
type calls will not be able to reference the second target.

Fortunately, hotplug disallows adding a "third" sda value:

$ qemu-img create -f raw /var/lib/libvirt/images/file2.img 10M
$ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sda
error: Failed to attach disk
error: operation failed: target sda already exists

$

BUT, it since 'sdb' doesn't exist one would get the following on the same
hotplug attempt, but changing to use 'sdb' instead of 'sda'

$ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sdb
error: Failed to attach disk
error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-1' for device

$

Since we cannot fix this issue at parsing time, the best that can be done so
as to not "lose" a domain is to make the check prior to starting the guest
with the results as follows:

$ virsh start $dom
error: Failed to start domain $dom
error: XML error: target 'sda' duplicated for disk sources '/var/lib/libvirt/images/file.qcow2' and '/var/lib/libvirt/images/file.img'

$

Running 'make check' found a few more instances in the tests where this
duplicated target dev value was being used. These also exhibited some
duplicated 'id=' values (negating the uniqueness argument of aliases) in
the corresponding .args file and of course the *xmlout version of a few
input XML files.

NUMA enabled guest configuration explicitly specifies memory sizes for
individual nodes. Allowing the virDomainSetMemoryFlags API (and friends)
to change the total doesn't make sense as the individual node configs
are not updated in that case.

Forbid use of the API in case NUMA is specified.

If the domain is not running, the agent will not respond.
Do not even try.

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

Not just the DomainObj's private data.

This way checks requiring the job can be done in qemuDomainAgentAvailable.

Filter out non-migratable features if
VIR_CONNECT_BASELINE_CPU_MIGRATABLE was specified.

Instead of tracking the number of added parameters,
add a comma at the end of each one unconditionally
and trim the trailing one at the end.

If we combine the boot order on the command line with other
boot options, we prepend order= in front of it.

Instead of checking if the number of added arguments is between
0 and 2, separate the strings for boot order and options
and prepend boot order only if both strings are not empty.

This option is xenner-only (since commit b81a7ece),
and we dropped support for xenner in commit de9be0ab.

It was only supported by xenner (since commit 763a59d8),
for which we removed support in commit de9be0ab.

Remove the code generating this command line option,
refuse to parse it and delete the outdated tests.

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

Commit cf2d4c60 used a logical or instead of bitwise or,
effectively passing 1, that is VIR_DOMAIN_XML_INACTIVE.

This was caught by a warning when building with clang.

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

Commit f7afeddc added code to report to systemd an array of interface
indexes for all tap devices used by a guest. Unfortunately it not only
didn't add code to report the ifindexes for macvtap interfaces
(interface type='direct') or the tap devices used by type='ethernet',
it ended up sending "-1" as the ifindex for each macvtap or hostdev
interface. This resulted in a failure to start any domain that had a
macvtap or hostdev interface (or actually any type other than
"network" or "bridge").

This patch does the following with the nicindexes array:

1) Modify qemuBuildInterfaceCommandLine() to only fill in the
nicindexes array if given a non-NULL pointer to an array (and modifies
the test jig calls to the function to send NULL). This is because
there are tests in the test suite that have type='ethernet' and still
have an ifname specified, but that device of course doesn't actually
exist on the test system, so attempts to call virNetDevGetIndex() will
fail.

2) Even then, only add an entry to the nicindexes array for
appropriate types, and to do so for all appropriate types ("network",
"bridge", and "direct"), but only if the ifname is known (since that
is required to call virNetDevGetIndex().

libvirt was unconditionally calling virNetDevBandwidthClear() for
every interface (and network bridge) of a type that supported
bandwidth, whether it actually had anything set or not. This doesn't
hurt anything (unless ifname == NULL!), but is wasteful.

This patch makes sure that all calls to virNetDevBandwidthClear() are
qualified by checking that the interface really had some bandwidth
setup done, and checks for a null ifname inside
virNetDevBandwidthClear(), silently returning success if it is null
(as well as removing the ATTRIBUTE_NONNULL from that function's
prototype, since we can't guarantee that it is never null,
e.g. sometimes a type='ethernet' interface has no ifname as it is
provided on the fly by qemu).

Signed-off-by: NJán Tomko <jtomko@redhat.com>

If the qemu binary on x86 does not support lsi SCSI controller,
but it supports virtio-scsi, we reject the virtio-specific attributes
for no reason.

Move the default controller assignment before the check.

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

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

Soo. you've successfully started yourself a domain. And since you want
to use it on your host exclusively you are confident enough to
passthrough the host CPU model, like this:

  <cpu mode='host-passthrough'/>

Then, after a while, you want to save the domain into a file (e.g.
virsh save dom dom.save). And here comes the trouble. The file consist
of two parts: Libvirt header (containing domain XML among other
things), and qemu migration data. Now, the domain XML in the header is
formatted using special flags (VIR_DOMAIN_XML_SECURE |
VIR_DOMAIN_XML_UPDATE_CPU | VIR_DOMAIN_XML_INACTIVE |
VIR_DOMAIN_XML_MIGRATABLE).

Then, on your way back from the bar, you think of changing something
in the XML in the saved file (we have a command for it after all), say
listen address for graphics console. So you successfully type in the
command:

  virsh save-image-edit dom.save

Change all the bits, and exit the editor. But instead of success
you're left with sad error message:

  error: unsupported configuration: Target CPU model <null> does not
  match source Pentium Pro

Sigh. Digging into the code you see lines, where we check for ABI
stability. The new XML you've produced is compared with the old one
from the saved file to see if qemu ABI will break or not. Wait, what?
We are using different flags to parse the XML you've provided so we
were just lucky it worked in some cases? Yep, that's right.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In commit cc41c648 I've re-factored qemuMonitorFindBalloonObjectPath, but
missed that there is a memory leak. The "nextpath" variable is
overwritten while looping in for cycle and we have to free it before next
cycle.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Making use of the ARCH_IS_S390 macro introduced with
e8083575Signed-off-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>