This patch strips reusable part of qemuDomainUpdateDeviceFlags()
and consolidate it to qemuDomainModifyDeviceFlags().
No functional changes.
* src/qemu/qemu_driver.c
(qemuDomainChangeDiskMediaLive) : pulled out code for updating disks.
(qemuDomainUpdateDeviceLive) : core of UpdateDevice, extracted from
UpdateDeviceFlags()
(qemuDomainModifyDeviceFlags): add support for updating device in live domain.
(qemuDomainUpdateDeviceFlags): reworked as a wrapper function of
qemuDomainModifyDeviceFlags()
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
clean up At(De)tachDeviceFlags() for consolidation.
qemuDomainAttachDeviceFlags()/qemuDomainDetachFlags()/
qemuDomainUpdateDeviceFlags() has similar logics and copied codes.
This patch series tries to unify them to use shared code when it can.
At first, clean up At(De)tachDeviceFlags() and devide it into functions.
By this, this patch pulls out shared components between functions.
Based on patch series by Eric Blake, I added some modification as
switch-case with QEMU_DEVICE_ATTACH, QEMU_DEVICE_DETACH, QEMU_DEVICE_UPDATE
* src/qemu/qemu_driver.c
(qemuDomainAt(De)tachDeviceFlags) : pulled out to qemuDomainModifyDeviceFlags()
(qemuDomainModifyDeviceFlags) : implements generic code for modifying domain.
(qemuDomainAt(De)tachDeviceFlagsLive) : code for at(de)taching devices to
domain in line. no changes in logic from old code.
(qemuDomainAt(De)tachDeviceDiskLive) : for at(de)taching Disks.
(qemuDomainAt(De)tachDeviceControllerLive) : for at(de)taching Controllers
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Centralize device modification in the more flexible APIs, to allow future
honoring of additional flags. Explicitly reject the
VIR_DOMAIN_DEVICE_MODIFY_FORCE flag on attach/detach.
Based on Eric Blake<eblake@redhat.com>'s work.
* src/qemu/qemu_driver.c
(qemudDomainAttachDevice)(qemudDomainAttachDeviceFlags): Swap bodies,rename...
(qemudDomainDetachDevice, qemudDomainDetachDeviceFlags): Likewise.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Up to now we missed parser for cpuinfo on x390(x) machines. Those machines
have only 1 thread, core, socket. What is missing is information about
CPU frequency.
The two ends of the pipe used for feeding QEMU tunnelled
migration data were interchanged, so QEMU got given the
"write" end instead of the "read" end.
The qemuMigrationPrepareTunnel method was also immediately
closing the "write" end of the pipe, so the stream failed
to actually write anything.
* src/qemu/qemu_migration.c: Swap tunnelled migration
pipe FDs & don't close pipe given to stream
ARRAY_CARDINALITY is typed as size_t, not long; this matters on 32-bit
platforms:
hashtest.c: In function 'testHashRemoveForEach':
hashtest.c:114: error: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int' [-Wformat]
* tests/hashtest.c (testHashRemoveForEach): Use correct format.
Gnulib already guarantees <stdbool.h>, so it is easier to just
use the standardized spellings.
* tools/virsh.c (vshCmdDef): Change callback to return real bool.
(__vshControl): Change several fields to bool.
(vshCommandOptBool): Change return type.
All callers updated.
* tools/Makefile.am (virsh-net-edit.c, virsh-pool-edit.c):
Likewise.
Here is a new version of this patch:
https://www.redhat.com/archives/libvir-list/2011-April/msg00337.html
v2:
- store the cputune info for the whole runtime of the domain
- remove cputune info when domain is destroyed
The nodeGetInfo code had to be moved into a helper
function to reuse it without a virConnectPtr.
Rather than copying and pasting lots of code, factor it into a
single helper function.
This commit adds a warning if tighter integer parsing would fail
due to any stray bytes after the number, but should not change
any behavior other than the bug fix for phypNumDomainsGeneric
looking only at numeric lines.
* src/phyp/phyp_driver.c (phypExecInt): New function.
(phypGetVIOSPartitionID, phypNumDomainsGeneric, phypGetLparID)
(phypGetLparMem, phypGetLparCPUGeneric, phypGetRemoteSlot)
(phypGetVIOSNextSlotNumber, phypAttachDevice)
(phypGetStoragePoolSize, phypStoragePoolNumOfVolumes)
(phypNumOfStoragePools, phypInterfaceDestroy)
(phypInterfaceDefineXML, phypInterfaceLookupByName)
(phypInterfaceIsActive, phypNumOfInterfaces): Use it.
(phypNumDomainsGeneric): Correctly find numeric line.
This last minute addition caused a build failure
cc1: warnings being treated as errors
qemu/qemu_process.c: In function 'qemuProcessHandleWatchdog':
qemu/qemu_process.c:436:34: error: ignoring return value of 'virDomainObjUnref', declared with attribute warn_unused_result [-Wunused-result]
make[3]: *** [libvirt_driver_qemu_la-qemu_process.lo] Error 1
Replace some occurrances of
virDomainPtr domain;
virNetworkPtr network;
With
virDomainPtr dom;
virNetworkPtr net;
* daemon/remote.c: Fix variable naming to follow standard
Replace cases of
type = virConnectGetType(conn);
if (type == NULL)
goto cleanup;
With
if (!(type = virConnectGetType(conn)))
goto cleanup;
* daemon/remote.c: Write error checks in compat form
Replace all occurrances of
if (....) {
goto cleanup;
}
With
if (.....)
goto cleanup;
to save one line of code
* daemon/remote.c: Remove curly braces on single line conditionals
The libvirt APIs reserve any negative value for indicating an
error. Thus checks
if (virXXXX() == -1)
Should instead be
if (virXXXX() < 0)
* daemon/remote.c: s/ == -1/ < 0/
The dispatcher functions have numerous places where they
return to the caller. This leads to duplicated cleanup
code, often resulting in memory leaks. It makes it harder
to ensure that errors are dispatched before freeing objects,
which may overwrite the original error.
The standard pattern is now
remoteDispatchXXX(...) {
int rv = -1;
....
if (XXX < 0)
goto cleanup;
...
if (XXXX < 0)
goto cleanup;
...
rv = 0;
cleanup:
if (rv < 0)
remoteDispatchError(rerr);
...free all other stuff..
return rv;
}
* daemon/remote.c: Centralize all cleanup paths
* daemon/stream.c: s/remoteDispatchConnError/remoteDispatchError/
* daemon/dispatch.c, daemon/dispatch.h: Replace
remoteDispatchConnError with remoteDispatchError
removing unused virConnectPtr
To install it, disable libvirtd sysv initscript:
chkconfig libvirtd off
service libvirtd stop
and enable libvirtd upstart job:
cp /usr/share/doc/libvirt-*/libvirtd.upstart \
/etc/init/libvirtd.conf
initctl reload-configuration
initctl start libvirtd
Test:
initctl status libvirtd
libvirtd start/running, process 3929
killall -9 libvirtd
initctl status libvirtd
libvirtd start/running, process 4047
I looked into the possibility to use the upstart script from Ubuntu or
at least getting inspiration from it but that's not possible. "expect
daemon" is a nice thing but it only works if the process is defined with
exec stanza instead of script ... no script. Unfortunately, with exec
stanza environment variables can only be set within upstart script
(i.e., configuration in /etc/sysconfig/libvirtd can't work). Hence, we
need to use script stanza, source sysconfig, and execute libvirtd
without --daemon. For similar reasons we can't use limit stanza and need
to handle DAEMON_COREFILE_LIMIT in job's script.
This patch does the following two things:
1. hold an extra reference while handling watchdog event
If the domain is not persistent, and qemu quits unexpectedly before
calling processWatchdogEvent(), vm will be freed and the function
processWatchdogEvent() will be dangerous.
2. unlock qemu driver and vm before returning from processWatchdogEvent()
When the function processWatchdogEvent() failed, we only free wdEvent,
but forget to unlock qemu driver and vm, free dumpfile.
We do not lock qemu_driver when calling virThreadPoolNew(). If it failed,
we will unlock qemu_driver. It is dangerous.
We may use this pool during auto starting domains. So we must create it before
calling qemuAutostartDomains(). Otherwise, libvirtd will crash.
Also mark error messages in block_stats.c for translation, add the
new macro to the msg_gen functions in cfg.mk and add block_stats.c
to po/POTFILES.in
commit d4601696 introduces two more generated files: esx_vi.generated.h
and esx_vi.generated.h. But we do not include them into dist file.
It will break building if using dist file to build.
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.
