When libvirt create's the vport (VPORT_CREATE) for the vHBA, there isn't
enough "time" between the creation and the running of the following
backend->refreshPool after a backend->startPool in order to find the LU's.
Population of LU's happens asynchronously when udevEventHandleCallback
discovers the "new" vHBA port. Creation of the infrastructure by udev
is an iterative process creating and discovering actual storage devices and
adjusting the environment.
Because of the time it takes to discover and set things up, the backend
refreshPool call done after the startPool call will generally fail to
find any devices. This leaves the newly started pool appear empty when
querying via 'vol-list' after startup. The "workaround" has always been
to run pool-refresh after startup (or any time thereafter) in order to
find the LU's. Depending on how quickly run after startup, this too may
not find any LUs in the pool. Eventually though given enough time and
retries it will find something if LU's exist for the vHBA.
This patch adds a thread to be executed after the VPORT_CREATE which will
attempt to find the LU's without requiring the external run of refresh-pool.
It does this by waiting for 5 seconds and searching for the LU's. If any
are found, then the thread completes; otherwise, it will retry once more
in another 5 seconds. If none are found in that second pass, the thread
gives up.
Things learned while investigating this... No need to try and fill the
pool too quickly or too many times. Over the course of creation, the udev
code may 'add', 'change', and 'delete' the same device. So if the refresh
code runs and finds something, it may display it only to have a subsequent
refresh appear to "lose" the device. The udev processing doesn't seem to
have a way to indicate that it's all done with the creation processing of a
newly found vHBA. Only the Lone Ranger has silver bullets to fix everything.
John Ferlan [Wed, 19 Nov 2014 15:06:22 +0000 (10:06 -0500)]
storage: Fix issue finding LU's when block doesn't exist
Fix a problem in the getBlockDevice and processLU where retval initialized
to zero causing some failures to erroneously continue through to the
virStorageBackendSCSINewLun with an attempt to find a path for "/dev/(null)".
This would fail approximately 10 seconds later with debug message:
virStorageBackendSCSINewLun:203 :
No stable path found for '/dev/(null)' in '/dev/disk/by-path'
The root cause of the issue is for many /sys/bus/scsi/devices/<lun path>
there is no "block*" device found for the vHBA's, where "<lun path>" are
the various paths created for the vHBA, such as "17:0:0:0", "17:0:1:0",
"17:0:2:0", "17:0:3:0", etc. If the block device isn't found, then the
directory should just be ignored rather than attempting to process it.
The bug was that in getBlockDevice the assumption was "block" would exist
and either getNewStyleBlockDevice or getOldStyleBlockDevice would fill in
@block_device. However, if 'block*' doesn't exist, then the code returned
NULL for block_device *and* a good (zero) retval value. This caused the
processLU code to attempt the virStorageBackendSCSINewLun which failed
"at some point in time" in the future.
After this change - on test system the refresh-pool didn't have a noticable
pause of about 20 seconds - it completed within a second since no longer
was there an attempt/need to find "/dev/(null)".
Additionally, the virStorageBackendSCSIFindLU's shouldn't be declaring
found unless the processLU actually returns success. This will be
important in the followup patch which relies on whether a LU was found.
Erik Skultety [Thu, 20 Nov 2014 11:52:57 +0000 (12:52 +0100)]
virsh: Fix msg: blockjob is aborted from another client
When a block{pull, copy, commit} is aborted via keyboard interrupt,
the job is properly canceled followed by proper error message.
However, when the job receives an abort from another client connected
to the same domain, the error message incorrectly indicates that
a blockjob has been finished successfully, though the abort request
took effect. This patch introduces a new blockjob abort handler, which
is registered when the client calls block{copy,commit,pull} routine,
providing its caller the status of the finished blockjob.
Jiri Denemark [Thu, 20 Nov 2014 12:09:16 +0000 (13:09 +0100)]
qemu: Fix crash in tunnelled migration
Any attempt to start a tunnelled migration with libvirtd that supports
RDMA migration (specifically commit v1.2.8-226-ged22a47) crashes
libvirtd on the destination host.
The crash is inevitable because qemuMigrationPrepareAny is always called
with NULL protocol in case of tunnelled migration.
Michal Privoznik [Wed, 19 Nov 2014 17:16:12 +0000 (18:16 +0100)]
qemu: Drop OVMF whitelist
As discussed on the upstream list, it's better not to make this
kind of predictions in libvirt. It may happen that qemu learns
how to enable OVMF on other architectures too and we shouldn't
try to chase that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 19 Nov 2014 15:25:56 +0000 (16:25 +0100)]
qemu: Support OVMF on armv7l aarch64 guests
Currently, we are whitelisting architectures, that we know how to run
OVMF on. So far, only x86_64 was enabled. However, looking at qemu
code, the same commandline can be used to enable OVMF for armv7l and
aarch64.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Eric Blake [Mon, 17 Nov 2014 23:39:48 +0000 (16:39 -0700)]
maint: forbid 'int foo = true'
I noticed this while working on qemuDomainGetBlockInfo. Assigning
a bool value to an int variable compiles fine, but raises red flags
on the maintenance front as it becomes too easy to assign -1 or 2
or any other non-bool value to the same variable.
Eric Blake [Tue, 18 Nov 2014 00:18:58 +0000 (17:18 -0700)]
virdbus: don't force users to pass int for bool values
Use of an 'int' to represent a 'bool' value is confusing. Just
because dbus made the mistake of cementing their 4-byte wire
format of dbus_bool_t into their API doesn't mean we have to
repeat the mistake. With a little bit of finesse, we can
guarantee that we provide a large-enough value to the DBus
code, while still copying only the relevant one-byte bool
to the client code, and isolate the rest of our code base from
the DBus stupidity.
* src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
(virDBusMessageIterDecode): Adjust all clients.
* src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
* tests/virdbustest.c (testMessageSimple, testMessageStruct):
Test new behavior.
Yohan BELLEGUIC [Wed, 19 Nov 2014 08:53:15 +0000 (09:53 +0100)]
vbox: fix a bug in _machineStateInactive
This function returned non-inactive domains instead of active
domains. This broke virConnectNumOfDefinedDomains() and
virConnectListDefinedDomains() functions.
network: Add network bandwidth support to ethernet interfaces
Ethernet interfaces in libvirt currently do not support bandwidth setting.
For example, following xml file for an interface will not apply these
settings to corresponding qdiscs.
Michal Privoznik [Tue, 18 Nov 2014 15:58:54 +0000 (16:58 +0100)]
docs: Document NVRAM behavior on transient domains
Since 1.2.8 it's possible to use OVMF on domains. Moreover, it's
possible to have libvirt create NVRAM file per domain. Later,
when domain is undefined, the file is removed too. However,
things are a bit complicated when domain's transient. There's no
undefine to transient domains. There are two options: 1) leave
the file behind and let mgmt app remove it. 2) remove it
automatically as domain dies.
But, in some scenarios mgmt app may want to preserve the file,
copy it somewhere safe, and then copy it back when the domain is
starting again. And this wouldn't be possible with case 2). So,
even though case 1) leaves some files behind (possibly undeleted
for a long time), the files themselves are small (128K each). And
data loss is worse than full disk, isn't it?
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
After a disk is hotunplugged a subsequent call to qemuDomainGetBlockIoTune
to get the --config settings of that disk will fail because the disk is no
longer found by qemuDiskPathToAlias causing an unexpected failure.
Since only the --live flag needs to have the disk device pointer, move the
fetch inside the (flags & VIR_DOMAIN_AFFECT_LIVE) condition. This will also
affect the results if no flags are provided or the --current flag is provided.
John Ferlan [Wed, 12 Nov 2014 15:16:51 +0000 (10:16 -0500)]
qemu: Add checks for blkdeviotune 'size_iops_sec' and adjust error
Seems the 'size_iops_sec' was a late add and the checks for whether
the field was defined, but unsupported and the maximum size of the
field were not being made.
Also, adjust blkdeviotune support error message for grammar, spelling
(paramater), and remove the "(need QEMU 1.7 or superior)". None of
our other similar error messages list which QEMU version is required.
bracket-spacing: Add syntax-check for unnecessary curly brackets
We're looking for three consecutive lines, first one is a if/for/while
with a condition and start of body, second one is a body with one and
only semicolon and third is end of the body by itself.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Change while () { smth; last; } to if () { smth; } as 'last' in perl is
analogous to 'break' in C. These are probably copy-paste leftovers from
creating new syntax-check rules.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
In bracket-spacing.pl, the current $line is being modified in $data.
That, however, spoils that $data for another check. Introduce new
$tmpdata variable that can be used for temporary modifications. The
difference between $data and $line is that $data are as much cleaned as
possible from non-code blocks and these changes must be kept.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Rule sc_prohibit_newline_at_end_of_diagnostic for syntax-check does
check for passing strings ending with '\n' two lines after known
functions. This is, of course subject to false positives, so for the
sake of future changes, trick that syntax-check by adding one more line
with a comment.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This only ever had effect with the virtual network driver,
as it was not wired up into the nwfilter driver. Unfortunately
in the firewall refactoring the use of the -w flag was
accidentally lost.
This patch introduces it to the virfirewall.c module so that
both the virtual network and nwfilter drivers will be using
it. It also ensures that the equivalent --concurrent flag
to ebtables is used.
Jiri Denemark [Wed, 12 Nov 2014 15:49:59 +0000 (16:49 +0100)]
qemu: Don't try to parse -help for new QEMU
Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
(and other commands, such as -cpu ?) output. However, if QMP probing
failed, we still tried starting QEMU with various options and parsing
the output, which was guaranteed to fail because the output changed.
Let's just refuse parsing -help for QEMU >= 1.2.0.
Jiri Denemark [Mon, 10 Nov 2014 13:46:26 +0000 (14:46 +0100)]
qemu: Always set migration capabilities
We used to set migration capabilities only when a user asked for them in
flags. This is fine when migration succeeds since the QEMU process is
killed in the end but in case migration fails or if it's cancelled, some
capabilities may remain turned on with no way to turn them off. To fix
that, migration capabilities have to be turned on if requested but
explicitly turned off in case they were not requested but QEMU supports
them.
virsh: Error out if VSH_OT_STRING option has VSH_OFLAG_REQ flag
Recent commit 12bd207e217f3c5dc2272a5ea943b81067bd8034 fixed few
VSH_OT_STRING options that should've been VSH_OT_DATA. That lead me to
this commit that enforces people to check that newly added options have
proper type. Thanks to virsh erroring out with error message, this will
immediately show up in 'make check' thanks to our virsh-synopsis test.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Even though vshCmddefOptParse() tried returning -1 if there was an
optional option specification that preceded a required one, it failed to
check that for boolean type options and options with VSH_OFLAG_REQ_OPT
flag set. On the other hand, it makes sense that VSH_OT_ARGV is
specified at the end of the option list.
Returning -1 enforces the proper ordering thanks to virsh-synopsis test
in 'make check'.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
According to comments in parsing functions, optional options should be
specified *after* required ones. It makes sense and help output looks
cleaner. The only exceptions are options with type == VSH_OT_ARGV.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Conrad Meyer [Wed, 12 Nov 2014 22:31:53 +0000 (17:31 -0500)]
drvbhyve: Use boot-order for grub-bhyve boot device
Rather than just picking the first CD (or failing that, HDD) we come
across, if the user has picked a boot device ordering with <boot
order=''>, respect that (and just try to boot the lowest-index device).
Adds two sets of tests to bhyve2xmlargv; 'grub-bootorder' shows that we
pick a user-specified device over the first device in the domain;
'grub-bootorder2' shows that we pick the first (lowest index) device.
Erik Skultety [Fri, 24 Oct 2014 09:17:20 +0000 (11:17 +0200)]
lxc: fix setmem effect on a running LXC machine
When user calls setmem on a running LXC machine, we do update its cgroup
entry, however we neither update domain's runtime XML nor
we update our internal structures and this patch fixes it.
The API docs generators were broken by the header file
re-organization. Specifically
* html/libvirt-libvirt.html was empty (and should be deleted)
* Makefile.am didn't install html/libvirt-libvirt-*.html
* hvsupport.html was mostly empty
* sitemap.html.in didn't list the new html/*.html files
Pavel Hrdina [Wed, 5 Nov 2014 13:28:57 +0000 (14:28 +0100)]
nwfilter: fix deadlock caused updating network device and nwfilter
Commit 6e5c79a1 tried to fix deadlock between nwfilter{Define,Undefine}
and starting of guest, but this same deadlock exists for
updating/attaching network device to domain.
The deadlock was introduced by removing global QEMU driver lock because
nwfilter was counting on this lock and ensure that all driver locks are
locked inside of nwfilter{Define,Undefine}.
This patch extends usage of virNWFilterReadLockFilterUpdates to prevent
the deadlock for all possible paths in QEMU driver. LXC and UML drivers
still have global lock.
Michal Privoznik [Wed, 12 Nov 2014 17:09:46 +0000 (18:09 +0100)]
qemuPrepareNVRAM: Save domain conf only if domain's persistent
In one of my previous patches (3a3c3780b) I've tried to fix the
problem of nvram path disappearing on a domain that's been
started and shut down again. I fixed this by explicitly saving
domain's config file. However, I did a bit of clumsy without
realizing we have a transient domains for which we don't save the
config file. Hence, any domain using UEFI became persistent.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 12 Nov 2014 09:26:43 +0000 (10:26 +0100)]
qemuxml2argvtest: Run some test only on Linux
As I was reviewing bhyve commits, I've noticed qemuxml2argvtest
failing for some test cases. This is not bug in qemu driver code
rather than being unable to load qemuxml2argvmock on non-Linux
platforms. For instance:
318) QEMU XML-2-ARGV numatune-memnode
... libvirt: error : internal error: NUMA node 0 is unavailable
FAILED
Rather than disabling qemuxml2argvtest on BSD (we do compile qemu
driver there) disable only those test cases which require mocking.
To achieve that goal new DO_TEST_LINUX() macro is introduced which
invokes the test case on Linux only and consume arguments on other
systems.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Introduce a 'managed' attribute to allow libvirt to decide whether to
delete a vHBA vport created via external means such as nodedev-create.
The code currently decides whether to delete the vHBA based solely on
whether the parent was provided at creation time. However, that may not
be the desired action, so rather than delete and force someone to create
another vHBA via an additional nodedev-create allow the configuration of
the storage pool to decide the desired action.
During createVport when libvirt does the VPORT_CREATE, set the managed
value to YES if not already set to indicate to the deleteVport code that
it should delete the vHBA when the pool is destroyed.
If libvirtd is restarted all the memory only state was lost, so for a
persistent storage pool, use the virStoragePoolSaveConfig in order to
write out the managed value.
Because we're now saving the current configuration, we need to be sure
to not save the parent in the output XML if it was undefined at start.
Saving the name would cause future starts to always use the same parent
which is not the expected result when not providing a parent. By not
providing a parent, libvirt is expected to find the best available
vHBA port for each subsequent (re)start.
At deleteVport, use the new managed value to decide whether to execute
the VPORT_DELETE. Since we no longer save the parent in memory or in
XML when provided, if it was not provided, then we have to look it up.
Introduce the ability to save a configuration of a persistent configuration
that may be changed by storage pool backend activity, such as start or stop
Passing a copy of the storage pool adapter to a function just changes the
copy of the fields in the particular function and then when returning to
the caller those changes are discarded. While not yet biting us in the
storage clean-up case, it did cause an issue for the fchost storage pool
startup case, createVport. The issue was at startup, if no parent is found
in the XML, the code will search for the 'best available' parent and then
store that in the in memory copy of the adapter. Of course, in this case
it was a copy, so when returning to the virStorageBackendSCSIStartPool that
change was discarded (or lost) from the pool->def->source.adapter which
meant at shutdown (deleteVport), the code assumed no adapter was passed
and skipped the deletion, leaving the vHBA created by libvirt still defined
requiring an additional stop of a nodedev-destroy to remove.
Adjusted the createVport to take virStoragePoolDefPtr instead of the
adapter copy. Then use the virStoragePoolSourceAdapterPtr when processing.
A future patch will need the 'def' anyway, so this just sets up for that.
The existing code assumed that the configuration of a 'parent' attribute
was correct for the createVport path. As it turns out, that may not be
the case which leads errors during the deleteVport path because the
wwnn/wwpn isn't associated with the parent.
With this change the following is reported:
error: Failed to start pool fc_pool_host3
error: XML error: Parent attribute 'scsi_host4' does not match parent 'scsi_host3' determined for the 'scsi_host16' wwnn/wwpn lookup.
If a 'parent' attribute is provided for the fchost, then at startup
time check to ensure it is a vport capable scsi_host. If the parent
is not vport capable, then disallow the startup. The following is the
expected results:
error: Failed to start pool fc_pool
error: XML error: parent 'scsi_host2' specified for vHBA is not vport capable
Providing an incorrect parent and a correct wwnn/wwpn could lead to
failures at shutdown (deleteVport) where the assumption is the parent
is for the fchost.
NOTE: If the provided wwnn/wwpn doesn't resolve to an existing scsi_host,
then we will be creating one with code (virManageVport) which
assumes the parent is vport capable.
I could have just remove bool supportMaxOptions variable, but
if I had do this, we could not check anymore if the nparams variable is
superior to QEMU_NB_BLOCK_IO_TUNE_PARAM_MAX.
v2: change following this proposal:
http://www.redhat.com/archives/libvir-list/2014-November/msg00379.html
Conrad Meyer [Sat, 8 Nov 2014 16:48:35 +0000 (11:48 -0500)]
bhyve: Add console support for grub-bhyve bootloader
This enables booting interactive GRUB menus (e.g. install CDs) with
libvirt-bhyve.
Caveat: A terminal other than the '--console' option to 'virsh start'
(e.g. 'cu -l /dev/nmdm0B -s 115200') must be used to connect to
grub-bhyve because the bhyve loader path is synchronous and must occur
before the VM actually starts.
Changing the bhyveProcessStart logic around to accommodate '--console'
for interactive loader use seems like a significant project and probably
not worth it, if UEFI/BIOS support for bhyve is "coming soon."
Conrad Meyer [Sat, 8 Nov 2014 16:48:30 +0000 (11:48 -0500)]
bhyve: Support /domain/bootloader configuration for non-FreeBSD guests.
We still default to bhyveloader(1) if no explicit bootloader
configuration is supplied in the domain.
If the /domain/bootloader looks like grub-bhyve and the user doesn't
supply /domain/bootloader_args, we make an intelligent guess and try
chainloading the first partition on the disk (or a CD if one exists,
under the assumption that for a VM a CD is likely an install source).
Caveat: Assumes the HDD boots from the msdos1 partition. I think this is
a pretty reasonable assumption for a VM. (DrvBhyve with Bhyveload
already assumes that the first disk should be booted.)
I've tested both HDD and CD boot and they seem to work.
Ján Tomko [Mon, 10 Nov 2014 15:52:49 +0000 (16:52 +0100)]
Display nicer error message for unsupported chardev hotplug
Use the device type name if we know it instead of its number,
even if we can't hotplug it:
qemuMonitorJSONAttachCharDevCommand:6094 : operation failed: Unsupported
char device type '10'
Directory '$cgroup_path/emulator/' is created in qemuSetupCgroupForEmulator.
But '$cgroup_path/emulator/cpuset.mems' it not set and has a default value
(all nodes, such as 0-1). Then we setup '$cgroup_path/cpuset.mems' to the
nodemask (in this case it's '0') in qemuSetupCgroupPostInit. It must fail.
This patch makes '$cgroup_path/emulator/cpuset.mems' is set before
'$cgroup_path/cpuset.mems'. The action is similar with that in
qemuDomainSetNumaParamsLive.
Wang Rui [Mon, 10 Nov 2014 13:53:18 +0000 (21:53 +0800)]
lxc: don't setup cpuset.mems if memory mode in numatune is not 'strict'
If the memory mode in numatune is not 'strict', we should not setup
cpuset.mems. Before commit 1a7be8c600905aa07ac2d78293336ba8523ad48e
we have checked the memory mode in virDomainNumatuneGetNodeset. This
patch adds the check as before.
Wang Rui [Mon, 10 Nov 2014 13:53:17 +0000 (21:53 +0800)]
qemu: don't setup cpuset.mems if memory mode in numatune is not 'strict'
If the memory mode in numatune is specified as 'preferred' with one node
(such as nodeset='0'), domain's memory is not all in node 0 absolutely.
Assumption that node 0 doesn't have enough memory, memory can be allocated
on node 1 when qemu process startup. Then if we set cpuset.mems to '0',
it may invoke OOM.
Commit 1a7be8c600905aa07ac2d78293336ba8523ad48e changed the former logic of
checking memory mode in virDomainNumatuneGetNodeset. This patch adds the
check as before.
Hao Liu [Tue, 11 Nov 2014 02:12:20 +0000 (10:12 +0800)]
Fix invalid log, misused option types and a typo
This patch fixes the following issues.
1) When an invalid wwn is introduced, libvirt reports
"Malformed wwn: %s". The template won't be replaced.
2) "target" option for dompmsuspend and "xml" option for
save-image-define are required options and should use
VSH_OT_DATA instead of VSH_OT_STRING as an option type.
Coverity found out that commit cd490086 caused a possible NULL pointer
dereference. This is due to the fact, that phyp_driver is NULL at the
time of closing the socket, instead of connection_data, which kept the
socket before the mentioned commit, could not be NULL.
However, internal_socket is still the local socket that can be
closed, even unconditionally, if we initialize it to -1.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Matthias Gatto [Wed, 29 Oct 2014 12:16:03 +0000 (13:16 +0100)]
qemu: Add bps_max and friends QMP suport
Detect if the the qemu binary currently in use support the bps_max option,
If yes add it to the command, if not, just ignore the option.
We don't print error here, because the check for invalide arguments
has alerady been made in qemu_driver.c
Matthias Gatto [Mon, 10 Nov 2014 15:19:09 +0000 (16:19 +0100)]
qemu: Add bps_max and friends qemu driver
Add support for bps_max and friends in the driver part.
In the part checking if a qemu is running, check if the running binary
support bps_max, if not print an error message, if yes add it to
"info" variable
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Matthias Gatto [Wed, 29 Oct 2014 12:16:01 +0000 (13:16 +0100)]
qemu: Add Qemu capability for bps_max and friends
Add the capability to detect if the qemu binary have the capability
to use bps_max and friends
Add a value in the enum virQEMUCapsFlags for the qemu capability.
Set it with virQEMUCapsSet if the binary suport bps_max and they friends.
Matthias Gatto [Wed, 29 Oct 2014 12:16:00 +0000 (13:16 +0100)]
qemu: Modify the structure _virDomainBlockIoTuneInfo.
Modify the structure _virDomainBlockIoTuneInfo to support these the new
options.
Change the initialization of the variable expectedInfo in qemumonitorjsontest.c
to avoid compiling problem.
Add documentation about the new xml options
Matthias Gatto [Wed, 29 Oct 2014 12:15:59 +0000 (13:15 +0100)]
qemu: Add define for the new throttle options
Add defines for the new options total_bytes_sec_max, write_bytes_sec_max,
read_bytes_sec_max, total_iops_sec_max, write_iops_sec_max, read_iops_sec_max,
size_iops_sec.
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Jincheng Miao [Fri, 7 Nov 2014 10:27:00 +0000 (11:27 +0100)]
nodeinfo: report error when failure in nodeSetMemoryParameters
nodeSetMemoryParameters() will call nodeSetMemoryParameterValue()
to set parameters. But it just filter the return code '-2' as
failure. Indeed we should report error when rc is negative.
Prerna Saxena [Mon, 10 Nov 2014 11:52:58 +0000 (17:22 +0530)]
cpu_conf: Allow specification of 'units' for @memory on numa nodes.
CPU numa topology implicitly allows memory specification in 'KiB'.
Enabling this to accept the 'unit' in which memory needs to be specified.
This now allows users to specify memory in units of choice, and
lists the same in 'KiB' -- just like other 'memory' elements in XML.
Prerna Saxena [Mon, 10 Nov 2014 11:52:05 +0000 (17:22 +0530)]
conf: Expose virDomainParseMemory for use outside domain_conf
Commit 01b4de2b9f5ca82 abstracts virDomainParseMemory()
for use by other functions in domain_conf.c
Extend the same for use, for functions outside of this file.
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
produced by virParseVersionString instead of dedicated enums.
Split the complex esxVI_ProductVersion enum into a simpler
esxVI_ProductLine enum and a product version number.
Relax API and product version number checks to accept everything that
is equal or greater than the supported minimum version. VMware ESX
went through 3 major versions and the vSphere API always stayed
backward compatible. This commit assumes that this will also be true
for future VMware ESX versions.
Also reword error messages in esxConnectTo* to say what was expected
and what was found instead (suggested by Richard W.M. Jones).
As reviewing patches upstream it occurred to me, that we have two
functions doing nearly the same: virDomainParseMemory which
expects XML in the following format:
<memory unit='MiB'>1337</memory>
The other function being virDomainHugepagesParseXML expecting the
following format:
<someElement size='1337' unit='MiB'/>
It wouldn't matter to have two functions handle two different
scenarios like this if we could only not copy code that handles
32bit arches around. So this code merges the common parts into
one by inventing new @units_xpath argument to
virDomainParseMemory which allows overriding the default location
of @unit attribute in XML. With this change both scenarios above
can be parsed with virDomainParseMemory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Transform VIR_ERROR into VIR_WARN in detect_scsi_host_caps
If detect_scsi_host_caps reports errors but keeps libvirtd going on
startup, the user is misled by the error messages. Transforming them
into warning still shows the problems, but indicates this is not fatal.
Chen Fan [Fri, 7 Nov 2014 08:54:56 +0000 (16:54 +0800)]
virnuma: add nodeset NULL check in virNumaSetupMemoryPolicy
Introduced by commit c63ef0452b, when nodeset is NULL, validation will
pass in virNumaSetupMemoryPolicy, but virBitmapNextSetBit must ensure
bitmap is not NULL, otherwise that might cause a segmentation fault.
This patch fixes it.
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Remove use of networkPrivateData from netcf driver
The shared netcf driver is stateful and inside the daemon so
there is no need to use the networkPrivateData field to get the
driver handle. Just access the global driver handle directly.
Remove use of networkPrivateData from network driver
The shared network driver is stateful and inside the daemon so
there is no need to use the networkPrivateData field to get the
driver handle. Just access the global driver handle directly.
Many places already directly accessed the global driver handle
in any case, so the code could never work without relying on
this.
Remove use of storagePrivateData from storage driver
The shared storage driver is stateful and inside the daemon so
there is no need to use the storagePrivateData field to get the
driver handle. Just access the global driver handle directly.
projects / libvirt.git / log