* docs/formatdomain.html.in: Add memtune element details, added min_guarantee
* src/libvirt.c: Update virDomainGetMemoryParameters api description, make
  it more clear that the user first needs to call the api to get the number
  of parameters supported and then call again to get the values.
* tools/virsh.pod: Add usage of new command memtune in virsh manpage

Vdsm needs to communicate with its guest agent via unix domain socket,
which qemu creates due to the following domain xml device:

    <channel type='unix'>
      <target type='virtio' name='com.redhat.rhevm.vdsm'/>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/fcp-xp-1.com.redhat.rhevm.vdsm'/>
    </channel>

The location of the socket below /var/lib/libvirt/qemu/channels makes
sense, to humans and selinux policy alike. However, that socket should
be accessible to vdsm, too.

Due to other (storage) reasons, vdsm is to join the "qemu" group. With
this patch, vdsm can look below /var/lib/libvirt/qemu and connect to the
socket.

The socket itself should be chmod'ed to allow qemu group read/write, but
that's for another project.

BZ#643407

* .gnulib: Update to latest.

* tests/virshtest.c (mymain): Add tests of command parsing and
echo command.

* tools/virsh.c (cmdEcho): New command.
(commands): Add it.
* tools/virsh.pod (echo): Document it.

* tools/virsh.c (vshCmdOptType): Add VSH_OT_ARGV.  Delete
unused VSH_OT_NONE.
(vshCmddefGetData): Special case new opt flag.
(vshCmddefHelp): Display help for argv.
(vshCommandOptArgv): New function.

https://bugzilla.redhat.com/show_bug.cgi?id=623903 documents a qemu
bug that causes libvirt to hang if virt-manager happens to be
querying balloon info when a guest is paused.  Until the qemu bug
is fixed, people need to know how to avoid the issue.

* docs/formatdomain.html.in (Memory balloon device): Mention
model='none'.

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

* libvirt.spec.in: Provide xenapi conditionals.

VMware uses a mix of percent-, pipe- and base64-encoding in
different combinations in different places.

Add a testcase for this.

Patch to prevent multiple nwfilters with different name but same UUID.

* AUTHORS: List Harsh Prateek Bora, for 'make syntax-check'.

* .gnulib: Undo change in previous commit.

This introduces new attribute to filesystem element
to support customizable access mode for mount type.
Valid accessmode are: passthrough, mapped and squash.

Usage:
        <filesystem type='mount' accessmode='passthrough'>
          <source dir='/export/to/guest'/>
          <target dir='mount_tag'/>
        </filesystem>

passthrough is the default model if not specified, that's
also the current behaviour.

The following filter transition from a filter allowing incoming TCP connections

  <rule action='accept' direction='in' priority='401'>
    <tcp/>
  </rule>
  <rule action='accept' direction='out' priority='500'>
    <tcp/>
  </rule>

to one that does not allow them

  <rule action='drop' direction='in' priority='401'>
    <tcp/>
  </rule>
  <rule action='accept' direction='out' priority='500'>
    <tcp/>
  </rule>

did previously not cut off existing (ssh) connections but only prevented newly initiated ones. The attached patch allows to cut off existing connections as well, thus enforcing what the filter is showing.

I had only tested with a configuration where the physical interface is connected to the bridge where the filters are applied. This patch now also solves a filtering problem where the physical interface is not connected to the bridge, but the bridge is given an IP address and the host routes between bridge and physical interface. Here the filters drop non-allowed traffic on the outgoing side on the host.

* configure.ac (AC_INIT): Provide email and URL.

* .gnulib: Update to latest, for termios fix.
* configure.ac (AC_CHECK_HEADERS): Drop redundent check.
* bootstrap: Synchronize from upstream.
Reported by Daniel P. Berrange.

Explicitly raising a nice error in the case user tries to migrate a
guest with assigned host devices is much better than waiting for a
mysterious error with no clue for the reason.

When only some host CPUs given to cpuBaseline contain <vendor> element,
baseline CPU should not contain it. Otherwise the result would not be
compatible with the host CPUs without vendor. CPU vendors are still
taken into account when computing baseline CPU, it's just removed from
the result.

Recent CPU models were specified using invalid vendor element
<vendor>NAME</vendor>, which was silently ignored due to a bug in the
code which was parsing it.

 This patch silences the nwfilter test case.

Failure introduced in commit 3a092f38.

* tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr: Fix typo.

'make -C src rpcgen' is supposed to be idempotent.  But commit
f928f43b mistakently manually edited a generated file rather
than fixing the upstream file.

* src/remote/remote_protocol.x (remote_memory_param_value): Use
correct spelling of enum values.
* src/remote/remote_protocol.c: Regenerate.

This enables support for nested SVM using the regular CPU
model/features block. If the CPU model or features include
'svm', then the '-enable-nesting' flag will be added to the
QEMU command line. Latest out of tree patches for nested
'vmx', no longer require the '-enable-nesting' flag. They
instead just look at the cpu features. Several of the models
already include svm support, but QEMU was just masking out
the svm bit silently. So this will enable SVM on such
models

* src/qemu/qemu_conf.h: flag for -enable-nesting
* src/qemu/qemu_conf.c: Use -enable-nesting if VMX or SVM are in
  the CPUID
* src/cpu/cpu.h, src/cpu/cpu.c: API to check for a named feature
* src/cpu/cpu_x86.c: x86 impl of feature check
* src/libvirt_private.syms: Add cpuHasFeature
* src/qemuhelptest.c: Add nesting flag where required

Before running each test case clear the thread local error
indicator. After running each test case, dispatch any error
that was reported

* tests/testutils.c: Fix error reporting in test suites

The TODO list changes frequently so cannot be well maintained
under GIT. Update the TODO file to point people at bugzilla
and the libvirt website

* TODO: Point at bugzilla/website

* src/xen/sexpr.c: Ensure () are escaped in sexpr2string
* tests/sexpr2xmldata/sexpr2xml-boot-grub.sexpr,
  tests/sexpr2xmldata/sexpr2xml-boot-grub.xml,
  tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr,
  tests/xml2sexprdata/xml2sexpr-boot-grub.xml: Data files to
  check escaping
* tests/sexpr2xmltest.c, tests/xml2sexprtest.c: Add boot-grub
  escaping test case

 This is from a bug report and conversation on IRC where Soren reported that while a filter update is occurring on one or more VMs (due to a rule having been edited for example), a deadlock can occur when a VM referencing a filter is started.

The problem is caused by the two locking sequences of

qemu driver, qemu domain, filter             # for the VM start operation
filter, qemu_driver, qemu_domain            # for the filter update operation

that obviously don't lock in the same order. The problem is the 2nd lock sequence. Here the qemu_driver lock is being grabbed in qemu_driver:qemudVMFilterRebuild()

The following solution is based on the idea of trying to re-arrange the 2nd sequence of locks as follows:

qemu_driver, filter, qemu_driver, qemu_domain

and making the qemu driver recursively lockable so that a second lock can occur, this would then lead to the following net-locking sequence

qemu_driver, filter, qemu_domain

where the 2nd qemu_driver lock has been ( logically ) eliminated.

The 2nd part of the idea is that the sequence of locks (filter, qemu_domain) and (qemu_domain, filter) becomes interchangeable if all code paths where filter AND qemu_domain are locked have a preceding qemu_domain lock that basically blocks their concurrent execution

So, the following code paths exist towards qemu_driver:qemudVMFilterRebuild where we now want to put a qemu_driver lock in front of the filter lock.

-> nwfilterUndefine()   [ locks the filter ]
    -> virNWFilterTestUnassignDef()
        -> virNWFilterTriggerVMFilterRebuild()
            -> qemudVMFilterRebuild()

-> nwfilterDefine()
    -> virNWFilterPoolAssignDef() [ locks the filter ]
        -> virNWFilterTriggerVMFilterRebuild()
            -> qemudVMFilterRebuild()

-> nwfilterDriverReload()
    -> virNWFilterPoolLoadAllConfigs()
        ->virNWFilterPoolObjLoad()
            -> virNWFilterPoolAssignDef() [ locks the filter ]
                -> virNWFilterTriggerVMFilterRebuild()
                    -> qemudVMFilterRebuild()

-> nwfilterDriverStartup()
    -> virNWFilterPoolLoadAllConfigs()
        ->virNWFilterPoolObjLoad()
            -> virNWFilterPoolAssignDef() [ locks the filter ]
                -> virNWFilterTriggerVMFilterRebuild()
                    -> qemudVMFilterRebuild()

Qemu is not the only driver using the nwfilter driver, but also the UML driver calls into it. Therefore qemuVMFilterRebuild() can be exchanged with umlVMFilterRebuild() along with the driver lock of qemu_driver that can now be a uml_driver. Further, since UML and Qemu domains can be running on the same machine, the triggering of a rebuild of the filter can touch both types of drivers and their domains.

In the patch below I am now extending each nwfilter callback driver with functions for locking and unlocking the (VM) driver (UML, QEMU) and introduce new functions for locking all registered callback drivers and unlocking them. Then I am distributing the lock-all-cbdrivers/unlock-all-cbdrivers call into the above call paths. The last shown callpath starting with nwfilterDriverStart() is problematic since it is initialize before the Qemu and UML drives are and thus a lock in the path would result in a NULL pointer attempted to be locked -- the call to virNWFilterTriggerVMFilterRebuild() is never called, so we never lock either the qemu_driver or the uml_driver in that path. Therefore, only the first 3 paths now receive calls to lock and unlock all callback drivers. Now that the locks are distributed where it matters I can remove the qemu_driver and uml_driver lock from qemudVMFilterRebuild() and umlVMFilterRebuild() and not requiring the recursive locks.

For now I want to put this out as an RFC patch. I have tested it by 'stretching' the critical section after the define/undefine functions each lock the filter so I can (easily) concurrently execute another VM operation (suspend,start). That code is in this patch and if you want you can de-activate it. It seems to work ok and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking filter and qemu_domain always has a preceding qemu_driver lock.

* tools/virsh.c: Update comments to match patch series.

* tools/virsh.c (vshCommandParse): Float up, to avoid the need for
a forward declaration.

This makes 'virsh --conn test:///default help help' work right;
previously, the abbreviation confused our hand-rolled option parsing.

* tools/virsh.c (vshParseArgv): Use getopt_long feature, rather
than (incorrectly) reparsing options ourselves.

"--" means no option at the following arguments.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

Some users may type command like this at the virsh shell:
virsh # somecmd 'some arg'

because they often use single quote in linux shell.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

add escaper \ for command string parsing, example:

virsh # cd /path/which/have/a/double\"quote
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

* tools/virsh.pod: Document top-level options.

Old virsh command parsing mashes all the args back into a string and
miss the quotes, this patches fix it. It is also needed for introducing
qemu-monitor-command which is very useful.

This patches uses the new vshCommandParser abstraction and adds
vshCommandArgvParse() for arguments vector, so we don't need
to mash arguments vector into a command sting.

And the usage was changed:
old:
virsh [options] [commands]

new:
virsh [options]... [<command_string>]
virsh [options]... <command> [args...]

So we still support commands like:
"define D.xml; dumpxml D" was parsed as a commands-string.

and support commands like:
we will not mash them into a string, we use new argv parser for it.

But we don't support the command like:
"define D.xml; dumpxml" was parsed as a command-name, but we have no such command-name.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>