Remove the optional option "group", as cmdHelp should accepts
only one option ("virsh help" supports both command and command
group now, and user rarely uses the options, so it doesn't matter
much for it being longer, :-)
* tools/virsh.c
This patch adds a mode_t parameter to virFileWriteStr().
If mode is different from 0, virFileWriteStr() will try
to create the file if it doesn't exist.
* src/util/util.h (virFileWriteStr): Alter signature.
* src/util/util.c (virFileWriteStr): Allow file creation.
* src/network/bridge_driver.c (networkEnableIpForwarding)
(networkDisableIPV6): Adjust clients.
* src/node_device/node_device_driver.c
(nodeDeviceVportCreateDelete): Likewise.
* src/util/cgroup.c (virCgroupSetValueStr): Likewise.
* src/util/pci.c (pciBindDeviceToStub, pciUnBindDeviceFromStub):
Likewise.
* tools/virsh.c (find-storage-pool-sources-as and find-storage-pool-sources
should't be in command group "Domain Management", move them to group
"Storage Pool".
* src/qemu/qemu_conf.c (qemudExtractVersionInfo): Check for file
before executing it here, rather than in callers.
(qemudBuildCommandLine): Rewrite with virCommand.
* src/qemu/qemu_conf.h (qemudBuildCommandLine): Update signature.
* src/qemu/qemu_driver.c (qemuAssignPCIAddresses)
(qemudStartVMDaemon, qemuDomainXMLToNative): Adjust callers.
This proof of concept shows how two existing uses of virExec
and virRun can be ported to the new virCommand APIs, and how
much simpler the code becomes
This introduces a new set of APIs in src/util/command.h
to use for invoking commands. This is intended to replace
all current usage of virRun and virExec variants, with a
more flexible and less error prone API.
* src/util/command.c: New file.
* src/util/command.h: New header.
* src/Makefile.am (UTIL_SOURCES): Build it.
* src/libvirt_private.syms: Export symbols internally.
* tests/commandtest.c: New test.
* tests/Makefile.am (check_PROGRAMS): Run it.
* tests/commandhelper.c: Auxiliary program.
* tests/commanddata/test2.log - test15.log: New expected outputs.
* cfg.mk (useless_free_options): Add virCommandFree.
(msg_gen_function): Add virCommandError.
* po/POTFILES.in: New translation.
* .x-sc_avoid_write: Add exemption.
* tests/.gitignore: Ignore new built file.
This patch allows for using custom scripts instead of /usr/bin/qemu
emulator in domain XML. To do so, one would specify relative path to the
custom script in <emulator/>. The path needs to be relative to
qemuxml2argvdata directory and it will be transparently made absolute in
runtime. The expected command line needs to contain the exact relative
path as was used in domain XML.
The problem is RelaxNG schema for domain XML only allows for absolute
path within <emulator/>. To workaround it, an extra '/' must be added at
the beginning of the path. That is, instead of "./qemu.sh" or
"../emulator/qemu.sh" one would use "/./qemu.sh" or
"/../emulator/qemu.sh". The extra slash is removed before further
processing. I don't like this workaround, it's very ugly but it's the
best option I was able to come up with. Relaxing domain XML schema is
not an option IMO.
* tools/virsh.c (virsh shouldn't use 'phy' as the disk driver if
user doesn't specify "--driver", it causes bugs, as not all of
hypervisor driver supports 'phy', and actually hypervisor should
known the correct default disk driver and subdriver, so remove it)
* src/qemu/qemu_driver.c (though MACROS QEMU_VNC_PORT_MAX, and
QEMU_VNC_PORT_MIN are defined at the beginning, numbers (65535, 5900)
are still used, replace them)
The arguments passed to the thread function must be allocated on
the heap, rather than the stack, since it is possible for the
spawning thread to continue before the new thread runs at all.
In such a case, it is possible that the area of stack where the
thread args were stored is overwritten.
* src/util/threads-pthread.c, src/util/threads-win32.c: Allocate
thread arguments on the heap
As virsh help supports both command and command group now,
update "cmdHelp" to print consite help, (this patch is
increment of "7829052757953023b0826e0293ffe18ed4ab89e9").
And also remove redundant empty line in "vshUsage".
* tools/virsh.c
Use macvtap specific functions depending on WITH_MACVTAP.
Use #if instead of #ifdef to check for WITH_MACVTAP, because
WITH_MACVTAP is always defined with value 0 or 1.
Also export virVMOperationType{To|From}String unconditional,
because they are used unconditional in the domain config code.
The output was previously:
-c | --connect <uri> hypervisor connection URI
-r | --readonly connect readonly
-d | --debug <num> debug level [0-5]
-h | --help this help
-q | --quiet quiet mode
-t | --timing print timing information
-l | --log <file> output logging to file
-v | --version[=short] program version
-V | --version=long version and full options
(note the blank line between the --version types)
This patch removes the extra blank line.
When dumping a domain, it's reasonable to save dump-file in raw format
if dump format is misconfigured or the corresponding compress program
is not available rather then fail dumping.
Change the virsh help out. The new output of "virsh help" and
"virsh --help" will be like:
Secret (help keyword 'secret'):
secret-define define or modify a secret from an XML file
secret-dumpxml secret attributes in XML
secret-set-value set a secret value
secret-get-value Output a secret value
secret-undefine undefine a secret
secret-list list secrets
Snapshot (help keyword 'snapshot'):
snapshot-create Create a snapshot
snapshot-current Get the current snapshot
snapshot-delete Delete a domain snapshot
snapshot-dumpxml Dump XML for a domain snapshot
snapshot-list List snapshots for a domain
snapshot-revert Revert a domain to a snapshot
Also support output help information of specified command group, e.g.
% ./tools/virsh help "Network Filter"
Network Filter (help keyword 'filter'):
nwfilter-define define or update a network filter from an XML file
nwfilter-undefine undefine a network filter
nwfilter-dumpxml network filter information in XML
nwfilter-list list network filters
nwfilter-edit edit XML configuration for a network filter
Each group has a help keyword, e.g.
% ./tools/virsh help filter
Network Filter (help keyword 'filter'):
nwfilter-define define or update a network filter from an XML file
nwfilter-undefine undefine a network filter
nwfilter-dumpxml network filter information in XML
nwfilter-list list network filters
nwfilter-edit edit XML configuration for a network filter
* tools/virsh.c:
- introduce new struct "vshCmdGrp" and macros to define the groups.
- split previous array "commands" into small arrays which are orgnized
by group
- changed some functions, e.g. "vshCmdDefSearch"
- Added new functions, e.g. "vshCmdGrpSearch"
- commands of each group are in "alphabetical order" now.
- command groups are in "alphabetical order" now.
- the commands are categorized with reference of
http://wiki.libvirt.org/page/VirshHelpV2 (by Justin)
- the modifications doesn't affect tests
* TODO:
- doc
This patch introduces the usage of the pre-associate state of the IEEE 802.1Qbg standard on incoming VM migration on the target host. It is in response to bugzilla entry 632750.
https://bugzilla.redhat.com/show_bug.cgi?id=632750
For being able to differentiate the exact reason as to why a macvtap device is being created, either due to a VM creation or an incoming VM migration, I needed to pass that reason as a parameter from wherever qemudStartVMDaemon is being called in order to determine whether to send an ASSOCIATE (VM creation) or a PRE-ASSOCIATE (incoming VM migration) towards lldpad.
I am also fixing a problem with the virsh domainxml-to-native call on the way.
Gerhard successfully tested the patch with a recent blade network 802.1Qbg-compliant switch.
The patch should not have any side-effects on the 802.1Qbh support in libvirt, but Roopa (cc'ed) may want to verify this.
We currently use the next free veid although there's one given in the
domain xml. This currently breaks defining new domains since vmdef->name
and veid don't match leading to the following error later on:
error: Failed to define domain from 110.xml
error: internal error Could not set UUID
Since silently ignoring vmdef->name is not nice respect it instead. We
avoid veid collisions in the upper levels already.
This reverts commit
Log all errors at level INFO to stop polluting syslog
04bd0360f3.
and makes virRaiseErrorFull() log errors at debug priority
when called from inside libvirtd. This stops libvirtd from
polluting it's own log with client errors at error priority
that'll be reported and logged on the client side anyway.
When we set migrate_speed by json, we receive the following
error message:
libvirtError: internal error unable to execute QEMU command
'migrate_set_speed': Invalid parameter type, expected: number
The reason is that: the arguments of migrate_set_speed
by json is json number, not json string.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
The dominfo.py example script has a bogus check for /proc/xen
existing. The default connection cannot be assumed to be Xen
any more
* examples/python/dominfo.py: Remove check for Xen
The nodeinfo structure includes
nodes : the number of NUMA cell, 1 for uniform mem access
sockets : number of CPU socket per node
cores : number of core per socket
threads : number of threads per core
which does not work well for NUMA topologies where each node does not
consist of integral number of CPU sockets.
We also have VIR_NODEINFO_MAXCPUS macro in public libvirt.h which
computes maximum number of CPUs as (nodes * sockets * cores * threads).
As a result, we can't just change sockets to report total number of
sockets instead of sockets per node. This would probably be the easiest
since I doubt anyone is using the field directly. But because of the
macro, some apps might be using sockets indirectly.
This patch leaves sockets to be the number of CPU sockets per node (and
fixes qemu driver to comply with this) on machines where sockets can be
divided by nodes. If we can't divide sockets by nodes, we behave as if
there was just one NUMA node containing all sockets. Apps interested in
NUMA should consult capabilities XML, which is what they probably do
anyway.
This way, the only case in which apps that care about NUMA may break is
on machines with funky NUMA topology. And there is a chance libvirt
wasn't able to start any guests on those machines anyway (although it
depends on the topology, total number of CPUs and kernel version).
Nothing changes at all for apps that don't care about NUMA.
