Commit da665fbd introduced the following condition to virLXCProcessEnsureRootFS
and openvzReadFSConf:
if (!(<some_var> = virDomainFSDefNew()) < 0)
which broke the build on fedora with GCC 5.3.1: "logical not is only applied to
the left hand side of comparison".
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The commit da665fbd introduced virStorageSourcePtr inside the structure
_virDomainFSDef. This is causing an error when libvirt is being compiled.
make[3]: Entering directory `/media/julio/8d65c59c-6ade-4740-9cdc-38016a4cb8ae
/home/julio/Desktop/virt/libvirt/src'
CC security/virt_aa_helper-virt-aa-helper.o
security/virt-aa-helper.c: In function 'get_files':
security/virt-aa-helper.c:1087:13: error: passing argument 2 of 'vah_add_path'
from incompatible pointer type [-Werror]
if (vah_add_path(&buf, fs->src, "rw", true) != 0)
^
security/virt-aa-helper.c:732:1: note: expected 'const char *' but argument is
of type 'virStorageSourcePtr'
vah_add_path(virBufferPtr buf, const char *path, const char *perms, bool
recursive)
^
cc1: all warnings being treated as errors
Adding the attribute "path" from virStorageSourcePtr fixes this issue.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
vz supports only a subset of tcp and udp parameters.
1. tcp type supports only 'raw' protocol.
2. udp type supports only same parameters of 'host' and 'service'
for 'bind' and 'connect'.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
After domain is in the domains list let's keep it there. This
is approach taken by qemu driver and vz vzDomainMigrateFinish3Params too.
It quite reasonable, driver domain object is fully constructed and
can be discovered by client later.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
9c14a9ab introduced vzNewDomain function to enlist libvirt domain
object before actually creating vz sdk domain. Fix should fix
race on same vz sdk domain added event where libvirt domain object is
enlisted too. But later eb5e9c1e added locked checks for
adding livirtd domain object to list on vz sdk domain added event.
Thus now approach of 9c14a9ab is unnecessary complicated.
See we have otherwise unuseful prlsdkGetDomainIds function only
to create minimal domain definition to create libvirt domain object.
Also vzNewDomain is difficult to use as it creates partially
constructed domain object.
Let's move back to original approach where prlsdkLoadDomain do
all the necessary job. Another benefit is that we can now
take driver lock for bare minimum and in single place. Reducing
locking time have small disadvatage of double parsing on race
conditions which is typical if domain is added thru vz driver.
Well we have this double parse inevitably with current vz sdk api
on any domain updates so i would not take it here seriously.
Performance events subscribtion is done before locked check and
therefore could be done twice on races but this is not the problem.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Vz containers are able to use ploop volumes from storage pools
to work upon.
To use filesystem type volume, pool name and volume name should be
specifaed in <source> :
<filesystem type='volume' accessmode='passthrough'>
<driver type='ploop' format='ploop'/>
<source pool='guest_images' volume='TEST_POOL_CT'/>
<target dir='/'/>
</filesystem>
The information about pool and volume is stored in ct dom configuration:
<StorageURL>libvirt://localhost/pool_name/vol_name</StorageURL>
and can be easily obtained via PrlVmDevHd_GetStorageURL sdk call.
The only shorcoming: if storage pool is moved somewhere the ct
should be redefined in order to refresh the information aboot path
to root.hdd
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
We do not need to check domainf fs type there,
because it is done in prlsdkCheckUnsupportedParams.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
New type of <devices> <filesystem type= 'volume'> is introduced.
This patch allows to use volumes for storing the filesystem, that is
accessed from the guest e.g. root directory for container.
To take advantage of volumes as a backend of filesystem volume
and pool names should be specified:
<filesystem type= 'volume'>
<source pool='pool name' volume='volume name'/>
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Adding domain to domain list on preparation step is not correct.
First domain is not fully constructed - domain definition is
missing. Second we can't use VIR_MIGRATE_PARAM_DEST_XML parameter
to parse definition as vz sdk can patch it by itself. Let's add/remove
domain on finish step. This is for synchronization purpose only so domain
is present/absent on destination after migration completion. Actually
domain object will probably be created right after actual vz sdk
migration start by vz sdk domain defined event.
We can not and should not sync domain cache on error path in finish step
of migration. We can not as we really don't know what is the reason of
cancelling and we should not as user should not make assumptions on
state on error path. What we should do is cleaning up temporary migration
state that is induced on prepare step but we don't have one. Thus
cancellation should be noop.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
libvirt domain defined event is issued only on correspondent vz sdk
event. But in case event delivered before domain is added to
domain list we can mistakenly skip this event if prlsdkNewDomainByHandle
return NULL in case of domain is discovered in the list under
the driver lock. Let's return domain object in this case.
Now prlsdkNewDomainByHandle returns NULL only in case of
error which is more convinient.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
The first version of migration cookie was rather dumb resulting
in passing empty or unused fields here and there. Add flags to
specify what to bake to and eat from cookie so we deal only
with meaningful data. However for backwards compatibility
we still need to pass at least some faked fields sometimes.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Older libvirt versions send persistent XML in a migration cookie even
when VIR_MIGRATE_PERSIST_DEST flag is not used, but current libvirt
properly fails if the cookie contains unexpected flags. Thus migration
from old libvirt fails with
internal error: Unsupported migration cookie feature persistent
unless VIR_MIGRATE_PERSIST_DEST flag is set.
https://bugzilla.redhat.com/show_bug.cgi?id=1320500
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
A nodedev device definition like this is required for testing
NodeDeviceCreateXML and NodeDeviceDestroy. So unless it's part
of the stock test:///default set there's no way to actually
invoke those functions for the default URI
Convert the individual XML documents into one big XML document
in the format expected by the non-default test://$PATH URI, and
use the same internal helpers for assembling the driver contents.
virConfGetValueLLong() errors out if the value is too big to
fit into a long long integer, but claims the supported range
to be (0,LLONG_MAX) instead of (LLONG_MIN,LLONG_MAX).
When parsing numeric values, we always store them as unsigned
unless they're negative. We can use this fact to simplify the
logic by removing a bunch of unnecessary checks.
Commit 6381c89f8c changed virConfValue to store long long
integers instead of long integers; however, the temporary variable
used in virConfParseLong() was not updated accordingly, causing
trouble for 32-bit machines.
In preparation to tracking which USB addresses are occupied.
Introduce two helper functions for printing the port path
as a string and appending it to a virBuffer.
We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).
Only format the port if it has been specified and mark it as optional
in the XML schema.
Migration to an older libvirt (pre v1.3.0-175-g7140807) is broken
because older versions of libvirt generated different channel paths and
they didn't drop the default paths when parsing domain XMLs. We'd get
such a nice error message:
internal error: process exited while connecting to monitor:
2016-07-08T15:28:02.665706Z qemu-kvm: -chardev socket,
id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/
domain-3-nest/org.qemu.guest_agent.0,server,nowait: Failed to bind
socket to /var/lib/libvirt/qemu/channel/target/domain-3-nest/
org.qemu.guest_agent.0: No such file or directory
That said, we should not even format the default paths when generating a
migratable XML.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Playing directly with our live definition, updating it, and reverting it
back once we are done is very nice and it's quite dangerous too. Let's
just make a copy of the domain definition if needed and do all tricks on
the copy.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
If size_t is the same size as long long, then we can skip
some of the range checks. This avoids triggering some
bogus compiler warning messages.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virConf 'l' field is a 'signed long long', so whenever
the 'type' field is VIR_CONF_ULONG, we should explicitly cast
'l' to a 'unsigned long long' before doing range checks.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This function tries to get a ssize_t value from a config file.
But before returning it, it checks whether the value would fit in
ssize_t and if not an error is printed out among with the range
for the ssize_t type. However, on some platforms SSIZE_MAX may
actually be a signed long type:
util/virconf.c: In function 'virConfGetValueSSizeT':
util/virconf.c:1268:9: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=]
virReportError(VIR_ERR_INTERNAL_ERROR,
^
$ grep -r SSIZE_MAX /usr/include/
/usr/include/bits/posix1_lim.h:#ifndef SSIZE_MAX
/usr/include/bits/posix1_lim.h:# define SSIZE_MAX LONG_MAX
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
MinGW complained that we might be dereferencing a NULL pointer. While
that can't be true, the logic certainly allows for that.
../../src/conf/domain_conf.c: In function 'virDomainDefPostParse':
../../src/conf/domain_conf.c:4224:18: error: potential null pointer dereference [-Werror=null-dereference]
if (!vcpu->online && vcpu->cpumask) {
~~~~^~~~~~~~
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
MinGW complained that we might be dereferencing a NULL pointer. While
that can't be true, the logic certainly allows for that.
src/conf/domain_conf.c: In function 'virDomainDefGetVcpuPinInfoHelper':
src/conf/domain_conf.c:1545:17: error: potential null pointer dereference [-Werror=null-dereference]
if (vcpu->cpumask)
~~~~^~~~~~~~~
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
IPv6 RA always contains an implicit default route via
the link-local address of the source of RA. This forces
the guest to install a route via isolated network, which
may disturb the guest's networking in case of multiple interfaces.
More info in 013427e6e7.
The validity of this route is controlled by "default [route] lifetime"
field of RA. If the lifetime is set to 0 seconds, then no route
is installed by receiver.
dnsmasq 2.67+ supports "ra-param=<interface>,<RA interval>,<default
lifetime>" option. We pass "ra-param=*,0,0"
(here, RA_interval=0 means default) to disable default gateway in RA
for isolated networks.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1354238
So we spend some time and effort constructing perfect file name
for an automatic coredump of a domain, but then just leak it and
use the domain name anyway. This is probably due to a silly
mistake that slipped even through review.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
At least with systemd v210, NOTIFY_SOCKET is abstact, e.g.
@/org/freedesktop/systemd1/notify. sendmsg() fails on such a socket
with "Connection refused". The unix(7) man page contains the following
details wrt abstract socket addresses
abstract: an abstract socket address is distinguished (from a
pathname socket) by the fact that sun_path[0] is a null byte
('\0'). The socket's address in this namespace is given by the
additional bytes in sun_path that are covered by the specified
length of the address structure. (Null bytes in the name have
no special significance.)
So we need to be more precise about the address length, setting it to
the sizeof sa_family_t + length of address copied to sun_path instead
of setting it to the sizeof the entire sockaddr_un struct.
Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=987668
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
When fetching domains with virConnectListAllDomains() and when filtering
by snapshot existence is requested the ESX driver first lists all the
domains and then check one-by-one for snapshot existence. This process
takes unnecessarily long time.
To significantly improve the time necessary to finish the query we can
request the snapshot related info directly when querying the list of
domains from VMware.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
In an unlikely event of execve() failing, the virCommandExec()
function does not report any error, even though checks that are
at the beginning of the function are verbose when failing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The modification of .volWipe callback wipes ploop volume using one of
given wiping algorithm: dod, nnsa, etc.
However, in case of ploop volume we need to reinitialize root.hds and DiskDescriptor.xml.
v2:
- added check on ploop tools presens
- virCommandAddArgFormat changed to virCommandAddArg
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com>
Check whether QEMU supports -device intel-iommu
Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1235580
Currently many users of virConf APIs are defining the same
macros for calling virConfValue() and then doing type
checking. To remove this repeated code, add a set of
typesafe accessor methods.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If the config file does not end with a \n, the parser will append
one. When re-allocating the array though, it is mistakenly assuming
that 'len' is the length including the trailing NUL, but it does
not. So we must add 2 to len, when reallocating, not 1.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This one's a bit more complicated. In qemuProcessPrepareDomain()
a master key for encrypting secret for ciphered disks is created.
This object lives within qemuDomainObjPrivate object. It is freed
in qemuProcessStop(), but if nobody calls it (for instance like
our qemuxml2argvtest does), the key object leaks.
==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707
==17078== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==17078== by 0xAD924DF: virAllocN (viralloc.c:191)
==17078== by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166)
==17078== by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678)
==17078== by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913)
==17078== by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542)
==17078== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==17078== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==17078== by 0x446E7A: virTestRun (testutils.c:179)
==17078== by 0x445BD9: mymain (qemuxml2argvtest.c:2022)
==17078== by 0x44886F: virTestMain (testutils.c:969)
==17078== by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Just like every other qemuBuild*CommandLine() function, this uses
a buffer to hold partial cmd line strings too. However, if
there's an error, the control jumps to 'cleanup' label leaving
the buffer behind and thus leaking it.
==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711
==2013== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==2013== by 0x4C2C32F: realloc (vg_replace_malloc.c:692)
==2013== by 0xAD925A8: virReallocN (viralloc.c:245)
==2013== by 0xAD95EA8: virBufferGrow (virbuffer.c:130)
==2013== by 0xAD95F78: virBufferAdd (virbuffer.c:165)
==2013== by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339)
==2013== by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437)
==2013== by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174)
==2013== by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546)
==2013== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==2013== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==2013== by 0x446E7A: virTestRun (testutils.c:179)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When storage secret is parsed in virStorageEncryptionSecretParse(),
virSecretLookupParseSecret() which allocates some memory. This is
however never freed.
==21711== 134 bytes in 6 blocks are definitely lost in loss record 70 of 85
==21711== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==21711== by 0xBCA0356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==21711== by 0xA9F432E: virXMLPropString (virxml.c:479)
==21711== by 0xA9D25B0: virSecretLookupParseSecret (virsecret.c:70)
==21711== by 0xA9D616E: virStorageEncryptionSecretParse (virstorageencryption.c:172)
==21711== by 0xA9D66B2: virStorageEncryptionParseXML (virstorageencryption.c:281)
==21711== by 0xA9D68DF: virStorageEncryptionParseNode (virstorageencryption.c:338)
==21711== by 0xAA12575: virDomainDiskDefParseXML (domain_conf.c:7606)
==21711== by 0xAA2CAC6: virDomainDefParseXML (domain_conf.c:16658)
==21711== by 0xAA2FC75: virDomainDefParseNode (domain_conf.c:17472)
==21711== by 0xAA2FAE4: virDomainDefParse (domain_conf.c:17419)
==21711== by 0xAA2FB72: virDomainDefParseFile (domain_conf.c:17443)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Setting up cgroups and other things for all kinds of threads (the
emulator thread, vCPU threads, I/O threads) was copy-pasted every time
new thing was added. Over time each one of those functions changed a
bit differently. So create one function that does all that setup and
start using it, starting with I/O thread setup. That will shave some
duplicated code and maybe fix some bugs as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true
qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
^
It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.
This splits the conditional check into two parts with
distinct error messages and fixes the logic error.
Fixes the bug in
commit 5184f398b4
Author: Peter Krempa <pkrempa@redhat.com>
Date: Fri Jul 1 14:56:14 2016 +0200
qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
An error in virHostCPUGetKVMMaxVCPUs() means we've been unable
to access /dev/kvm, or we're running on a platform that doesn't
support KVM in the first place.
If that's the case, we shouldn't ignore the error and report
domcapabilities even though we know the user won't be able to
start any KVM guest.
If we don't HAVE_LINUX_KVM_H, we can't query /dev/kvm to discover
the limits on the number of vCPUs, so we report an error and
return a negative value instead.
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.
Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.
A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.
The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the bootloader is treated as a
custom bootloader.
Custom bootloader are supported by setting the def->os.bootloader and
def->os.bootloaderArgs accordingly
grub-bhyve is also treated as a custom bootloader. Since we don't get the
device map in the native format anyways, we can't reconstruct the complete
boot order. While it is possible to check what type the grub boot disk is by
checking if the --root argument is "cd" or "hd0,msdos1", and then just use the
first disk found, implementing the grub-bhyve argument parser as-is in the
grub-bhyve source would mean adding a dependency to argp or duplicating lots
of the code of argp. Therefore it's not really worth implementing that now.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
loosely based on its argument parser, which reads the following from the bhyve
command line string:
* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime)
* features:
* acpi
* ioapic: While this flag is deprecated in FreeBSD r257423, keep checking for
it for backwards compatibiility.
* the domain UUID; if not explicitely given, one will be generated.
* lpc devices: for now only the com1 and com2 are supported. It is required for
these to be /dev/nmdm[\d+][AB], and the slave devices are automatically
inferred from these to be the corresponding end of the virtual null-modem
cable: /dev/nmdm<N>A <-> /dev/nmdm<N>B
* PCI devices:
* Disks: these are numbered in the order they are found, for virtio and ahci
disks separately. The destination is set to sdX or vdX with X='a'+index;
therefore only 'z'-'a' disks are supported.
Disks are considered to be block devices if the path
starts with /dev, otherwise they are considered to be files.
* Networks: only tap devices are supported. Since it isn't possible to tell
the type of the network, VIR_DOMAIN_NET_TYPE_ETHERNET is assumed, since it
is the most generic. If no mac is specified, one will be generated.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
First, remove escaped newlines and split up the string into an argv-list for
the bhyve and loader commands, respectively. This is done by iterating over the
string splitting it by newlines, and then re-iterating over each line,
splitting it by spaces.
Since this code reuses part of the code of qemu_parse_command.c
(in bhyveCommandLine2argv), add the appropriate copyright notices.
Signed-off-by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
As there is an explicit constructor for the special case of empty
bitmaps, we should mention that the generic constructors rejects the
creation of empty bitmaps.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Before the variable 'bits' was initialized with 0 (commit
3470cd860d), the following bug was
possible.
A function call with an empty bitmap leads to undefined
behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
and 'sz == 1'. So the non global and non static variable 'bits' would
have never been set. Consequently the check 'bits == 0' results in
undefined behavior.
This patch clarifies the current version of the function by handling the
empty bitmap explicitly. Also, for an empty bitmap there is obviously no
bit set so we can just return -1 (indicating no bit set) right away. The
explicit check for 'bits == 0' after the loop is unnecessary because we
only get to this point if no set bit was found.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.
Broken by bd7c8a69.
https://bugzilla.redhat.com/show_bug.cgi?id=1151723
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
People debugging guest OS boot processes and reported that
the default 128 KB size is too small to capture an entire
boot up sequence. Increase the default size to 2 MB which
should allow capturing a full boot up even with verbose
debugging.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently virtlogd has a hardcoded max file size of 128kb
and max of 3 backups. This adds two new config parameters
to /etc/libvirt/virtlogd.conf to let these be customized.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
After 27726d8c21 a privateData is allocated in
virDomainHostdevDefAlloc(). However, the counter part - freeing
them in Free() is missing which leads to the following memory
leak:
==6489== 24 bytes in 1 blocks are definitely lost in loss record 684 of 1,003
==6489== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==6489== by 0x54B7C94: virAllocVar (viralloc.c:560)
==6489== by 0x5517BE6: virObjectNew (virobject.c:193)
==6489== by 0x1B400121: qemuDomainHostdevPrivateNew (qemu_domain.c:798)
==6489== by 0x5557B24: virDomainHostdevDefAlloc (domain_conf.c:2152)
==6489== by 0x5575578: virDomainHostdevDefParseXML (domain_conf.c:12709)
==6489== by 0x5582292: virDomainDefParseXML (domain_conf.c:16995)
==6489== by 0x5583C98: virDomainDefParseNode (domain_conf.c:17470)
==6489== by 0x5583B07: virDomainDefParse (domain_conf.c:17417)
==6489== by 0x5583B95: virDomainDefParseFile (domain_conf.c:17441)
==6489== by 0x55A3F24: virDomainObjListLoadConfig (virdomainobjlist.c:465)
==6489== by 0x55A43E6: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Libxl is the last user and I don't have the toolchain prepared to
compile the libxl driver. Move it to the libxl driver to avoid having to
refactor the code.
This is just a convenience method for discarding a list of filters instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Provide a separate method to free a logging filter object. This will come handy
once a method to create an individual logging filter object is introduced.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This is just a convenience method for discarding a list of outputs instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Provide a separate method to free a logging output object. This will come handy
once a method to create an individual logging output object is introduced.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Same as with outputs; since the operations will be further divided into smaller
tasks, creating a filter will become a separate operation that will return
a reference to a newly created filter.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Right now, we define outputs one after another. However, the correct flow
should be to define a set of outputs as a whole unit. Therefore each output
should be first created, placed into an array/list and the list will be
defined. Output creation should be a separate operation, so an output will be
returned by a reference. From that perspective, it makes perfect sense to
only store pointers to actual outputs.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In this particular case, reset is meant as clearing the whole list of
outputs/filters, not resetting it to a predefined default setting. Looking at
it from that perspective, returning the number of records removed doesn't help
the caller in any way (not that any of the callers would actually check for
it). Well, callers could detect an error from the number of successfully
removed records, but the only thing that can fail in virLogReset is force
closing a file descriptor in which case the error isn't propagated back to
virLogReset anyway. Conclusion: there is no practical use for having a return
type of 'int' rather than 'void' in this case.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.
Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350772
For type='ethernet' interfaces only.
(This patch had been pushed earlier in
commit 0b4645a7e0, but was reverted in
commit 84d47a3cce because it had been
accidentally pushed during the freeze for release 2.0.0)
(This patch had been pushed earlier in
commit cd5c9f21de, but was reverted in
commit 1549f16832 because it had been
accidentally pushed during the freeze for release 2.0.0)
This will apply to any IP address setting that uses
virNetDevIPInfoAddToDev() (which so far is only the guest-side of LXC
type='ethernet' interfaces).
(This patch had been pushed earlier in
commit cb20f989df, but was reverted in
commit cba06aea8d because it had been
accidentally pushed during the freeze for release 2.0.0)
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
(This patch had been pushed earlier in
commit fe6a77898a, but was reverted in
commit d658456530 because it had been
accidentally pushed during the freeze for release 2.0.0)
The peer attribute is used to set the property of the same name in the
interface IP info:
<interface type='ethernet'>
...
<ip family='ipv4' address='192.168.122.5'
prefix='32' peer='192.168.122.6'/>
...
</interface>
Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.
(This patch now has quite a history: it was originally pushed in
commit 690969af, which was subsequently reverted in commit 1d14b13f,
then reworked and pushed (along with a lot of other related/supporting
patches) in commit 93135abf1; however *that* commit had been
accidentally pushed during dev. freeze for release 2.0.0, so it was
again reverted in commit f6acf039f0).
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: Laine Stump <laine@laine.org>
This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.
One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).
(This patch had been pushed earlier in commit
f1e0d0da11, but was reverted in commit
05eab47559 because it had been
accidentally pushed during the freeze for release 2.0.0)
Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.
This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Add a new secret type known as "passphrase" - it will handle adding the
secret objects that need a passphrase without a specific username.
The format is:
<secret ...>
<uuid>...</uuid>
...
<usage type='passphrase'>
<name>mumblyfratz</name>
</usage>
</secret>
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since the virSecretDefParseUsage ensures each of the fields is present,
no need to check during virSecretDefFormatUsage (also virBufferEscapeString
is a no-op with a NULL argument).
Signed-off-by: John Ferlan <jferlan@redhat.com>
A helper that will execute a callback on every USB device
in the domain definition.
With an ability to skip USB hubs, since we will want to treat
them differently in some cases.
I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.
https://bugzilla.redhat.com/show_bug.cgi?id=1323085
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Pretending (partial) support for something we don't understand is risky.
Reporting a failure is much better.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virTypedParameterAssign steals the string rather than copying it into
the typed parameter and thus freeing it leads to a crash when attempting
to serialize the results.
This was introduced in commit 9f50f6e2 and later made an universal
helper in 32e6339c.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351473
Some code paths already assume that it is allocated since it was always
allocated by virDomainPerfDefParseXML. Make it member of virDomainDef
directly so that we don't have to allocate it all the time.
This fixes crash when attempting to connect to an existing process via
virDomainQemuAttach since we would not allocate it in that code path.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350688
Ensure that the given controller and all controllers with a smaller
index exist; there must not be any missing index in between.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The commit "qemu: hot-plug: Assume support for -device in
qemuDomainAttachSCSIDisk" dropped the code for the automatic SCSI
controller creation used in SCSI disk hot-plugging. If we are
hot-plugging a SCSI disk to a domain and there is no proper SCSI
controller defined, it results in an "error: internal error: Could not
find scsi controller with index X required for device" error.
For that reason reverting a hunk of the commit
d4d32005d6.
This patch also adds an extra comment to the code to clarify the
loop.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
CVE-2016-5008
Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".
https://bugzilla.redhat.com/show_bug.cgi?id=1180092
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Similarly to what virsh virt-login-shell do, call virAdmInitialize prior to
initializing an event loop and initializing the error handler. Commit 97973ebb7
described and fixed an identical issue for libvirt_lxc.
Since virAdmInitialize becomes a public API after applying this patch,
the symbol is also added to public syms and the doc string of the method is
slightly enhanced analogically to virInitialize.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
virNetServerClientGetInfo returns the client's remote address
as a string, which is a part of the client object.
Use VIR_STRDUP to make a copy which can be freely accessed
even after the virNetServerClient object is unlocked.
To reproduce, put a sleep between virObjectUnlock in
virNetServerClientGetInfo and virTypedParamsAddString in
adminClientGetInfo, then close the queried connection during
that sleep.
https://bugzilla.redhat.com/show_bug.cgi?id=1316370
Consider the following disk for a domain:
<disk type='volume' device='cdrom'>
<driver name='qemu' type='raw'/>
<auth username='libvirt'>
<secret type='iscsi' usage='libvirtiscsi'/>
</auth>
<source pool='iscsi-secret-pool' volume='unit:0:0:0' mode='direct' startupPolicy='optional'/>
<target dev='sda' bus='scsi'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Now, startupPolicy is currently not allowed for iscsi disks, so
one would expect an error message to be thrown. But what a
surprise is waiting for users if they try to start up such
domain:
==15724== Invalid free() / delete / delete[] / realloc()
==15724== at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==15724== by 0x54B7A69: virFree (viralloc.c:582)
==15724== by 0x552DC90: virStorageAuthDefFree (virstoragefile.c:1549)
==15724== by 0x552F023: virStorageSourceClear (virstoragefile.c:2055)
==15724== by 0x552F054: virStorageSourceFree (virstoragefile.c:2067)
==15724== by 0x55556AA: virDomainDiskDefFree (domain_conf.c:1562)
==15724== by 0x5557ABE: virDomainDefFree (domain_conf.c:2547)
==15724== by 0x1B43CC42: qemuProcessStop (qemu_process.c:5918)
==15724== by 0x1B43BA2E: qemuProcessStart (qemu_process.c:5511)
==15724== by 0x1B48993E: qemuDomainObjStart (qemu_driver.c:7050)
==15724== by 0x1B489B9A: qemuDomainCreateWithFlags (qemu_driver.c:7104)
==15724== by 0x1B489C01: qemuDomainCreate (qemu_driver.c:7122)
==15724== Address 0x21cfbb90 is 0 bytes inside a block of size 48 free'd
==15724== at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==15724== by 0x54B7A69: virFree (viralloc.c:582)
==15724== by 0x552DC90: virStorageAuthDefFree (virstoragefile.c:1549)
==15724== by 0x12D1C8D4: virStorageTranslateDiskSourcePool (storage_driver.c:3475)
==15724== by 0x1B4396E4: qemuProcessPrepareDomain (qemu_process.c:4896)
==15724== by 0x1B43B880: qemuProcessStart (qemu_process.c:5466)
==15724== by 0x1B48993E: qemuDomainObjStart (qemu_driver.c:7050)
==15724== by 0x1B489B9A: qemuDomainCreateWithFlags (qemu_driver.c:7104)
==15724== by 0x1B489C01: qemuDomainCreate (qemu_driver.c:7122)
==15724== by 0x561CA97: virDomainCreate (libvirt-domain.c:6787)
==15724== by 0x12B6FD: remoteDispatchDomainCreate (remote_dispatch.h:4116)
==15724== by 0x12B61A: remoteDispatchDomainCreateHelper (remote_dispatch.h:4092)
The problem is, in virStorageTranslateDiskSourcePool disk
def->src->auth is freed, but the pointer is not set to NULL. So
later, when qemuProcessStop starts to free the domain definition,
virStorageAuthDefFree() tries to free the memory again, instead
of jumping out immediately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit cf0568b0af moved a bunch of functions from virNetDev
to the more specific virNetDevIP; however, not all of the
existing uses were moved properly, causing build failures on
FreeBSD.
Complete the transition to the new names and drop the
obsolete declarations from the header file while at it.
Not including the header causes
util/virnetdevip.c:520:5: error:
unknown type name 'virCommandPtr'; did you mean 'virCondPtr'?
virCommandPtr cmd = NULL;
^~~~~~~~~~~~~
and plenty more similar failures when compiling on FreeBSD.
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types, and 2) we can retain the info when set to
an invalid interface type all the way through to validation and report
a proper error, rather than just ignoring it (which is currently what
happens for many other type-specific settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
The peer attribute is used to set the property of the same name in the
interface IP info:
<interface type='ethernet'>
...
<ip family='ipv4' address='192.168.122.5'
prefix='32' peer='192.168.122.6'/>
...
</interface>
Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.
(This is an updated *re*-commit of commit 690969af, which was
subsequently reverted in commit 1d14b13f).
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: Laine Stump <laine@laine.org>
This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.
One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).
It makes more sense to have the logging at the lower level so other
callers can share the goodness.
While removing so much stuff from / touching so many lines in
lxcContainerRenameAndEnableInterfaces() (which used to have this
debug/error logging), label names were changed and it was updated to
use the now-more-common method of initializing ret to -1 (failure),
then setting to 0 right before the cleanup label.
virDomainNetIPInfoParseXML() and virDomainNetIPInfoFormat() are no
longer "unused", so we can now remove the "ATTRIBUTE_UNUSED" from
their definitions, since virDomainNetIPInfoFormat() is now the only
caller of virDomainNetIPsFormat() and virDomainNetRoutesFormat(),
those two functions can simply be subsumed into
virDomainNetIPInfoFormat().
libvirt's qemu driver doesn't have direct access to the config on the
guest side of a network interface, and currently doesn't have any
method in place to even inform the guest of the desired config. In the
future, an unenforceable attempt to set the guest-side IP info could
be made by adding a static host entry to the appropriate dnsmasq
configuration (or changing the default dhcp client address on the qemu
commandline for type='user' interfaces), or enhancing the guest agent
to allow setting an IP address, but for now it can't have any effect,
and we don't want to give the illusion that it does.
To prevent the "disappearance" of any existing configs with ip
address/route info (due to parser failure), this check is added in the
newly implemented qemuDomainDeviceDefValidate(), which is only called
when a domain is defined or started, *not* when it is reread from disk
at libvirtd startup.
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.
There are currently two places in the domain where this combination is
used, and there is about to be another. This patch puts them together
for brevity and uniformity.
As with the newly-renamed virNetDevIPAddr and virNetDevIPRoute
objects, the new virNetDevIPInfo object will need to be accessed by a
utility function that calls low level Netlink functions (so we don't
want it to be in the conf directory) and will be called from multiple
hypervisor drivers (so it can't be in any hypervisor directory); the
most appropriate place is thus once again the util directory.
The parse and format functions are in conf/domain_conf.c because only
the domain XML (i.e. *not* the network XML) has this exact combination
of IP addresses plus routes. Note that virDomainNetIPInfoFormat() will
end up being the only caller to virDomainNetRoutesFormat() and
virDomainNetIPsFormat(), so it will just subsume those functions in a
later patch, but we can't do that until they are no longer called.
(It would have been nice to include the interface name within the
virNetDevIPInfo object (with a slight name change), but that can't
be done cleanly, because in each case the interface name is provided
in a different place in the XML relative to the routes and IP
addresses, so putting it in this object would actually make the code
more confused rather than simpler).
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.
This patch splits virnetdev.[ch] into multiple files, with the new
virnetdevip.[ch] containing all the functions related to setting and
retrieving IP-related info for a device (both addresses and routes).
When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).
When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.
In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.
This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.
NB: I decided on this course of action after mentioning the
inconsistency here:
https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html
and getting encouragement do eliminate it in a later IRC discussion
with danpb.
in qemuConnectDomainXMLToNative. This function was only accounting for
about 1/10 of all the allocated items in the NetDef prior to memseting
it to all 0's. On top of that, it was going to great pains to learn
the name of the bridge device, but then never doing anything useful
with it (just putting it into data.ethernet.dev, which is *never* used
when building a qemu commandline). (I think this again all started off
as code with good intentions, but it was never completed, and instead
was just Frankensteinically cargo-culted into the odd mish mash we
have today).
The resulting code is much simpler, produces exactly the same output,
and doesn't leak memory.
This patch removes the expanded and duplicated code that all sprung
out of two well-intentioned-but-useless settings of
net->data.(bridge|ethernet).ipaddr.
qemu has never supported even a single IP address in the interface
config, much less a list of them. All of the instances of "clearing
out the IP addresses" that are now in this function originated with
commit d8dbd6 "Basic domain XML conversions for Xen/QEMU drivers" in
May 2009, but even then the single "ipaddr" in the struct for
type='ethernet' and type='bridge' wasn't used in the qemu driver (only
in xen and openvz). Since then anyone who added a new interface type
also tacked on another unnecessary clearing of ipaddr, and when it was
made into a list of IPs (so far supported only by the LXC driver) this
simple setting was turned into a loop (well, multiple loops) to clear
them all.
Commit c9a641 (first appearred in 1.2.12) added support for setting
the guest-side IP address of veth devices in lxc domains.
Unfortunately, it hardcoded the assumption that the proper prefix for
any IP address with no explicit prefix in the config should be "24";
that is only correct for class C IPv4 addresses, but not for any other
IPv4 address, nor for any IPv6 address.
The good news is that there is already a function in libvirt that will
determine the proper default prefix for any IP address. This patch
replaces the use of the ill-fated VIR_SOCKET_ADDR_DEFAULT_PREFIX with
calls to virSocketAddrGetIPPrefix().
lxcContainerRenameAndEnableInterfaces() isn't making a copy of the
interface's ifname_guest (into newname), it's just copying the pointer
to it. This means that when it later calls VIR_FREE(newname), it's
actually freeing up (and fortunately NULLing out, so at least we don't
try to access free'd memory) netDef->ifname_guest.
There are times when we don't have a netmask pointer to give to
virSocketAddrGetIPPrefix() (e.g. the IP addresses in domain interfaces
only have a prefix, no netmask), but it would have caused a segv if we
called it with NULL instead of a pointer to a netmask. This patch
qualifies the code that would use the netmask or address pointers to
check for NULL first.
Rearrange this function to be better organized and more correct:
* the error codes were changed from the incorrect INVALID_ARG to
XML_ERROR
* prefix still isn't required, but if present it must be valid or an
error will be logged.
* don't emit a debug log just because prefix is missing - this
is valid.
* group everything related to setting prefix in one place rather than
scattered through the function.
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)
These had been declared in conf/device_conf.h, but then used in
util/virnetdev.c, meaning that we had to #include conf/device_conf.h
in virnetdev.c (which we have for a long time said shouldn't be done.
This caused a bigger problem when I tried to #include util/virnetdev.h
in a file in src/conf (which is allowed) - for some reason the
"device_conf.h: File not found" error.
The solution is to move the data types and functions used in util
sources from conf to util. Some names were adjusted during the move
("virInterface" --> "virNetDevIf", and "VIR_INTERFACE" -->
"VIR_NETDEV_IF")
virNetDevLinkDump should have been in virnetlink.c, but that file
didn't exist yet when the function was created. It didn't really
matter until now - I found that having virnetlink.h included by
virnetdev.h caused build problems when trying to #include virnetdev.h
in a .c file in src/conf (due to missing directory in -I). Rather than
fix that to further institutionalize the incorrect placement of this
one function, this patch moves the function.
This patch enables admin socket creation in daemon's code, bumps the library
version in libvirt_admin_public.syms, and performs all necessary modifications
to our makefiles so that admin API can finally be included in the tarball,
and eventually become part of an rpm package (a patch later in this series).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
We need this because apply graphics functions is used on
update too. Also in case of NULL address resolve it to default
instead of error.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Move graphic device config to post parse. This way we
detect error on early stage and leverage checking on detach too.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
First we need to always set value to vz sdk parameter so
we can leverage setting code for device updates. This patch
resolves tristate default to off implicitly. This is easier
then extract default value from vz sdk itself. First current
default is off too, second this approach is already taken
for 'net->linkstate'.
Second dump this option in domain xml.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Current code that pass gateways to vz sdk is not suitable for
updates. If update has no gateways while we had them before
we need to pass "" for vz sdk gateways to reset old value.
The code definitely deserves its own function.
Drop checks that skip setting gateways if network address
is not set. Such a configuration is possible in vz sdk.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
