Modeled after the qemuDomainHostdevPrivatePtr (commit id '27726d8c'),
create a privateData pointer in the _virDomainChardevDef to allow storage
of private data for a hypervisor in order to at least temporarily store
secret data for usage during qemuBuildCommandLine.

NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the secret data, there's no need to add code
code to handle this new structure there.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The first argument should be const char ** instead of
char **, because this is a search function and as such it
doesn't, and shouldn't, alter the haystack in any way.

This change means we no longer have to cast arrays of
immutable strings to arrays of mutable strings; we still
have to do the opposite, though, but that's reasonable.

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Allow to store driver specific data on a per-vcpu basis.

Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.

All the same information was already there, just in slightly different
places in the virDomainNetDef.

a.k.a. <hostdev mode='capabilities' type='net'>.

This replaces the existing nips, ips, nroutes, and routes with a
single virNetDevIPInfo, and simplifies the code by calling that
object's parse/format/clear functions instead of open coding.

These functions all need to be called from a utility function that
must be located in the util directory, so we move them all into
util/virnetdevip.[ch] now that it exists.

Function and struct names were appropriately changed for the new
location, but all code is unchanged aside from motion and renaming.

I'm tired of mistyping this all the time, so let's do it the same all
the time (similar to how we changed all "Pci" to "PCI" awhile back).

(NB: I've left alone some things in the esx and vbox drivers because
I'm unable to compile them and they weren't obviously *not* a part of
some API. I also didn't change a couple of variables named,
e.g. "somethingIptables", because they were derived from the name of
the "iptables" command)

Most the callers pass 0 in one form or another, including
vircapstest which used VIR_ARCH_NONE.

cgroup functions set and get the longer type so use it everywhere

This is identical to type='bridge', but without the "connect to a
bridge" part, so it can be handled by using the same functions (and
often even the same cases in switch statements), after renaming
virLXCProcessSetupInterfaceBridged() to virLXCProcessInterfaceTap()
and enhancing it to skip bridge-related items when brname == NULL.

To be truly useful, we need to support setting the ip address on the
host side veth as well as guest side veth (already supported for
type='bridge'), as well as setting the peer address for both.

The <script> element (supported by type='ethernet' in qemu) isn't
supported in this patch. An error is logged at domain start time if it
is encountered. This may be changed in a later patch.

Modeled after the qemuDomainDiskPrivatePtr logic, create a privateData
pointer in the _virDomainHostdevDef to allow storage of private data
for a hypervisor in order to at least temporarily store auth/secrets
data for usage during qemuBuildCommandLine.

NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the auth/secret data, there's no need to add
code to handle this new structure there.

Updated copyrights for modules touched. Some didn't have updates in a
couple years even though changes have been made.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The virStringListLength function does not ever modify the passed
string list. It merely counts the items in it. Make sure that we
reflect this bit in the function header.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

(crobinso: fix up spacing and squash in sheepdog bit suggested
 by Andrea)

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

This change ensures to call driver specific post-parse code to modify
domain definition after parsing hypervisor config the same way we do
after parsing XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The name of the variable was misleading. Rename it and it's setting
accessor before other fixes.

Although defined the same way, fortunately there hadn't been any deviation.
Ensure any assignments to onCrash use VIR_DOMAIN_LIFECYCLE_CRASH_* defs and
not VIR_DOMAIN_LIFECYCLE_* defs

Upping an interface for no reason and not configuring it is a cardinal sin.

With the default addrgenmode if eui64 it sticks a link-local address to the
interface. That is not good, as NetworkManager would see an address configured,
assume the interface is already configured and won't touch it iself and the
interface might stay unconfigured until the end of the days.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1124721Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As there are two possible approaches to define a domain's memory size -
one used with legacy, non-NUMA VMs configured in the <memory> element
and per-node based approach on NUMA machines - the user needs to make
sure that both are specified correctly in the NUMA case.

To avoid this burden on the user I'd like to replace the NUMA case with
automatic totaling of the memory size. To achieve this I need to replace
direct access to the virDomainMemtune's 'max_balloon' field with
two separate getters depending on the desired size.

The two sizes are needed as:
1) Startup memory size doesn't include memory modules in some
hypervisors.
2) After startup these count as the usable memory size.

Note that the comments for the functions are future aware and document
state that will be present after a few later patches.

There was a mess in the way how we store unlimited value for memory
limits and how we handled values provided by user.  Internally there
were two possible ways how to store unlimited value: as 0 value or as
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED.  Because we chose to store memory
limits as unsigned long long, we cannot use -1 to represent unlimited.
It's much easier for us to say that everything greater than
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED means unlimited and leave 0 as valid
value despite that it makes no sense to set limit to 0.

Remove unnecessary function virCompareLimitUlong.  The update of test
is to prevent the 0 to be miss-used as unlimited in future.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1146539Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

As virDomainNumatuneSet now doesn't allocate the virDomainNuma object
any longer it's not necessary to pass the pointer to a pointer to store
the object as it will not change any longer.

While touching the parameter definitions I've also changed the name of
the parameter to "numa".

Use the virDomainDefNew() helper to allocate the definition instead of
doing it via VIR_ALLOC.

The structure will gradually become the only place for NUMA related
config, thus rename it appropriately.

This patch adds back the virDomainDef typedef into domain_conf and
makes all the numatune_conf functions independent of any virDomainDef
definitions.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For the values "default", "on", "off"

Replaces
virDeviceAddressPCIMulti
virDomainFeatureState
virDomainIoEventFd
virDomainVirtioEventIdx
virDomainDiskCopyOnRead
virDomainMemDump
virDomainPCIRombarMode
virDomainGraphicsSpicePlaybackCompression

There were numerous places where numatune configuration (and thus
domain config as well) was changed in different ways.  On some
places this even resulted in persistent domain definition not to be
stable (it would change with daemon's restart).

In order to uniformly change how numatune config is dealt with, all
the internals are now accessible directly only in numatune_conf.c and
outside this file accessors must be used.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since there was already public virDomainNumatune*, I changed the
private virNumaTune to match the same, so all the uses are unified and
public API is kept:

s/vir\(Domain\)\?Numa[tT]une/virDomainNumatune/g

then shrunk long lines, and mainly functions, that were created after
that:

sed -i 's/virDomainNumatuneMemPlacementMode/virDomainNumatunePlacement/g'

And to cope with the enum name, I haad to change the constants as
well:

s/VIR_NUMA_TUNE_MEM_PLACEMENT_MODE/VIR_DOMAIN_NUMATUNE_PLACEMENT/g

Last thing I did was at least a little shortening of already long
name:

s/virDomainNumatuneDef/virDomainNumatune/g
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Currently, <cputune><shares>0</shares></cputune> is treated
as if it were not specified.

Treat is as a valid value if it was explicitly specified
and write it to the cgroups.

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>