Lets not give a bad example and check for return values of
virNetwork* APIs called within the test. Even though it's
unlikely that any API will fail, it can happen. We're connected
to the test driver after all, and our API sequence is correct. So
test driver should fail only in case of bug or OOM.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to lock the network driver, as network driver
initialization is done prior accepting any client. There's nobody
to hop in and do something over partially initialized driver. Nor
qemu driver is doing that.

==30532== Observed (incorrect) order is: acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x5396440: virNetworkObjListForEach (network_conf.c:4511)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B27B60: networkGetDnsmasqCaps (bridge_driver.c:113)
==30532==    by 0x19B2856A: networkUpdateState (bridge_driver.c:389)
==30532==    by 0x53963E9: virNetworkObjListForEachHelper (network_conf.c:4488)
==30532==    by 0x52E2224: virHashForEach (virhash.c:521)
==30532==    by 0x539645B: virNetworkObjListForEach (network_conf.c:4512)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==
==30532== Required order was established by acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B28DF9: networkStateInitialize (bridge_driver.c:609)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x538A09C: virNetworkAssignDef (network_conf.c:527)
==30532==    by 0x5391EB2: virNetworkLoadState (network_conf.c:3008)
==30532==    by 0x53922D4: virNetworkLoadAllState (network_conf.c:3128)
==30532==    by 0x19B2929A: networkStateInitialize (bridge_driver.c:671)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Wikipedia's list of common misspellings [1] has a machine-readable
version.  This patch fixes those misspellings mentioned in the list
which don't have multiple right variants (as e.g. "accension", which can
be both "accession" and "ascension"), such misspellings are left
untouched.  The list of changes was manually re-checked for false
positives.

[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

We've never set the cpuset.memory_migrate value to anything, keeping it
on default.  However, we allow changing cpuset.mems on live domain.
That setting, however, don't have any consequence on a domain unless
it's going to allocate new memory.

I managed to make 'virsh numatune' move all the memory to any node I
wanted even without disabling libnuma's numa_set_membind(), so this
should be safe to use with it as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1198497Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Deepak Shetty has changed preferred email address since prior
contributions.
Signed-off-by: NEric Blake <eblake@redhat.com>

xen.git commit babeca32 added a pkgconfig file for libxenlight,
allowing libxl apps to determine the location of Xen binaries
such as firmware blobs, device emulator, etc.

This patch adds support for xenlight.pc in the libxl driver, falling
back to the previous configure logic if not found.  It introduces
LIBXL_FIRMWARE_DIR and LIBXL_EXECBIN_DIR to define the firmware and
libexec_bin locations.  If xenlight.pc does not exist, the defines
are set to the current hardcoded paths.  The capabilities'
<emulator> and <loader> elements are updated to use the paths.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

If, by any reason, parallelsNetworkOpen fails it dereferences
newly allocated privconn->networks via virObjectUnref, which in
turn deallocates its memory.
Subsequent call of parallelsNetworkClose calls virObjectUnref
that leads to double memory free. To prevent this we should zero
privconn->networks to make all subsequent virObjectUnref be safe.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

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

When qemu exits during startup, libvirt includes the error from
/var/log/libvirt/qemu/vm.log in the error message:

$ virsh start test3
error: Failed to start domain test3
error: internal error: early end of file from monitor: possible problem:
2015-02-27T03:03:16.985494Z qemu-kvm: -numa memdev is not supported by
machine rhel6.5.0

The check for domain liveness added to qemuDomainObjExitMonitor
in commit dc2fd51f sometimes overwrites this error:
$ virsh start test3
error: Failed to start domain test3
error: operation failed: domain is no longer running

Fix the check to only report an error if there is none set.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

When converting domXML from native, the libxl driver was overwriting
useful errors from the xenconfig parsing code with a useless, generic
error.  E.g. "internal error: parsing xm config failed" vs
"internal error: config value usbdevice was malformed".  Remove the
redundant (and useless) error reporting in the libxl driver.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Issue #1 - A call to virBitmapNew did not check if the allocation
failed which could lead to a NULL dereference

Issue #2 - When deleting the pin entries from the config file, the
code loops from the number of elements down to the "new" vcpu count;
however, the pin id values are numbered 0..n-1 not 1..n, so the "first"
pin attempt would never work. Luckily the check was for whether the
incoming 'n' (vcpu id) matched the entry in the array from 0..arraysize
rather than a dereference of the 'n' entry

I spent quite some time figuring that backingStore info
isn't included in the dom xml, unless guest is up and
running. Hopefully putting that in the doc should help.

Also, several people have complained that libvirt reports
a backing file as raw, even though they expected it to be
qcow2; where the culprit is usually the user forgetting to
create the file with qemu-img create -o backing_fmt=qcow2.

This patch adds that info to the doc.
Signed-off-by: NDeepak C Shetty <deepakcs@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

In qemu 2.3, the migration status will include 'cancelling' in the
window between when an asynchronous cancel has been requested and
when the migration is actually halted.  Previously, qemu hid this
state and reported 'active'.  Libvirt manages the sequence okay
even when the string is unrecognized (that is, it will report an
unknown state:

Migration: [ 69 %]^Cerror: internal error: unexpected migration status in cancelling.

but the migration is still cancelled), but recognizing the string
makes for a smoother user experience.

* src/qemu/qemu_monitor.h
(QEMU_MONITOR_MIGRATION_STATUS_CANCELLING): Add enum.
* src/qemu/qemu_monitor.c (qemuMonitorMigrationStatus): Map it.
* src/qemu/qemu_migration.c (qemuMigrationUpdateJobStatus): Adjust
clients.
* src/qemu/qemu_monitor_json.c
(qemuMonitorJSONGetMigrationStatusReply): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Investigation of a problem with creating passthrough macvtap devices
(https://bugzilla.redhat.com/show_bug.cgi?id=1185501) has shown that
this slightly more verbose failure message is useful. In particular,
the mac address can be used to determine the domain. You could also
figure this out by looking at preceding messages in a debug log, but
this gets it in a single place.

virnetdevopenvswitch.h declares a few functions that can be called to
add ports to and remove them from OVS bridges, and retrieve the
migration data for a port. It does not contain any data definitions
that are used by domain_conf.h. But for some reason, domain_conf.h
virnetdevopenvswitch.h should be directly #including it. This adds a
few lines to the project, but saves all the files that don't need it
from the extra computing, and makes the dependencies more clear cut.

Problem Description:
When we set boot order for a vhost-user network interface, we found the boot index
doesn't work.

Cause of the Problem:
In the function qemuBuildVhostuserCommandLine(), it forcely set the arg bootindex of
function qemuBuildNicDevStr() to 0. Thus, the bootindex parameter got missing.

Solution:
Trans the arg bootindex down.
Signed-off-by: NGao Haifeng <gaohaifeng.gao@huawei.com>
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>

network adapter is used

which is on by default when a new VM/CT is created.
We should do this because this feature can't be controlled
by libvirt now and it sets up some iptables rules. So it's
better to do this to avoid potential conflict of different
set of rules or to avoid unexpected behavior.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

and set adapter model specified in xml
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

when a new network adapter device is added
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

In order to support 'bridge' network adapters in parallels
driver we need to plug our veth devices into corresponding
linux bridges.
We are going to do this by reusing our abstraction of
Virtual Networks in terms of PCS. On a domain creation, we
create a new Virtual Network naming it with the same name
as a source bridge for each network  interface.
Having done this, we plug PCS veth interfaces created with names of
target dev into specified bridges using our standard PCS procedures
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Don't fail initialization of parallels driver if
parallelsLoadNetwork fails for optional networks.
This can happen when some of them are added manually
and configured incompletely. PCS requires only two networks
created automatically (named Host-Only and Bridged), others
are optional and their incompleteness can be ignored.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

My commit 2dbfa716 added test data for vircgrouptest but forgot to
distribute the new directory.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The following is a long winded way to say this patch is avoiding a
false positive.

Coverity complains that calling networkPlugBandwidth() could eventually
end up with a NULL dereference on iface->bandwidth because in the
networkAllocateActualDevice there's a check of 'iface->bandwidth'
before deciding to try to use the 'portgroup' if it exists or to not
perferm the virNetDevBandwidthCopy if 'bandwidth' is not NULL.

Later in networkPlugBandwidth the 'iface->bandwidth' is sourced from
virDomainNetGetActualBandwidth - which would be either iface->bandwidth
or (preferably) iface->data.network.actual->bandwidth which would have
been filled in from either 'iface->bandwidth' or 'portgroup->bandwidth'
back in networkAllocateActualDevice

There *is* a check in networkCheckBandwidth for the result of the
virDomainNetGetActualBandwidth being NULL and a return 1 based on
that which would cause networkPlugBandwidth to exit properly and thus
never hit the condition that Coverity complains about.

However, since Coverity checks all paths - it somehow believes that
a return of 0 by networkCheckBandwidth in this condition would end
up causing the possible NULL dereference. The "fix" to silence Coverity
is to not have networkCheckBandwidth also call virDomainNetGetActualBandwidth
in order to get the ifaceBand, but rather have it accept it as an argument
which causes Coverity to "see" that it's the exit condition of 1 that won't
have the possible NULL dereference.  Since we're passing that, I added the
passing of iface->mac rather than passing iface as well. This just hopefully
makes sure someone doesn't undo this in the future...

When libvirt is starting a domain, it reports the state as SHUTOFF until
it's RUNNING. This is not ideal because domain startup may take a long
time (usually because of some configuration issues, firewalls blocking
access to network disks, etc.) and domain lists provided by libvirt look
awkward. One can see weird shutoff domains with IDs in a list of active
domains or even shutoff transient domains. In any case, it looks more
like a bug in libvirt than a normal state a domain goes through.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function needs a pointer to the network to get list of DHCP
leases. The pointer is obtained via virNetworkLookupByName() which
requires callers to free the returned network once no longer needed.
Otherwise it's leaked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The variable holds formatted suffix to each line printed out
(address type, address and prefix). However, the variable is
never freed. At the same time, honour fact, that data held in
the variable is not constant.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we allow HW address to be not present on our RPC layer,
don't error out if qemu-ga hasn't provided any.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Make sure we don't print (null) (which in fact is printf()'s
cleverness anyway, not ours). If no HW address is present, print
"N/A" string just like we do for other fields.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not all NICs (esp. the virtual ones like TUN) must have a hardware
address. Teach our RPC that it's possible.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1199182 documents that
after a series of disk snapshots into existing destination images,
followed by active commits of the top image, it is possible for
qemu 2.2 and earlier to end up tracking a different name for the
image than what it would have had when opening the chain afresh.
That is, when starting with the chain 'a <- b <- c', the name
associated with 'b' is how it was spelled in the metadata of 'c',
but when starting with 'a', taking two snapshots into 'a <- b <- c',
then committing 'c' back into 'b', the name associated with 'b' is
now the name used when taking the first snapshot.

Sadly, older qemu doesn't know how to treat different spellings of
the same filename as identical files (it uses strcmp() instead of
checking for the same inode), which means libvirt's attempt to
commit an image using solely the names learned from qcow2 metadata
fails with a cryptic:

error: internal error: unable to execute QEMU command 'block-commit': Top image file /tmp/images/c/../b/b not found

even though the file exists.  Trying to teach libvirt the rules on
which name qemu will expect is not worth the effort (besides, we'd
have to remember it across libvirtd restarts, and track whether a
file was opened via metadata or via snapshot creation for a given
qemu process); it is easier to just always directly ask qemu what
string it expects to see in the first place.

As a safety valve, we validate that any name returned by qemu
still maps to the same local file as we have tracked it, so that
a compromised qemu cannot accidentally cause us to act on an
incorrect file.

* src/qemu/qemu_monitor.h (qemuMonitorDiskNameLookup): New
prototype.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONDiskNameLookup):
Likewise.
* src/qemu/qemu_monitor.c (qemuMonitorDiskNameLookup): New function.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskNameLookup)
(qemuMonitorJSONDiskNameLookupOne): Likewise.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit)
(qemuDomainBlockJobImpl): Use it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use the utilities introduced in the previous patches so the qemu
driver is able to create tap devices that are bound (and unbound
on domain destroyal) to Midonet virtual ports.
Signed-off-by: NAntoni Segura Puimedon <toni+libvirt@midokura.com>

Midonet is an opensource virtual networking that over lays the IP
network between hypervisors. Currently, such networks can be made
with the openvswitch virtualport type.

This patch, defines the schema and documentation that will serve
as basis for the follow up patches that will add support to libvirt
for using Midonet virtual ports for its interfaces. The schema
definition requires that the port profile expresses its interfaceid
as part of the port profile. For that reason, this is part of the
patch too.
Signed-off-by: NAntoni Segura Puimedon <toni+libvirt@midokura.com>

Adds the port type definitions and methods that will be used to bind
interfaces to the Midonet virtual ports.

virtnetdevmidonet.c adds the way to bind and unbind the ports by
calling into the Midonet Host Agent control command line (installed
with the midolman package).
Signed-off-by: NAntoni Segura Puimedon <toni+libvirt@midokura.com>

Previously we had to check for 3 fields to see if the source was filled.
Repurpose one of the variables as a boolean flag and use it instead of
combining multiple sources.

For the condition that checks that only CDROM/FLOPPY drives can be empty
we can use the virStorageSourceIsEmpty() helper.

If the storage device type is parsed as network our parser still allows
it to omit the <source> element. The empty drive check would not trigger
on such device as it expects that every network storage source is valid.

Use VIR_STORAGE_NET_PROTOCOL_NONE as a marker that the storage source is
empty.

Only selected fields from the disk source were copied when cold updating
source in a CDROM drive. When such drive was backed by a network file
this resulted into corruption of the definition:

    <disk type='network' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source protocol='gluster' name='gluster-vol1(null)'>
        <host name='localhost'/>
      </source>
      <target dev='vdc' bus='virtio'/>
      <readonly/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>

Update the whole source instead of cherry-picking elements.

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