Currently the virNetServerDispatchNewClient both creates the
virNetServerClientPtr instance and registers it with the
virNetServerPtr internal state. Split the client registration
code out into a separate virNetServerAddClient method to
allow future reuse from other contexts
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

For network devices allocated from a network with <forward
mode='hostdev'>, there is a need to add the newly minted hostdev to
the hostdevs array.

In this case we also need to call qemuPrepareHostDevices just for this
one device, as the standard call to initialize all the hostdevs that
were defined directly in the domain's configuration has already been
made by the time we allocate a device from a libvirt network, and thus
have something that needs initializing.
Signed-off-by: NShradha Shah <sshah@solarflare.com>

This patch updates the network driver to properly utilize the new
attributes/elements that are now in virNetworkDef
Signed-off-by: NShradha Shah <sshah@solarflare.com>
Signed-off-by: NLaine Stump <laine@laine.org>

This function is needed by the network driver in a later commit.
It is useful in functions like networkNotifyActualDevice and
networkReleaseActualDevice

The network pool should be able to keep track of both network device
names and PCI addresses, and return the appropriate one in the
actualDevice when networkAllocateActualDevice is called.
Signed-off-by: NShradha Shah <sshah@solarflare.com>

This patch introduces the new forward mode='hostdev' along with
attribute managed. Includes updates to the network RNG and new xml
parser/formatter code.
Signed-off-by: NShradha Shah <sshah@solarflare.com>

Existing code that creates a list of forwardIfs from a single PF
was moved to the new utility function networkCreateInterfacePool.
No functional change.
Signed-off-by: NShradha Shah <sshah@solarflare.com>

Move the functions the parse/format, and validate PCI addresses to
their own file so they can be conveniently used in other places
besides device_conf.c

Refactoring existing code without causing any functional changes to
prepare for new code.

This patch makes the code reusable.
Signed-off-by: NShradha Shah <sshah@solarflare.com>

Change device type of a virtio channel from/to spicevmc is not a user
visible change. However, spicevmc channels use different default target
name than other virtio channels. To maintain ABI stability during this
change target name must be explicitly specified (and equal) in both
configurations.

Add the ability to support VLAN tags for Open vSwitch virtual port
types. To accomplish this, modify virNetDevOpenvswitchAddPort and
virNetDevTapCreateInBridgePort to take a virNetDevVlanPtr
argument. When adding the port to the OVS bridge, setup either a
single VLAN or a trunk port based on the configuration from the
virNetDevVlanPtr.
Signed-off-by: NKyle Mestery <kmestery@cisco.com>

Setting hard_limit larger than previous swap_hard_limit must fail,
it's not that good if one wants to change the swap_hard_limit
and hard_limit together. E.g.

% virsh memtune rhel6
hard_limit     : 1000000
soft_limit     : 1000000
swap_hard_limit: 1000000

% virsh memtune rhel6 --hard-limit 1000020 --soft-limit 1000020 \
--swap-hard-limit 1000020 --live

This patch reorder the limits setting to set the swap_hard_limit
first, hard_limit then, and soft_limit last if it's greater than
current swap_hard_limit. And soft_limit first, hard_limit then,
swap_hard_limit last, if not.

'make distcheck' fails because the generated ESX and HyperV files
are (intentionally) marked read-only, but since the stamp file was
missing, make assumes they need to be rebuilt.  Shipping the stamp
file solves the problem.

* src/Makefile.am (EXTRA_DIST): Ship stamp files.

The underlying function to set the vlan tag of an SR-IOV network
device was already in place (although an extra patch to save/restore
the original vlan tag was needed), and recent patches added the
ability to configure a vlan tag. This patch just ties those two
together.

An SR-IOV device doesn't support vlan trunking, so if anyone tries to
configure more than a single tag, or set the trunk flag, and error is
logged.

When a network device that is a VF of an SR-IOV card was assigned to a
guest using <interface type='hostdev'>, only the MAC address was being
saved/restored, but the VLAN tag was left untouched. Up to now we
haven't actually used vlan tags on SR-IOV devices, so the guest would
have used whatever was set, and left it the same at the end.

The patch following this one will hook up the <vlan> element from the
interface config, so save/restore of the device state needs to also
include the vlan tag.

MAC address is being saved as a simple ASCII string in a file named
for the device under /var/run.  The VLAN tag is now just added at the
end of that file, after a newline. It might be nicer if the file was
XML (in case it ever gets more complicated) but at the moment there's
nothing else on the horizon, and this makes backward compatibility
easier.

The parameter value for cpuset could be in special format like
"0-10,^7", which is not recognized by cgroup. This patch is to
ensure the cpuset is formatted as expected before passing it to
cgroup. As a side effect, after the patch, it parses the cpuset
early before cgroup setting, to avoid the rollback if cpuset
parsing fails afterwards.

Previous commit:

  commit 9093ab77
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Jul 18 17:03:17 2012 +0100

    Add lots of internal symbols to libvirt_private.syms

mistakenly put some conditional SASL symbols in libvirt_private.syms
instead of libvirt_sasl.syms

The network driver now looks for the vlan element in network and
portgroup objects, and logs an error at network define time if a vlan
is requested for a network type that doesn't support it. (Currently
vlan configuration is only supported for openvswitch networks, and
networks used to do hostdev assignment of SR-IOV VFs.)

At runtime, the three potential sources of vlan information are
examined in this order: interface, chosen portgroup, network, and the
first that is non-empty is used.  Another check for valid network type
is made at this time, since the interface may have requested a vlan (a
legal thing to have in the interface config, since it's not known
until runtime if the chosen network will actually support it).

Since we must also check for domains requesting vlans for unsupported
connection types even if they are type='network', and since
networkAllocateActualDevice() is being called in exactly the correct
places, and has all of the necessary information to check, I slightly
modified the logic of that function so that interfaces that aren't
type='network' don't just return immediately. Instead, they also
perform all the same validation for supported features. Because of
this, it's not necessary to make this identical check in the other
three places that would normally require it: 1) qemu domain startup,
2) qemu device hotplug, 3) lxc domain startup.

This can be seen as a first step in consolidating network-related
functionality into the network driver, rather than having copies of
the same code spread around in multiple places; this will make it
easier to split the network parts off into a separate daemon, as we've
discussed recently.

The following config elements now support a <vlan> subelements:

within a domain: <interface>, and the <actual> subelement of <interface>
within a network: the toplevel, as well as any <portgroup>

Each vlan element must have one or more <tag id='n'/> subelements.  If
there is more than one tag, it is assumed that vlan trunking is being
requested. If trunking is required with only a single tag, the
attribute "trunk='yes'" should be added to the toplevel <vlan>
element.

Some examples:

  <interface type='hostdev'/>
    <vlan>
      <tag id='42'/>
    </vlan>
    <mac address='52:54:00:12:34:56'/>
    ...
  </interface>

  <network>
    <name>vlan-net</name>
    <vlan trunk='yes'>
      <tag id='30'/>
    </vlan>
    <virtualport type='openvswitch'/>
  </network>

  <interface type='network'/>
    <source network='vlan-net'/>
    ...
  </interface>

  <network>
    <name>trunk-vlan</name>
    <vlan>
      <tag id='42'/>
      <tag id='43'/>
    </vlan>
    ...
  </network>

  <network>
    <name>multi</name>
    ...
    <portgroup name='production'/>
      <vlan>
        <tag id='42'/>
      </vlan>
    </portgroup>
    <portgroup name='test'/>
      <vlan>
        <tag id='666'/>
      </vlan>
    </portgroup>
  </network>

  <interface type='network'/>
    <source network='multi' portgroup='test'/>
    ...
  </interface>

IMPORTANT NOTE: As of this patch there is no backend support for the
vlan element for *any* network device type. When support is added in
later patches, it will only be for those select network types that
support setting up a vlan on the host side, without the guest's
involvement. (For example, it will be possible to configure a vlan for
a guest connected to an openvswitch bridge, but it won't be possible
to do that for one that is connected to a standard Linux host bridge.)

To allow for the possibility of vlan "trunks", which have more than
one vlan tag associated with them, we need a vlan struct. Since it
will be used by multiple files in src/util, src/conf, src/network, and
src/qemu, it must be defined in src/util. Unfortunately there isn't
currently a common file for simple netdev data definitions, so I
created a new file.

This caused compilation of virnetdevvportprofile.c to fail on systems
without IFLA support in netlink (these are netlink commands used to
configure the VF's of SR-IOV network devices).

Fix build on platforms lacking YAJL library by adding missing
'bool pretty' parameter to virJSONValueToString.

Currently there is a hook function that is invoked when a
new client connection comes in, which allows an app to
setup private data. This setup will make it difficult to
serialize client state during process re-exec(). Change to
a model where the app registers a callback when creating
the virNetServerPtr instance, which is used to allocate
the client private data immediately during virNetClientPtr
construction.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the virNetClientPtr constructor will always register
the async IO event handler and the keepalive objects. In the
case of the lock manager, there will be no event loop available
nor keepalive support required. Split this setup out of the
constructor and into separate methods.

The remote driver will enable async IO and keepalives, while
the LXC driver will only enable async IO
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the virNetServerServicePtr is responsible for
creating the virNetServerClientPtr instance when accepting
a new connection. Change this so that the virNetServerServicePtr
merely gives virNetServerPtr a virNetSocketPtr instance. The
virNetServerPtr can then create the virNetServerClientPtr
as it desires
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

It is desirable to be able to query the config params of
the thread pool, in order to save the server state. Add
virThreadPoolGetMinWorkers, virThreadPoolGetMaxWorkers
and virThreadPoolGetPriorityWorkers APIs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

While the QEMU monitor/agent do not want JSON strings pretty
printed, other parts of libvirt might. Instead of hardcoding
QEMU's desired behaviour in virJSONValueToString(), add a
boolean flag to control pretty printing
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

To allow a virLockManagerPtr to be created directly from a
driver table struct, replace the virLockManagerPluginPtr parameter
with a virLockDriverPtr parameter.

* src/locking/domain_lock.c, src/locking/lock_manager.c,
  src/locking/lock_manager.h: Replace plugin param with
  a driver in virLockManagerNew
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemuProcessAutoDestroyRun function was removed in an earlier
commit, but the header file declaration was not deleted

Do some cleanup of parallelsOpen, STREQ_NULLABLE can replace
a lot of checks.

Also fix error message to be VIR_ERR_INTERNAL_ERROR, the same
as in other drivers.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Let's change URI to parallels:///system. Parallels Server supports
creating VMs from non-privileged accounts, but it's not main usage
scenario and it may be forbidden in the future.

Also containers, which will be supported by the driver, can be managed
only by root, so /system path is more suitable for this driver.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Each interface has a single pointer to a filterref object. That
filterref can itself point to multiple other filterrefs, but at the
toplevel there is only one.

The parser had previously just silently overwritten earlier filterrefs
when a new one was encountered, so the interface was left with
whichever was the last filterref in the xml, ignoring all the
others. This patch logs an error when it sees more than one filterref.

Just as each physical device used by a network has a connections
counter, now each network has a connections counter which is
incremented once for each guest interface that connects using this
network.

The count is output in the live network XML, like this:

   <network connections='20'>
   ...
   </network>

It is read-only, and for informational purposes only - it isn't used
internally anywhere by libvirt.

A later patch will be adding a counter that will be
incremented/decremented each time an guest interface starts/stops
using a particular network. For this to work, all types of networks
need to go through a common return sequence rather than returning
early. To setup for this, a new success: label is added (when
necessary), a new error: label is added which does any cleanup
necessary only for error returns and then does goto cleanup, and early
returns are changed to goto error if it's a failure, or goto success
if it's successful. This way the intent of all the gotos is
unambiguous, and a successful return path never encounters the
"error:" label.

It may be useful for management applications to know which physical
network devices are in use by guests. This information is already
available in the network objects, but wasn't output in the XML. This
patch outputs it when the INACTIVE flag isn't set (and if it's non-0).

I want to include this count in the xml output of networks, but
calling it "connections" in the XML sounds better than "usageCount", and it
would be better if the name in the XML matched the variable name.

In a few places, usageCount was being initialized to 0, but this is
unnecessary, because VIR_ALLOC_N zero-fills everything anyway.

This array was originally defined using the existing
virNetworkForwardIfDef, but that struct has a UsageCount field that
isn't used in the case of PFs. This patch just copies that struct and
removes UsageCount. It ends up being a struct with a single field, but
I left it as a struct in case we need to add other fields to it in the
future.

Use of ldexp() requires -lm on some platforms; use gnulib to determine
this for our makefile.  Also, optimize virRandomInt() for the case
of a power-of-two limit (actually rather common, given that Daniel
has a pending patch to replace virRandomBits(10) with code that will
default to virRandomInt(1024) on default SELinux settings).

* .gnulib: Update to latest, for ldexp.
* bootstrap.conf (gnulib_modules): Import ldexp.
* src/Makefile.am (libvirt_util_la_CFLAGS): Link with -lm when
needed.
* src/util/virrandom.c (virRandomInt): Optimize powers of 2.

One of the original ideas behind allowing a <virtualport> in an
interface definition as well as in the <network> definition *and*one
or more <portgroup>s within the network, was that guest-specific
parameteres (like instanceid and interfaceid) could be given in the
interface's virtualport, and more general things (portid, managerid,
etc) could be given in the network and/or portgroup, with all the bits
brought together at guest startup time and combined into a single
virtualport to be used by the guest. This was somehow overlooked in
the implementation, though - it simply picks the "most specific"
virtualport, and uses the entire thing, with no attempt to merge in
details from the others.

This patch uses virNetDevVPortProfileMerge3() to combine the three
possible virtualports into one, then uses
virNetDevVPortProfileCheck*() to verify that the resulting virtualport
type is appropriate for the type of network, and that all the required
attributes for that type are present.

An example of usage is this: assuming a <network> definitions on host
ABC of:

  <network>
    <name>testA</name>
    ...
    <virtualport type='openvswitch'/>
    ...
    <portgroup name='engineering'>
      <virtualport>
        <parameters profileid='eng'/>
      </virtualport>
    </portgroup>
    <portgroup name='sales'>
      <virtualport>
        <parameters profileid='sales'/>
      </virtualport>
    </portgroup>
  </network>

and the same <network> on host DEF of:

  <network>
    <name>testA</name>
    ...
    <virtualport type='802.1Qbg'>
      <parameters typeid="1193047" typeidversion="2"/>
    </virtualport>
    ...
    <portgroup name='engineering'>
      <virtualport>
        <parameters managerid="11"/>
      </virtualport>
    </portgroup>
    <portgroup name='sales'>
      <virtualport>
        <parameters managerid="55"/>
      </virtualport>
    </portgroup>
  </network>

and a guest <interface> definition of:

  <interface type='network'>
    <source network='testA' portgroup='sales'/>
    <virtualport>
      <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                  interfaceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"\>
    </virtualport>
    ...
  </interface>

If the guest was started on host ABC, the <virtualport> used would be:

  <virtualport type='openvswitch'>
    <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'
                profileid='sales'/>
  </virtualport>

but if that guest was started on host DEF, the <virtualport> would be:

    <virtualport type='802.1Qbg'>
      <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                  typeid="1193047" typeidversion="2"
                  managerid="55"/>
    </virtualport>

Additionally, if none of the involved <virtualport>s had a specified type
(this includes cases where no virtualport is given at all),

Until now, all attributes in a <virtualport> parameter list that were
acceptable for a particular type, were also required. There were no
optional attributes.

One of the aims of supporting <virtualport> in libvirt's virtual
networks and portgroups is to allow specifying the group-wide
parameters in the network's virtualport, and merge that with the
interface's virtualport, which will have the instance-specific info
(i.e. the interfaceid or instanceid).

Additionally, the guest's interface XML shouldn't need to know what
type of network connection will be used prior to runtime - it could be
openvswitch, 802.1Qbh, 802.1Qbg, or none of the above - but should
still be able to specify instance-specific info just in case it turns
out to be applicable.

Finally, up to now, the parser for virtualport has always generated a
random instanceid/interfaceid when appropriate, making it impossible
to leave it blank (which is what's required for virtualports within a
network/portprofile definition).

This patch modifies the parser and formatter of the <virtualport>
element in the following ways:

* because most of the attributes in a virNetDevVPortProfile are fixed
  size binary data with no reserved values, there is no way to embed a
  "this value wasn't specified" sentinel into the existing data. To
  solve this problem, the new *_specified fields in the
  virNetDevVPortProfile object that were added in a previous patch of
  this series are now set when the corresponding attribute is present
  during the parse.

* allow parsing/formatting a <virtualport> that has no type set. In
  this case, all fields are settable, but all are also optional.

* add a GENERATE_MISSING_DEFAULTS flag to the parser - if this flag is
  set and an instanceid/interfaceid is expected but not provided, a
  random one will be generated. This was previously the default
  behavior, but is now done only for virtualports inside an
  <interface> definition, not for those in <network> or <portgroup>.

* add a REQUIRE_ALL_ATTRIBUTES flag to the parser - if this flag is
  set the parser will call the new
  virNetDevVPortProfileCheckComplete() functions at the end of the
  parser to check for any missing attributes (based on type), and
  return failure if anything is missing. This used to be default
  behavior. Now it is only used for the virtualport defined inside an
  interface's <actual> element (by the time you've figured out the
  contents of <actual>, you should have all the necessary data to fill
  in the entire virtualport)

* add a REQUIRE_TYPE flag to the parser - if this flag is set, the
  parser will return an error if the virtualport has no type
  attribute. This also was previously the default behavior, but isn't
  needed in the case of the virtualport for a type='network' interface
  (i.e. the exact type isn't yet known), or the virtualport of a
  portgroup (i.e. the portgroup just has modifiers for the network's
  virtualport, which *does* require a type) - in those cases, the
  check will be done at domain startup, once the final virtualport is
  assembled (this is handled in the next patch).