Let's fix this before we bake in a painful API.  Since we know
that we have exactly one non-negative fd on success, we might
as well return the fd directly instead of forcing the user to
pass in a pointer.  Furthermore, I found some memory and fd
leaks while reviewing the code - the idea is that on success,
libvirtd will have handed two fds in two different directions:
one to qemu, and one to the RPC client.

* include/libvirt/libvirt.h.in (virDomainOpenGraphicsFD): Drop
unneeded parameter.
* src/driver.h (virDrvDomainOpenGraphicsFD): Likewise.
* src/libvirt.c (virDomainOpenGraphicsFD): Adjust interface to
return fd directly.
* daemon/remote.c (remoteDispatchDomainOpenGraphicsFd): Adjust
semantics.
* src/qemu/qemu_driver.c (qemuDomainOpenGraphicsFD): Likewise,
and plug fd leak.
* src/remote/remote_driver.c (remoteDomainOpenGraphicsFD):
Likewise, and plug memory and fd leak.
Signed-off-by: NEric Blake <eblake@redhat.com>

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=999926

According to docs/schemas/domaincommon.rng and _virDomainBlockIoTuneInfo
all the iotune values are interpreted as unsigned long long, however
according to qemu_monitor_json.c, qemu silently truncates numbers
larger than LLONG_MAX. There's really not much of a usage for such
large numbers anyway yet. This patch provides the same overflow
check during a domain start as it does during setting
a blkdeviotune element in qemu_driver.c and thus reports an error when
a larger number than LLONG_MAX is detected.

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

QEMU 2.1 added support for the kvm=off option to the -cpu command,
allowing the KVM hypervisor signature to be hidden from the guest.
This enables disabling of some paravirualization features in the
guest as well as allowing certain drivers which test for the
hypervisor to load.  Domain XML syntax is as follows:

<domain type='kvm>
  ...
  <features>
    ...
    <kvm>
      <hidden state='on'/>
    </kvm>
  </features>
  ...
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1021703Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit b606bbb4 reminded me that any time we drop locks to run
back-to-back guest interaction commands, we have to check that
the guest didn't disappear in between the two commands.  A quick
audit found a couple of spots that were missing this check.

* src/qemu/qemu_driver.c (qemuDomainShutdownFlags)
(qemuDomainSetVcpusFlags): Check that domain is still up.
Signed-off-by: NEric Blake <eblake@redhat.com>

The 'min_guarantee' is used by VMware ESX and OpenVZ drivers,
with qemu however, libvirt should report error when starting a domain,
because this element is not used.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1122455

On some places in the libvirt code we have:

  f(a,z)

instead of

  f(a, z)

This trivial patch fixes couple of such occurrences.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Using 'virsh attach-device --config' (or --persistent) to attach a
file backed lun device will succeed; however, subsequent domain restarts
will result in failure because the configuration of a file backed lun
is not supported.

Although allowing 'illegal configurations' is something that can be
allowed, it may not be practical in this case. Generally, when attaching
a device to a domain means the domain must be running. A way around
this is using the --config (or --persistent) option. When an attach
is done to a running domain, a temporary configuration is modified
first followed by the live update. The live update will make a number
of disk validity checks when building the qemu command to attach the
disk. If any fail, then change is rejected.

Rather than allow a potentially illegal combination, adjust the code
in the configuration path to make the same checks as the running path
will make with respect to disk validity checks. This way we avoid
having the potential for some subsequent start/reboot to fail because
an illegal combination was allowed.

NB: The live path still checks the configuration since it is possible
to just do --live guest modification...

And add a syntax-check for '){$'.  It's not perfect, but better than
nothing.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

An advice appeared there on the qemu-devel list [1]. When a domain is
suspended and then resumed guest kernel is not aware of this. So we've
introduced virDomainSetTime API that resets the time within guest
using qemu-ga. On the other hand, qemu itself is trying to make RTC
beat faster to catch the difference. But if we don't tell qemu that
guest's time was reset via the other method, both mechanisms are
applied resulting in again wrong guest time. In order to avoid summing
both corrections we need to tell qemu that it should not use the RTC
injection if the guest time is set via guest agent.

1: http://www.mail-archive.com/qemu-devel@nongnu.org/msg236435.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1131306Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The build failure is caused by a false positive of some static analysys
steps done by gcc (that don't happen on -O0).

When a user would try changing the persistent IO tuning settings for a
disk that was hotplugged to a vm in a transient way, the
qemuDomainSetBlockIoTune API would use the same index for both the
live and config disk array. The disk was missing from the config array
though causing a crash of libvirtd.

To fix the issue, determine the indexes separately.

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

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

When starting up the domain the domain's NICs are allocated. As of
1f24f682 (v1.0.6) we are able to use multiqueue feature on virtio
NICs. It breaks network processing into multiple queues which can be
processed in parallel by different host CPUs. The queues are, however,
created by opening /dev/net/tun several times. Unfortunately, only the
first FD in the row is labelled so when turning the multiqueue feature
on in the guest, qemu will get AVC denial. Make sure we label all the
FDs needed.

Moreover, the default label of /dev/net/tun doesn't allow
attaching a queue:

    type=AVC msg=audit(1399622478.790:893): avc:  denied  { attach_queue }
    for  pid=7585 comm="qemu-kvm"
    scontext=system_u:system_r:svirt_t:s0:c638,c877
    tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023
    tclass=tun_socket

And as suggested by SELinux maintainers, the tun FD should be labeled
as svirt_t. Therefore, we don't need to adjust any range (as done
previously by Guannan in ae368ebf) rather set the seclabel of the
domain directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of tediously copying of the disk source to remove it later
ensure that the media change function removes the old device after it
succeeds.

Both addition and removal of a shared hostdev share the code to generate
the hostdev key. Split it out into a separate function and refactor
them.

Removing a shared device needs special steps for disks and hostdevs.
Instead of having one function dealing this split the code into two
separate functions that can be used with better granularity.

Adding a shared device needs special steps for disks and hostdevs.
Instead of having one function dealing this split the code into two
separate functions that can be used with better granularity.

The qemuCheckSharedDevice function is operating only on disk devices.
Rename it and change the arguments to reflect that and refactor some
logic for more readability.

Split it out into a separate function and simplify the code. There's no
need to copy the entry to update it as the hash returns pointer to the
existing item.

Also remove the now unused qemuSharedDeviceEntryCopy function.

To allow reuse split the code into a separate function and refactor it.
To update an existing entry there's no need to copy it first, just
update it inplace.

Use the qemu source string formatter to format the source string
correctly for remote and other storage instead of passing source->path
blindly.

Pass the source of the changed media instead of a complete disk
definition.

Note that the @disk argument now contains what @olddisk would contain.
The new source is passed as a virStorageSource struct.

When we are changing media (or doing other hotplug operations) we need
to setup cgroups, locking and seclabels on the new disk. This is a
multi-step process where every piece can fail. To simplify dealing with
this introduce qemuDomainPrepareDisk that similarly to
qemuDomainPrepareDiskChainElement initializes/tears down  a whole new
disk to be used with the domain.

Additionally the function supports passing a different source struct for
media changes of cdroms that will be refactored later.

Avoid the "audit" label to simplify control flow.

All checks are based on the storage source, thus there's no need to pass
the complete disk def.

Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Currently, qemu driver uses qemuTranslateDiskSourcePool()
to translate disk volume information. This function is
general enough and could be used for other drivers as well,
so move it to conf/domain_conf.c along with its helpers.

 - qemuTranslateDiskSourcePool: move to storage/storage_driver.c
   and rename to virStorageTranslateDiskSourcePool,
 - qemuAddISCSIPoolSourceHost: move to storage/storage_driver.c
   and rename to virStorageAddISCSIPoolSourceHost,
 - qemuTranslateDiskSourcePoolAuth: move to storage/storage_driver.c
   and rename to virStorageTranslateDiskSourcePoolAuth,
 - Update users of qemuTranslateDiskSourcePool to use a
   new name.

In commit 45ad1adb I added a nicer message for tunings that need
cgroups when unavailable (unprivileged), but I added this check for
I/O tuning of block devices, which doesn't need cgroups, because it is
done by QEMU, so let's fix that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Pin existing vcpus rather than existing vcpu pinning infos. This
increases the complexity of the lookup, but avoids pinning cpus that are
not enabled actually.

Remove the pinning info when removing to CPU, otherwise when the VM will
be started our code will try to pin non-existing vcpus as the definition
wasn't updated.

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

We set just one affinity of the emulator and the virConnectPtr isn't
needed for that function.

When editing guest's XML (on QEMU), it was possible to add multiple
listen elements into graphics parent element. However QEMU does not
support listening on multiple addresses. Configuration is tested for
multiple 'listen address' and if positive, an error is raised.

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

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

During a QEMU live migration several warning messages about job
handling could be written to syslog on the destination host:

"entering monitor without asking for a nested job is dangerous"

The messages are written because the job handling during migration
uses hard coded asyncJob values in several places that are incorrect.

This patch passes the required asyncJob value around and prevents
the warnings as well as any issues that the warnings may be referring
to.

https://bugzilla.redhat.com/show_bug.cgi?id=1130089Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

At the beginning of the qemu config file parsing function there
are 3 helper macros defined: GET_VALUE_BOOL, GET_VALUE_LONG and
GET_VALUE_STR. Later, when they are no longer needed they are
undefined in order to keep the namespace clean. However, the
GET_VALUE_STRING is undefined instead of GET_VALUE_STR.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Implement ZFS storage backend driver. Currently supported
only on FreeBSD because of ZFS limitations on Linux.

Features supported:

 - pool-start, pool-stop
 - pool-info
 - vol-list
 - vol-create / vol-delete

Pool definition looks like that:

 <pool type='zfs'>
  <name>myzfspool</name>
  <source>
    <name>actualpoolname</name>
  </source>
 </pool>

The 'actualpoolname' value is a name of the pool on the system,
such as shown by 'zpool list' command. Target makes no sense
here because volumes path is always /dev/zvol/$poolname/$volname.

User has to create a pool on his own, this driver doesn't
support pool creation currently.

A volume could be used with Qemu by adding an entry like this:

    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <source pool='myzfspool' volume='vol5'/>
      <target dev='hdc' bus='ide'/>
    </disk>