In the table built for traffic coming from the VM going to the host make the following changes:

- don't ACCEPT the packets but do a 'RETURN' and let the host-specific firewall rules in subsequent rules evaluate whether the traffic is allowed to enter

- use the '-m state' in the rules as everywhere else

* .x-sc_po_check: Exclude docs directory.

Add src/util/files.c to libvirt_proxy_SOURCES.

ESX(i) uses UTF-8, but a Windows based GSX server writes
Windows-1252 encoded VMX files.

Add a test case to ensure that libxml2 provides Windows-1252
to UTF-8 conversion.

Since bugs due to double-closed file descriptors are difficult to track down in a multi-threaded system, I am introducing the VIR_CLOSE(fd) macro to help avoid mistakes here.

There are lots of places where close() is being used. In this patch I am only cleaning up usage of close() in src/conf where the problems were.

I also dare to declare close() as being deprecated in libvirt code base (HACKING).

Over root-squashing nfs, when virFileOperation() is called as uid==0,
it may fail with EACCES, but also with EPERM, due to
virFileOperationNoFork()'s failed attemp to chown a writable file.

qemudDomainSaveFlag() should expect this case, too.

qemudOpenAsUID is intended to open a file with the credentials of a
specified uid. Current implementation fails if the file is accessible to
one of uid's groups but not owned by uid.

This patch replaces the supplementary group list that the child process
inherited from libvirtd with the default group list of uid.

* tools/virsh.c: Add new memory tunable "min_guarantee", currently only
  ESX can use this
* tools/virsh.pod: Update the manpage

* 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.