Signed-off-by: NLi Yang <liyang.fnst@cn.fujitsu.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...

The error message contains one extra dash.

Since vbox driver rewrite the virDriver structure init moved from
vbox_tmpl.c into vbox_common.c. However, our hvsupport.pl script
doesn't count with that. It still parses vbox_tmp.c and looks for
virDriver structure which is not found there anymore. As a result,
at hvsupport page is seems like vbox driver doesn't support
anything.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In case the host has 2 or more NUMA nodes, we fetch CPU map for each
node. However, we need to free the CPU map in between loops:

==29513== 96 (72 direct, 24 indirect) bytes in 3 blocks are definitely lost in loss record 951 of 1,264
==29513==    at 0x4C2A700: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29513==    by 0x52AD24B: virAlloc (viralloc.c:144)
==29513==    by 0x52AF0E6: virBitmapNew (virbitmap.c:78)
==29513==    by 0x52FB720: virNumaGetNodeCPUs (virnuma.c:294)
==29513==    by 0x53C700B: nodeCapsInitNUMA (nodeinfo.c:1886)
==29513==    by 0x11759708: vboxCapsInit (vbox_common.c:398)
==29513==    by 0x11759CC4: vboxConnectOpen (vbox_common.c:514)
==29513==    by 0x53C965F: do_open (libvirt.c:1147)
==29513==    by 0x53C9EBC: virConnectOpen (libvirt.c:1317)
==29513==    by 0x142905: remoteDispatchConnectOpen (remote.c:1215)
==29513==    by 0x126ADF: remoteDispatchConnectOpenHelper (remote_dispatch.h:2346)
==29513==    by 0x5453D21: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The "maxMemory" element was never supported by libvirt. Remove it from
the test XMLs. (Found while actually trying to add support for a
identically named element).

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>

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>

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

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

Update bhyveBuildDiskArgStr to support volumes:

 - Make virBhyveProcessBuildBhyveCmd and
   virBhyveProcessBuildLoadCmd take virConnectPtr as the
   first argument instead of bhyveConnPtr as virConnectPtr is
   needed for virStorageTranslateDiskSourcePool,
 - Add virStorageTranslateDiskSourcePool call to
   virBhyveProcessBuildBhyveCmd and
   virBhyveProcessBuildLoadCmd,
 - Allow disks of type VIR_STORAGE_TYPE_VOLUME

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.

net-undefine doesn't only undefine an inactive network,
but also an active network(persistent), it just cannot
undefine a transient network.
Signed-off-by: NLi Yang <liyang.fnst@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The prototype was along with domain API prototypes instead of network
API ones.

  * tools/virsh.pod (migrate): Add --auto-converge flag
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

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>

Added attribute dscp to below supported protocols table in nwfilter docs.
IPV4 (ip)
TCP/UDP/SCTP (tcp/udp/sctp)
ICMP (icmp)
IGMP,ESP,AH,UDPLITE,'ALL' (igmp,esp,ah,udplite,all)
TCP/UDP/SCTP over IPV6 (tcp-ipv6,udp-ipv6,sctp-ipv6)
ICMPV6 (icmpv6)
IGMP,ESP,AH,UDPLITE,'ALL' over IPv6 (igmp-ipv6,esp-ipv6,ah-ipv6,udplite-ipv6,all-ipv6)

Here is a simple example:
[root@localhost ~]# virsh nwfilter-dumpxml myself
<filter name='myself' chain='root'>
  <uuid>7192ef51-cd50-4f14-ad7b-fa5c69ea19e3</uuid>
  <rule action='accept' direction='in' priority='500'>
    <ip dscp='1'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <tcp dscp='1'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <tcp-ipv6 dscp='2'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <icmp dscp='55'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <icmpv6 dscp='55'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <udp dscp='3'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <udp-ipv6 dscp='4'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <udplite dscp='5'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <udplite-ipv6 dscp='6'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <esp dscp='7'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <esp-ipv6 dscp='8'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <ah dscp='9'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <ah-ipv6 dscp='10'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <sctp dscp='11'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <sctp-ipv6 dscp='55'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <igmp dscp='55'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <all-ipv6 dscp='55'/>
  </rule>
  <rule action='accept' direction='in' priority='500'>
    <all dscp='55'/>
  </rule>
</filter>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

A possible fix to issue:
http://www.redhat.com/archives/libvir-list/2014-August/thread.html#00227

While doing migration on KVM host, found problem sometimes:
VM is already running on the target host and disappears from source
host, but 'virsh migrate' command line hangs, cannot exit normally.
If pressing "ENTER" key, it will exit.

The code hangs at tools/virsh-domain.c: cmdMigrate
->vshWatchJob->poll():
poll() is trying to select pipe_fd, which is used to receive message
from doMigrate thread. In debugging, found that doMigrate finishes
and at the end it does call safewrite() to write the retval ('0' or
'1') to pipe_fd, and the write is completed. But cmdMigrate poll()
cannot get the event. If pressing "ENTER" key, poll() can get the
event and select pipe_fd, then command line can exit.

In current code, authentication thread which is called by vshConnect
will use stdin, and at the same time, in cmdMigrate main process,
poll() is listening to stdin, that probably affect poll() to get
pipe_fd event. Better to move authentication before vshWatchJob. With
this change, above problem does not exist.
Signed-off-by: NChunyan Liu <cyliu@suse.com>

XM and XL config are very similar.  Disks are specified differently
in XL, but the old XM disk config is still supported by XL.  XL also
supports new config like spice that was never supported by XM.

This patch moves all the common parsing and formatting functions to
the new file xen_common.c and adapts the XM parser/formatter accordingly.
This restructuring paves way for introducing an XL parser/formatter in
the future.

While moving the code, fixup whitespace, comments, and style issues.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Wrap formatting code common to xm and xl in xenFormatConfigCommon
and export it.
Signed-off-by: NKiarie Kahurani <davidkiarie4@gmail.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Wrap parsing code common to xm and xl in xenParseConfigCommon
and export it.
Signed-off-by: NKiarie Kahurani <davidkiarie4@gmail.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>