Regression introduced in 0.8.5, commit c1564268. The command
'virsh freecell 0' quit working when it changed from an optional
string to an optional integer.
This patch introduces a slight change that specifying an option
twice is now detected as an error. It also changes things so
that a command that has more than 1 required option will not
complain about missing options if one but not all of the options
were given in long format, as in 'virsh vol-create --pool p file',
as well as making positional parsing work for all optional
options (each positional argument is associated with the earliest
option that has not yet been seen by name).
Optional boolean options can appear before required argument
options, because they don't affect positional argument parsing,
and obviously a required boolean option makes no sense.
Technically, this patch renders VSH_OT_STRING and VSH_OT_DATA
redundant; but cleaning that up can be a separate patch.
No command should ever need more than 32 options, right? :)
* tools/virsh.c (vshCmddefGetData, vshCmddefGetOption)
(vshCommandCheckOpts): Alter parameters to use bitmaps.
(vshCmddefOptParse): New function.
(vshCommandParse): Update for better handling of positional
arguments.
(vshCmddefHelp): Allow unit tests to validate options.
The current state of virsh parsing is that:
$ virsh vol-info /path/to/image
$ virsh vol-info --pool default /path/to/image
$ virsh vol-info --pool default --vol /path/to/image
all lookup the volume by path (technically, the last two also attempt
a name lookup within a pool, whereas the first skips that step, but
the end result is the same); meanwhile:
$ virsh vol-info default /path/to/image
complains about unexpected data. Why? Because the --pool option is
optional, so default was parsed as the --vol argument, and
/path/to/image.img doesn't match up with any remaining options that
require an argument. For proof, note that:
$ virsh vol-info default --vol /path/to/image
complains about looking up 'default' - the parser mis-associated both
arguments with --vol. Given the above, the only way to specify pool
is with an explicit "--pool" argument (you can't specify it
positionally). However, named arguments can appear in any order, so:
$ virsh vol-info /path/to/image --pool default
$ virsh vol-info --vol /path/to/image --pool default
have also always worked. Therefore, this patch has no functional
change on vol-info option parsing, but only on 'virsh help vol-info'
synopsis layout. However, it also allows the next patch to 1) enforce
that required options are always first (without this patch, the next
patch would fail the testsuite), and 2) allow the user to omit the
"--pool" argument. That is, the next patch makes it possible to do:
$ virsh vol-info /path/to/image default
which to date was not possible.
* tools/virsh.c (opts_vol_create_from, opts_vol_clone)
(opts_vol_upload, opts_vol_download, opts_vol_delete)
(opts_vol_wipe, opts_vol_info, opts_vol_dumpxml, opts_vol_key)
(opts_vol_path): List optional pool parameter after required
arguments.
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>
