Use the name 'ret' for all phypExec results, to make it easier
to wrap phypExec. Don't allow a possibly NULL ret through printf.
* src/phyp/phyp_driver.c (phypBuildVolume, phypDestroyStoragePool)
(phypBuildStoragePool, phypBuildLpar): Avoid NULL dereference.
(phypInterfaceDestroy): Avoid redundant free.
(phypVolumeLookupByPath, phypVolumeGetPath): Use consistent
naming.
Ever since commit ebc46f, the destroy function built two command
variants but only used one. I went with the variant that matches
the idiom used in the counterpart of phypBuildStoragePool.
* src/phyp/phyp_driver.c (phypDestroyStoragePool): Avoid
clobbering cmd. Fix error message typo.
This warnings come from partly generated code. Therefore, the best
solution is to mark them as potentially being unused using the
ATTRIBUTE_UNUSED macro. This is suggested by the gcc documentation.
Reported by Christophe Fergeau
This patch addresses:
https://bugzilla.redhat.com/show_bug.cgi?id=694382
In order to give each libvirt-created bridge a fixed MAC address,
commit 5754dbd56d, added code to create
a dummy tap device with guaranteed lowest MAC address and attach it to
the bridge. This tap device was given the name "${bridgename}-nic".
However, an interface device name must be IFNAMSIZ (15) characters or
less, so a valid ${bridgename} such as "verylongname123" (15
characters) would lead to an invalid tap device name
("verylongname123-nic" - 19 characters), and that in turn led to a
failure to bring up the network.
The solution is to shorten the part of the original name used to
generate the tap device name. However, simply truncating it is
insufficient, because the last few characters of an interface name are
often a number used to indicate one of a list of several similar
devices (for example, "verylongname123", "verylongname124", etc) and
simple truncation would lead to duplicate names (eg "verlongnam-nic"
and "verylongnam-nic"). So instead we take the first 8 characters of
$bridgename ("verylong" in the example), add on the final 3 bytes
("123"), then add "-nic" (so "verylong123-nic"). Not pretty, but it
is much more likely to generate a unique name, and is reproducible
(unlike, say, a random number).
Due to differences in /proc/cpuinfo the parsing of the cpu data is
different between architectures. On PPC /proc/cpuinfo looks like this:
[original formatting with tabs]
processor : 0
cpu : PPC970MP, altivec supported
clock : 2297.700000MHz
revision : 1.1 (pvr 0044 0101)
processor : 1
cpu : PPC970MP, altivec supported
clock : 2297.700000MHz
revision : 1.1 (pvr 0044 0101)
[..]
timebase : 14318000
platform : pSeries
model : IBM,8844-AC1
machine : CHRP IBM,8844-AC1
The patch adapts the parsing of the data found in /proc/cpuinfo.
/sys/devices/system/cpu/cpuX/topology/physical_package_id also
always returns -1. Check for it on ppc and make it '0' if found negative.
This patch enables the migration of Qemu VMs between hosts of different endianess. I tested this by migrating a i686 VM between a x86 and ppc64 host.
I am converting the 'int's in the VM's state header to uint32_t assuming this doesn't break compatibility with existing deployments other than Linux.
gcc 4.6 warns when a variable is initialized but isn't used afterwards:
vmware/vmware_driver.c:449:18: warning: variable 'vmxPath' set but not used [-Wunused-but-set-variable]
This patch fixes these warnings. There are still 2 offending files:
- vbox_tmpl.c: the variable is used inside an #ifdef and is assigned several
times outside of #ifdef. Fixing the warning would have required wrapping
all the assignment inside #ifdef which hurts readability.
vbox/vbox_tmpl.c: In function 'vboxAttachDrives':
vbox/vbox_tmpl.c:3918:22: warning: variable 'accessMode' set but not used [-Wunused-but-set-variable]
- esx_vi_types.generated.c: the name implies it's generated code and I
didn't want to dive into the code generator
esx/esx_vi_types.generated.c: In function 'esxVI_FileQueryFlags_Free':
esx/esx_vi_types.generated.c:1203:3: warning: variable 'item' set but not used [-Wunused-but-set-variable]
Make: passed
Make check: passed
Make syntax-check: passed
this is the commit to introduce the function to create new character
device definition for the domain as advised by Cole Robinson
<crobinso@redhat.com>.
The function is used on the relevant places and also new tests has
been added.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
This extends the SPICE XML to allow variable compression settings for audio,
images and streaming:
<graphics type='spice' port='5901' tlsPort='-1' autoport='yes'>
<image compression='auto_glz'/>
<jpeg compression='auto'/>
<zlib compression='auto'/>
<playback compression='on'/>
</graphics>
All new elements are optional.
This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=696660
While starting a network, if brSetForwardDelay() fails, we go to err1
where we want to access macTapIfName variable which was just
VIR_FREE'd a few lines above. Instead, keep macTapIfName until we are
certain of success.
The methods qemuDomain{Get,Set}{Memory,Blkio,Scheduler}Parameters
all forgot to do a check on virDomainIsActive(), resulting in bogus
error messages from later parts of their impl
* src/qemu/qemu_driver.c: Add missing checks on virDomainIsActive()
sizeof(domain->name) is the wrong thing. Instead of using strdup here
rewrite escape_specialcharacters to allocate the buffer itself.
Add a contains_specialcharacters to be used in phypOpen, as phypOpen is
not interested in the escaped version.
Don't pre-allocate 4kb per key, make phypVolumeGetKey allocate the memory.
Make phypBuildVolume return the volume key instead of using pre-allocated
memory to store it.
Also fix a memory leak in phypVolumeLookupByName when phypVolumeGetKey
fails. Fix another memory leak in phypVolumeLookupByPath in the success
path. Fix phypVolumeGetXMLDesc leaking voldef.key.
Move the virInterfacePtr declaration to the top of the
function to avoid jump uninitialized variable warnings
* src/phyp/phyp_driver.c: Fix var declaration
The daemon dispatcher code had an obsolete macro
#define REMOTE_DEBUG(fmt, ...) VIR_DEBUG(fmt, __VA_ARGS__)
This can be trivially removed
* daemon/remote.c: s/REMOTE_DEBUG/VIR_DEBUG/
Many functions did not check for whether a connection was
open. Replace the macro which obscures control flow, with
explicit checks, and ensure all dispatcher code has checks.
* daemon/remote.c: Add connection checks
A lot of code in libvirtd's dispatcher used the style
dom = get_nonnull_domain (conn, args->dom);
Instead of the normal libvirt style
dom = get_nonnull_domain(conn, args->dom);
* daemon/remote.c: Remove all whitelist before function brackets
This is the implementation of the previous patch now using virInterface*
API. Ended up this patch got much more simpler, smaller and easier to
review. Here is some details:
* MAC size and interface name are fixed due to specifications on HMC,
both are created automatically and CAN'T be specified from user. They
have the following format:
* MAC: 122980003002
* Interface name: U9124.720.067BE8B-V3-C0
* I did replaced all the |grep|sed following the comments Eric Blake
did on the last patch.
* According to my last email, It's not possible to create a network
interface without assigning it to a specific lpar. Then, I am using
this very minimalistic XML file for testing:
<interface type='ethernet' name='LPAR01'>
</interface>
In this file I am using "name" as the lpar name which I am going to
assign the new network interface. I couldn't find a better way to
refer to it. Comments are welcome.
* Regarding the fact I am sleeping one second waiting for the HMC to
complete creation of the interface, I don't have means to check
if the whole process is done. All I do is execute a command, wait
until is complete (which is not enough in this case) check
the return and the exit status. The process of actually creating
a networking interface seems to take a little longer than just the
return of the ssh control.
In qemuDomainObjBeginJobWithDriver, when virCondWaitUntil timeouts,
the function tries to call qemuDriverLock with virDomainObj locked,
this causes the dead-lock problem. This patch fixes this.
Commit 9677cd33ee made it possible to
remove current entry when iterating through all hash entries. However,
it didn't properly handle a special case of removing first entry
assigned to a given key which contains several entries in its collision
list.
Based on a smaller patch developed by Moritoshi Oshiro:
https://bugzilla.redhat.com/show_bug.cgi?id=693963
* tools/virsh.pod (freecell): Mention all, and clarify that
optional cellno requires --cellno.
This patch adds the new options (--live, --config, and --current) to
"virsh setmaxmem" command. The behavior of above options is the same
as that of "virsh setmem". When the --config option is specified, a
modification is effective for the persistent domain, while the --live
option is specified, a modification is effective for an active
domain. The --current option is specified, it affects a current
domain.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
This patch implements the code to support virDomainSetMaxMemory API,
and to support VIR_DOMAIN_MEM_MAXIMUM flag in qemudDomainSetMemoryFlags function.
As a result, we can change the maximum memory size of inactive QEMU guests.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Move "returns" keyword from beginning of API doc lines
when it does not describe return values.
Maybe the API doc extractor could be changed to look for
"returns: " to avoid such confusion.
Aargh; commit 8ae5dfd still didn't fix the mingw problem, because
gnulib defined O_NONBLOCK to 0 for just mingw. I've now fixed
that in gnulib, but we need the latest pipe2 for libvirt to work.
* .gnulib: Update to latest, for pipe2 fixes.
Commit 02c39a2 introduced a mingw build regression, due to a
regression in gnulib's areadlink module:
../../../gnulib/lib/careadlinkat.c: In function 'careadlinkat':
../../../gnulib/lib/careadlinkat.c:143:39: error: 'const struct allocator' has no member named 'malloc'
* .gnulib: Update to latest, for careadlinkat fix.
