Dmitry Mishin [Tue, 5 Jan 2016 12:25:38 +0000 (07:25 -0500)]
Use tristate constants for new 'append' field
For completeness, use the VIR_TRISTATE_SWITCH_ABSENT for data.file.append
comparisons. Commit ids '70ffa02f' and '53a15aed' just went with the non
zero comparison.
Ján Tomko [Thu, 17 Dec 2015 12:43:58 +0000 (13:43 +0100)]
schema: interleave domain name and uuid with other elements
Allow <name> and <uuid> anywhere under <domain>, not just at the top:
error:XML document failed to validate against schema: Unable to validate
doc against /usr/share/libvirt/schemas/domain.rng
Expecting an element name, got nothing
Invalid sequence in interleave
Element domain failed to validate content
Introduced with the first RelaxNG schema in commit c642103.
We have few code samples there that are almost unreadable when formatted
because they are not indented properly. By indenting them they are
formatted as code and hence quite readable. Also adjust descriptions to
be comments and add semicolons so that the code sample looks like sample
of a working code.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
qemu: Fix return value of qemuDomainGetBlockJobInfo
While reviewing 1b43885d1784640 I've noticed a virReportError()
followed by a goto endjob; without setting the correct return
value. Problem is, if block job is so fast that it's bandwidth
does not fit into ulong, an error is reported. However, by that
time @ret is already set to 1 which means success. Since the
scenario can be hardly considered successful, we should return a
value meaning error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Mon, 21 Dec 2015 15:53:57 +0000 (10:53 -0500)]
docs: update to properly reflect meaning of fields in log filter
The documentation (and comment in libvirtd.conf) says that the text in
a log filter is compared to the "source file name", and gives the
example of "util/json", but this is not correct (at least not since
commit 2835c1e, possibly earlier). It is instead compared to the
string given in the VIR_LOG_INIT() macro invocation at the top of each
source file, which is always "similar to but not the same as" the
source file name (in the example above, the proper name is
"util.json", while the file name is "util/virjson.c"). This patch
corrects the misstatement in both the documentation and in
libvirtd.conf.
Laine Stump [Sun, 20 Dec 2015 22:58:58 +0000 (17:58 -0500)]
util: reduce debug log in virPCIGetVirtualFunctions()
Due to debug logs like this:
virPCIGetDeviceAddressFromSysfsLink:2432 : Attempting to resolve device path from device link '/sys/class/net/eth1/device/virtfn6'
logStrToLong_ui:2369 : Converted '0000:07:00.7' to unsigned int 0
logStrToLong_ui:2369 : Converted '07:00.7' to unsigned int 7
logStrToLong_ui:2369 : Converted '00.7' to unsigned int 0
logStrToLong_ui:2369 : Converted '7' to unsigned int 7
virPCIGetDeviceAddressFromSysfs:1947 : virPCIDeviceAddress 0000:07:00.7
virPCIGetVirtualFunctions:2554 : Found virtual function 7
printed *once for each SR-IOV Virtual Function* of a Physical Function
each time libvirt retrieved the list of VFs (so if the system has 128
VFs, there would be 900 lines of log for each call), the debug logs on
any system with a large number of VFs was dominated by "information"
that was possibly useful for debugging when the code was being
written, but is now useless for debugging of any problem on a running
system, and only serves to obscure the real useful information. This
overkill has no place in production code, so this patch removes it.
Laine Stump [Fri, 18 Dec 2015 21:40:29 +0000 (16:40 -0500)]
util: improve error reporting in virNetDevVPortProfileGetStatus
The previous error message just indicated that the desired response
couldn't be found, this patch tells what was desired, as well as
listing out the entire table that had been in the netlink response, to
give some kind of idea why it failed.
Laine Stump [Fri, 18 Dec 2015 17:08:54 +0000 (12:08 -0500)]
util: report the MAC address that couldn't be set
I noticed in a log file that we had failed to set a MAC address. The
log said which interface we were trying to set, but didn't give the
offending MAC address, which could have been useful in determining the
source of the problem. This patch modifies all three places in the
code that set MAC addresses to report the failed MAC as well as
interface.
Michael Chapman [Thu, 31 Dec 2015 06:04:40 +0000 (17:04 +1100)]
storage: do not leak storage pool XML filename
Valgrind complained:
==28277== 38 bytes in 1 blocks are definitely lost in loss record 298 of 957
==28277== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==28277== by 0x82D7F57: __vasprintf_chk (in /lib64/libc-2.12.so)
==28277== by 0x52EF16A: virVasprintfInternal (stdio2.h:199)
==28277== by 0x52EF25C: virAsprintfInternal (virstring.c:514)
==28277== by 0x52B1FA9: virFileBuildPath (virfile.c:2831)
==28277== by 0x19B1947C: storageDriverAutostart (storage_driver.c:191)
==28277== by 0x19B196A7: storageStateAutoStart (storage_driver.c:307)
==28277== by 0x538527E: virStateInitialize (libvirt.c:793)
==28277== by 0x11D7CF: daemonRunStateInit (libvirtd.c:947)
==28277== by 0x52F4694: virThreadHelper (virthread.c:206)
==28277== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so)
==28277== by 0x82BE93C: clone (in /lib64/libc-2.12.so)
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Michael Chapman [Thu, 31 Dec 2015 06:04:39 +0000 (17:04 +1100)]
qemu: do not leak NBD disk data in migration cookie
Valgrind complained:
==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 188 of 996
==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593)
==18990== by 0x5292E9B: virAllocN (viralloc.c:191)
==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012)
==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413)
==18990== by 0x222228CE: qemuMigrationPrepareAny (qemu_migration.c:3463)
==18990== by 0x22224121: qemuMigrationPrepareDirect (qemu_migration.c:3865)
==18990== by 0x22251C25: qemuDomainMigratePrepare3Params (qemu_driver.c:12414)
==18990== by 0x5389EE0: virDomainMigratePrepare3Params (libvirt-domain.c:5107)
==18990== by 0x1278DB: remoteDispatchDomainMigratePrepare3ParamsHelper (remote.c:5425)
==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
==18990== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156)
==18990==
==18990== 20 (16 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 189 of 996
==18990== at 0x4A057BB: calloc (vg_replace_malloc.c:593)
==18990== by 0x5292E9B: virAllocN (viralloc.c:191)
==18990== by 0x2221E731: qemuMigrationCookieXMLParseStr (qemu_migration.c:1012)
==18990== by 0x2221F390: qemuMigrationEatCookie (qemu_migration.c:1413)
==18990== by 0x222249D2: qemuMigrationRun (qemu_migration.c:4395)
==18990== by 0x22226365: doNativeMigrate (qemu_migration.c:4693)
==18990== by 0x22228E45: qemuMigrationPerform (qemu_migration.c:5553)
==18990== by 0x2225144B: qemuDomainMigratePerform3Params (qemu_driver.c:12621)
==18990== by 0x539F5D8: virDomainMigratePerform3Params (libvirt-domain.c:5206)
==18990== by 0x127305: remoteDispatchDomainMigratePerform3ParamsHelper (remote.c:5557)
==18990== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
==18990== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
If we're replacing the NBD data, it's simplest to free the old object
(including the disk list) and allocate a new one.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Michael Chapman [Thu, 31 Dec 2015 06:04:38 +0000 (17:04 +1100)]
qemu: do not copy out non-existent block job info
Valgrind complained:
==23975== Conditional jump or move depends on uninitialised value(s)
==23975== at 0x22255FA6: qemuDomainGetBlockJobInfo (qemu_driver.c:16538)
==23975== by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685)
==23975== by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834)
==23975== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
==23975== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
==23975== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156)
==23975== by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145)
==23975== by 0x52F4668: virThreadHelper (virthread.c:206)
==23975== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so)
==23975== by 0x82BE93C: clone (in /lib64/libc-2.12.so)
==23975==
==23975== Conditional jump or move depends on uninitialised value(s)
==23975== at 0x22255FB4: qemuDomainGetBlockJobInfo (qemu_driver.c:16542)
==23975== by 0x538E97C: virDomainGetBlockJobInfo (libvirt-domain.c:9685)
==23975== by 0x12F740: remoteDispatchDomainGetBlockJobInfoHelper (remote.c:2834)
==23975== by 0x53FF287: virNetServerProgramDispatch (virnetserverprogram.c:437)
==23975== by 0x540523D: virNetServerProcessMsg (virnetserver.c:135)
==23975== by 0x54052C7: virNetServerHandleJob (virnetserver.c:156)
==23975== by 0x52F515B: virThreadPoolWorker (virthreadpool.c:145)
==23975== by 0x52F4668: virThreadHelper (virthread.c:206)
==23975== by 0x6E08A50: start_thread (in /lib64/libpthread-2.12.so)
==23975== by 0x82BE93C: clone (in /lib64/libc-2.12.so)
If no matching block job is found, qemuMonitorGetBlockJobInfo returns 0
and we should not write anything to the caller-supplied
virDomainBlockJobInfo pointer.
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Michal Privoznik [Sun, 20 Dec 2015 08:16:33 +0000 (09:16 +0100)]
tools: Disable virt-login-shell on mingw
So, after bec787ee9da we are building virt-login-shell
independent of LXC driver. This is nice, but the binary is
enabled by default which makes no sense on mingw. In fact, it
triggers some compilation errors there:
CC virt_login_shell-virt-login-shell.o
../../tools/virt-login-shell.c: In function 'main':
../../tools/virt-login-shell.c:289:15: error: implicit declaration of function 'sysconf' [-Werror=implicit-function-declaration]
openmax = sysconf(_SC_OPEN_MAX);
^
../../tools/virt-login-shell.c:289:5: error: nested extern declaration of 'sysconf' [-Werror=nested-externs]
openmax = sysconf(_SC_OPEN_MAX);
^
../../tools/virt-login-shell.c:289:23: error: '_SC_OPEN_MAX' undeclared (first use in this function)
openmax = sysconf(_SC_OPEN_MAX);
^
../../tools/virt-login-shell.c:289:23: note: each undeclared identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
While we could workaround sysconf(_SC_OPEN_MAX) issue, the binary
itself makes no sense on systems where no LXC can be spawned.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Sun, 20 Dec 2015 07:27:21 +0000 (08:27 +0100)]
sysconf: Include unistd.h
The manpage for sysconf() suggest including unistd.h as the
function is declared there. Even though we are not hitting any
compile issues currently, let's include the correct header file
instead of relying on some hidden include chain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 17 Dec 2015 10:06:51 +0000 (11:06 +0100)]
virStorageVolWipe: Document that wiping journaled FS is useless
So you have a libvirt volume that you want to wipe out. But lets
say that the volume is actually a file stored on a journaled
filesystem. Overwriting it with zeroes or a pattern does not mean
that corresponding physical location on the disk is overwritten
too, due to journaling. It's the same story with network based
volumes, copy-on-write filesystems, and so on. Since there is no
way that an userland application can write onto specific areas on
disk, all that we can do is document the fact.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Maxim Nestratov [Thu, 24 Dec 2015 12:58:59 +0000 (15:58 +0300)]
vz: BUG: fix connecting hang in case of init failure
In case of prlsdkLoadDomains fails, vzOpenDefault should
clear connection privateData pointer every time its
memory is actually freed.
Also it is not necessary to call vzConnectClose if a call
to vzOpenDefault fails, because they both make cleanup of
connection privateData.
Dmitry Mishin [Thu, 24 Dec 2015 14:27:55 +0000 (17:27 +0300)]
qemu: Process new 'append' attribute for char dev with output to a file
By default, QEMU truncates serial file on open. Sometimes, it could be weird -
for example, when we are trying to investigate some event, which occured several
restarts ago. This patch adds an ability to preserve previous content.
Dmitry Mishin [Thu, 24 Dec 2015 14:27:54 +0000 (17:27 +0300)]
conf: Add new 'append' attribute for chardevs with file source
Currently, there is no possibility for user to specify desired behaviour of
output to file - truncate or append. This patch adds an ability to explicitly
specify that user wants to preserve file's content on reopen.
Maxim Nestratov [Tue, 22 Dec 2015 15:29:39 +0000 (18:29 +0300)]
vz: move prlsdkCleanupBridgedNet after domain deletion
prlsdkCleanupBridgedNet call should be made strongly after
any actual domain deletion accurs. By doing this we avoid
any potential problems connected with second undefine call
when it is made after first one fails by some reason, and
we detect that network is already deleted.
Maxim Nestratov [Tue, 22 Dec 2015 15:29:38 +0000 (18:29 +0300)]
vz: delete domains when undefine is called
Currently vz driver unregisters domains when undefine is called,
which is wrong because it contradicts with expected behavior.
All vz domains are persistent, which means that when one is
defined a new bundle directory containing meta data is created.
Undefining domains in a way we do now leaves those directories
undeleted, which prevents subsequent define call for the same
domain xml. I.e. the following sequence define->undefine->define
doesn't work now.
The patch fixes the problem by calling PrlVm_Delete instead of
PrlVm_Unreg detaching all disks prior actually doing this to
prevent images deletion.
Andrea Bolognani [Thu, 17 Dec 2015 10:54:14 +0000 (11:54 +0100)]
hostdev: Mark PCI devices as inactive as they're detached
We want to eventually factor out the code dealing with device detaching
and reattaching, so that we can share it and make sure it's called eg.
when 'virsh nodedev-detach' is used.
For that to happen, it's important that the lists of active and inactive
PCI devices are updated every time a device changes its state.
Instead of passing NULL as the last argument of virPCIDeviceDetach() and
virPCIDeviceReattach(), pass the proper list so that it can be updated.
Andrea Bolognani [Fri, 23 Oct 2015 09:54:07 +0000 (11:54 +0200)]
pci: Introduce virPCIStubDriver enumeration
This replaces the virPCIKnownStubs string array that was used
internally for stub driver validation.
Advantages:
* possible values are well-defined
* typos in driver names will be detected at compile time
* avoids having several copies of the same string around
* no error checking required when setting / getting value
The names used mirror those in the
virDomainHostdevSubsysPCIBackendType enumeration.
Erik Skultety [Thu, 10 Dec 2015 12:46:45 +0000 (13:46 +0100)]
Revert "admin: Rename virAdmConnect to virAdmDaemon"
Commmit df8192aa introduced admin related rename and some minor
(caused by automated approach, aka sed) and some more severe isues along with
it. First reason to revert is the inconsistency with libvirt library.
Although we deal with the daemon directly rather than with a specific
hypervisor, we still do have a connection. That being said, contributors might
get under the impression that AdmDaemonNew would spawn/start a new daemon
(since it's admin API, why not...), or AdmDaemonClose would do the exact
opposite or they might expect DaemonIsAlive report overall status of the daemon
which definitely isn't the case.
The second reason to revert this patch is renaming virt-admin client. The
client tool does not necessarily have to reflect the names of the API's it's
using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
where noone can be certain of what the latter function really does. The former
is quite expressive about some connection magic it performs, but the latter does
not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
left untouched.
Jim Fehlig [Tue, 15 Dec 2015 21:47:40 +0000 (14:47 -0700)]
Xen: support maxvcpus in xm and xl config
From: Ian Campbell <ian.campbell@citrix.com>
xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
as a bit map of which cpus are online (default is all).
xend from 4.0 onwards understands maxvcpus as maxvcpus and
vcpus as the number which are online (from 0..N-1). The
upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
claims that if maxvcpus is omitted then the old behaviour
(i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
in this case vcpu==maxcpus==online cpus. This is good for us
because handling anything else would be fiddly.
This patch changes parsing of the virDomainDef maxvcpus and vcpus
entries to use the corresponding 'maxvcpus' and 'vcpus' settings
from xm and xl config. It also drops use of the old Xen 3.x
'vcpu_avail' setting.
The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
maxvcpus is simply a count, not a bit mask), which is particularly
crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
expected to support vcpu placement, and therefore only the boot
vcpu's info lives in the shared info page).
Existing tests adjusted accordingly, and new tests added for the
'maxvcpus' setting.
Commit id '3c7590e0a' added the flag to the rbd backend, but provided
no means via virsh to use the flag. This patch adds a '--delete-snapshots'
option to both the "undefine" and "vol-delete" commands.
For "undefine", the flag is combined with the "--remove-all-storage" flag
in order to add the appropriate flag for the virStorageVolDelete call;
whereas, for the "vol-delete" command, just the flag is sufficient since
it's only operating on one volume.
John Ferlan [Fri, 18 Dec 2015 13:25:47 +0000 (08:25 -0500)]
lxc_cgroup: Add check for NULL cgroup before AddTask call
Commit id '71ce4759' altered the cgroup processing with respect to the
call to virCgroupAddTask being moved out from lower layers into the calling
layers especially for qemu processing of emulator and vcpu threads. The
movement affected lxc insomuch as it is possible for a code path to
return a NULL cgroup *and* a 0 return status via virCgroupNewPartition
failure when virCgroupNewIgnoreError succeeded when virCgroupNewMachineManual
returns. Coverity pointed out that would cause virCgroupAddTask to core.
This patch will check for a NULL cgroup as well as the negative return
and just return the NULL cgroup to the caller (as it would have previously)
Jim Fehlig [Tue, 15 Dec 2015 00:44:30 +0000 (17:44 -0700)]
Xen: xenconfig: remove disks from '(image)' sexpr
It has been quite some time since xend required specifying cdroms
and fds in '(image (hvm ...))'. Remove the code from the parsing
and formatting functions and fixup the associated tests.
Jim Fehlig [Mon, 14 Dec 2015 21:24:56 +0000 (14:24 -0700)]
Xen: tests: remove net-ioemu xm config test
Remove the fullvirt-net-ioemu test since explicitly specifying
'type=ioemu' has not been needed in xm/xend for a long time. It is
not used at all in xl/libxl.
Utilize recently added VIR_STORAGE_POOL_CREATE_WITH_BUILD* flags in
order to pass the flags along to the virStoragePoolCreateXML and
virStoragePoolCreate API's.
This affects the 'virsh pool-create', 'virsh pool-create-as', and
'virsh pool-start' commands. While it could be argued that pool-start
doesn't need the flags, they could prove useful for someone trying to
do one command build --overwrite and start command processing or
essentially starting with a clean slate.
NB:
This patch is loosely based upon code originally authored by Osier
Yang that were not reviewed and pushed, see:
John Ferlan [Wed, 25 Nov 2015 13:57:30 +0000 (08:57 -0500)]
virsh: Create a macro for pool-define-as and pool-create-as options
Although they both are the same now, a future patch will add new options
to pool-create-as. So create a common macro to capture commonality, then
use that in the command specific structure.
John Ferlan [Wed, 25 Nov 2015 14:08:54 +0000 (09:08 -0500)]
virsh: Create macro for "file" option
Rather than continually cut/paste the "file" option for pool command
option structures, generate a macro which will commonly define it for
any command. Then of course use that macro.
John Ferlan [Wed, 25 Nov 2015 14:06:33 +0000 (09:06 -0500)]
virsh: Create macro for "pool" option
Rather than continually cut/paste the "pool" option for pool command
option structures, generate a macro which will commonly define it for
any command. Then of course use that macro.
Add flags handling to the virStoragePoolCreate and virStoragePoolCreateXML
API's which will allow the caller to provide the capability for the storage
pool create API's to also perform a pool build during creation rather than
requiring the additional buildPool step. This will allow transient pools
to be defined, built, and started.
The new flags are:
* VIR_STORAGE_POOL_CREATE_WITH_BUILD
Perform buildPool without any flags passed.
* VIR_STORAGE_POOL_CREATE_WITH_BUILD_OVERWRITE
Perform buildPool using VIR_STORAGE_POOL_BUILD_OVERWRITE flag.
* VIR_STORAGE_POOL_CREATE_WITH_BUILD_NO_OVERWRITE
Perform buildPool using VIR_STORAGE_POOL_BUILD_NO_OVERWRITE flag.
It is up to the backend to handle the processing of build flags. The
overwrite and no-overwrite flags are mutually exclusive.
NB:
This patch is loosely based upon code originally authored by Osier
Yang that were not reviewed and pushed, see:
Ján Tomko [Wed, 12 Aug 2015 14:52:11 +0000 (16:52 +0200)]
Remove dead code from qemuDomainAttachControllerDevice
We only support hotplugging SCSI controllers.
The USB and virtio-serial related code was never reachable because
this function was only called for VIR_DOMAIN_CONTROLLER_TYPE_SCSI
controllers.
John Ferlan [Wed, 16 Dec 2015 16:54:04 +0000 (11:54 -0500)]
storage: Fix startup issue for logical pool
Commit id '71b803ac' assumed that the storage pool source device path
was required for a 'logical' pool. This resulted in a failure to start
a pool without any device path defined.
So, adjust the virStorageBackendLogicalMatchPoolSource logic to
return success if at least the pool name matches the vgs output
when no pool source device path is/are provided.
John Ferlan [Tue, 15 Dec 2015 18:39:44 +0000 (13:39 -0500)]
qemu: Fix event generated for qemuDomainRevertToSnapshot (pause->run)
A closer review of the code shows that for the transition from paused to
running which was supposed to emit the VIR_DOMAIN_EVENT_RESUMED - no event
would be generated. Rather the event is generated when going from running
to running.
Following the 'was_running' boolean shows it is set when the domain obj
is active and the domain obj state is VIR_DOMAIN_RUNNING. So rather than
using was_running to generate the RESUMED event, use !was_running
When a volume wipe is successful, perform a volume refresh afterwards to
update any volume data that may be used in future volume commands, such as
volume resize. For a raw file volume, a wipe could truncate the file and
a followup volume resize the capacity may fail because the volume target
allocation isn't updated to reflect the wipe activity.
Ján Tomko [Fri, 11 Dec 2015 15:37:34 +0000 (16:37 +0100)]
storage: fix return values of virStorageBackendWipeExtentLocal
Return -1:
* on all failures of fdatasync. Instead of propagating -errno
all the way up to the virStorageVolWipe API, which is documented
to return 0 or -1.
* after a partial wipe. If safewrite failed, we would re-use the
non-negative return value of lseek (which should be 0 in this case,
because that's the only offset we seek to).
Andrea Bolognani [Thu, 10 Dec 2015 18:13:58 +0000 (19:13 +0100)]
qemu: Allow qemuDomainAdjustMaxMemLock() to restore previous value
When the function changes the memory lock limit for the first time,
it will retrieve the current value and store it inside the
virDomainObj for the domain.
When the function is called again, if memory locking is no longer
needed, it will be able to restore the memory locking limit to its
original value.
Eric Blake [Tue, 13 Oct 2015 20:47:42 +0000 (14:47 -0600)]
build: disable vbox on cygwin
Cygwin cannot build the vbox driver yet:
CC vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo
In file included from vbox/vbox_glue.c:27:0:
vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me"
# error "Port me"
^
In file included from vbox/vbox_XPCOMCGlue.c:45:0,
from vbox/vbox_glue.c:27:
vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne':
vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function)
if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0)
^
./util/virstring.h:245:31: note: in definition of macro 'virAsprintf'
strp, __VA_ARGS__)
^
Rather than trying to figure out how to get dynamic loading of
vbox to work under cygwin (since I don't even have a working vbox
setup to test whether it works), I'm going to be lazy and just
default to not even trying vbox on cygwin.
Andrea Bolognani [Tue, 15 Dec 2015 08:44:35 +0000 (09:44 +0100)]
pci: Use virPCIDeviceAddress in virPCIDevice
Instead of replicating the information (domain, bus, slot, function)
inside the virPCIDevice structure, use the already-existing
virPCIDeviceAddress structure.
For users of the module, this means that the object returned by
virPCIDeviceGetAddress() can no longer be NULL and must no longer
be freed by the caller.
Ian Campbell [Thu, 10 Dec 2015 11:38:36 +0000 (11:38 +0000)]
libxl: Use libxentoollog in preference to libxenctrl if available.
Upstream Xen is in the process of splitting the (stable API) xtl_*
interfaces out from the (unstable API) libxenctrl library and into a
new (stable API) libxentoollog.
In order to be compatible with Xen both before and after this
transition check for xtl_createlogger_stdiostream in a libxentoollog
library and use it if present. If it is not present assume it is in
libxenctrl.
Compile tested on Xen 4.6 and a development tree with the split in
place.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Joao Martins [Fri, 13 Nov 2015 13:14:48 +0000 (13:14 +0000)]
libxl: implement virDomainGetJobStats
Introduces support for domainGetJobStats which has the same
info as domainGetJobInfo but in a slightly different format.
Another difference is that virDomainGetJobStats can also
retrieve info on the most recently completed job. Though so
far this is only used in the source node to know if the
migration has been completed. But because we don't support
completed jobs we will deliver an error.
Joao Martins [Fri, 13 Nov 2015 13:14:47 +0000 (13:14 +0000)]
libxl: implement virDomainGetJobInfo
Introduce support for domainGetJobInfo to get info about the
ongoing job. If the job is active it will update the
timeElapsed which is computed with the "started" field added to
struct libxlDomainJobObj. For now we support just the very basic
info and all jobs have VIR_DOMAIN_JOB_UNBOUNDED (i.e. no completion
time estimation) plus timeElapsed computed.
Openstack Kilo uses the Job API to monitor live-migration
progress which is currently nonexistent in libxl driver and
therefore leads to a crash in the nova compute node. Right
now, migration doesn't use jobs in the source node and will
return VIR_DOMAIN_JOB_NONE. Though nova handles this case and
will migrate it properly instead of crashing.
Add a new helper virStorageBackendLogicalMatchPoolSource to compare the
pool's source name against the output from a 'pvs' command to list all
volume group physical volume data on the host. In addition, compare the
pool's source device list against the particular volume group's device
list to ensure the source device(s) listed for the pool match what the
was listed for the volume group.
Then for pool startup or check API's we need to call this new API in
order to ensure that the pool we're about to start or declare active
during checkPool has a valid definition vs. the running host.
John Ferlan [Mon, 7 Dec 2015 16:27:03 +0000 (11:27 -0500)]
storage: Create helper for virStorageBackendLogicalFindPoolSources
Rework virStorageBackendLogicalFindPoolSources a bit to create a
helper virStorageBackendLogicalGetPoolSources that will make the
pvs call in order to generate a list of associated pv_name and vg_name's.
A future patch will make use of this for start/check processing to
ensure the storage pool source definition matches expectations.
When determining whether a FS pool is mounted, rather than assuming that
the FS pool is mounted just because the target.path is in the mount list,
let's make sure that the FS pool source matches what is mounted
Then the first disk device in the config will have ",bootindex=1"
appended to its qemu commandline -device options, and the first (and
*only* the first) network interface device will get ",bootindex=2".
However, if the first network interface device is a "hostdev" device
(an SRIOV Virtual Function (VF) being assigned to the domain with
vfio), then the bootindex option will *not* be appended. This happens
because the bootindex=n option corresponding to the order of "<boot
dev='network'/>" is added to the -device for the first network device
when network device commandline args are constructed, but if it's a
hostdev network device, its commandline arg is instead constructed in
the loop for hostdevs.
This patch fixes that omission by noticing (in bootHostdevNet) if the
first network device was a hostdev, and if so passing on the proper
bootindex to the commandline generator for hostdev devices - the
result is that ",bootindex=2" will be properly appended to the first
"network" device in the config even if it is really a hostdev
(including if it is assigned from a libvirt network pool). (note that
this is only the case if there is no <bootmenu enabled='yes'/> element
in the config ("-boot menu-on" in qemu) , since the two are mutually
exclusive - when the bootmenu is enabled, the individual per-device
bootindex options can't be used by qemu, and we revert to using "-boot
order=xyz" instead).
If a greater level of control over boot order is desired (e.g., more
than one network device should be tried, or a network device other
than the first one encountered in the config), then <boot
dev='network'/> in the <os> element should not be used; instead, the
individual device elements in the config should be given a "<boot
order='n'/>
Pavel Hrdina [Tue, 15 Dec 2015 10:04:49 +0000 (11:04 +0100)]
qemuMonitorJSONEjectMedia: don't stringify the replay at all
Commit 256496e1 introduced a detection if "is locked" in error replay
from qemu monitor. Commit c4073657 fixed a memory leak, but it was
pointed out by Peter, that this could be done cleaner without
stringifing the replay.
The return value of virJSONValueToString() should be freed when
no longer needed. This is not the case after 256496e1.
==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of 1,239
==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902== by 0x552BAD9: virStrdup (virstring.c:726)
==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902== by 0x1DF6EBB9: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2225)
==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966)
==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of 1,239
==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902== by 0x552BAD9: virStrdup (virstring.c:726)
==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902== by 0x1DF6EC0C: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2227)
==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Henning Schild [Mon, 14 Dec 2015 20:58:05 +0000 (15:58 -0500)]
qemu cgroups: move new threads to new cgroup after cpuset is set up
Moving tasks to cgroups implied sched_setaffinity. Changing the cpus in
a set implies the same for all tasks in the group.
The old code put the the thread into the cpuset inherited from the
machine cgroup, which allowed it to run outside of vcpupin for a short
while.
Henning Schild [Mon, 14 Dec 2015 20:48:05 +0000 (15:48 -0500)]
qemu: do not put a task into machine cgroup
The machine cgroup is a superset, a parent to the emulator and vcpuX
cgroups. The parent cgroup should never have any tasks directly in it.
In fact the parent cpuset might contain way more cpus than the sum of
emulatorpin and vcpupins. So putting tasks in the superset will allow
them to run outside of <cputune>.
Michal Privoznik [Sun, 13 Dec 2015 06:54:46 +0000 (07:54 +0100)]
virNetDevMacVLanTapSetup: Drop @multiqueue argument
Firstly, there's a bug (or typo) in the only place where we call
this function: @multiqueue is set whenever @tapfdSize is greater
than zero, while in fact the condition should have been 'greater
than one'.
Then, secondly, since the condition depends on just one
variable, that we are even passing down to the function, we can
move the condition into the function and drop useless argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
projects / libvirt.git / log