When the remote client receives end of file on the stream
it never invokes the stream callback. Applications relying
on async event driven I/O will thus never see the EOF
condition on the stream
* src/rpc/virnetclient.c, src/rpc/virnetclientstream.c:
Ensure EOF is dispatched
The client stream object can be used independently of the
virNetClientPtr object, so must have full locking of its
own and not rely on any caller.
* src/remote/remote_driver.c: Remove locking around stream
callback
* src/rpc/virnetclientstream.c: Add locking to all APIs
and callbacks
When a filter steals an RPC message, that message must
not be freed, except by the filter code itself
* src/rpc/virnetserverclient.c: Don't free stolen RPC
messages
Improve log messages issued when encountering a bogus
message length to include the actual length and the
limit violated
* src/rpc/virnetmessage.c: Improve log messages
On stream completion it is neccessary to send back a
message with an empty payload. The message header was
not being filled out correctly, since we were not writing
any payload. Add a method for encoding an empty payload
which updates the message headers correctly.
* src/rpc/virnetmessage.c, src/rpc/virnetmessage.h: Add
a virNetMessageEncodePayloadEmpty method
* src/rpc/virnetserverprogram.c: Write empty payload on
stream completion
The RPC client treats failure to register a socket watch
as non-fatal, since we do not mandate that a libvirt client
application provide an event loop implementation. It is
thus inappropriate to a log a message at VIR_LOG_WARN
* src/rpc/virnetsocket.c: Lower logging level
If a streams error is raised, virNetClientIOEventLoop
returns 0, but an error is set. Check for this and
propagate it if present
* src/rpc/virnetclient.c: Propagate streams error
If a callback being invoked from a stream issues a virStreamAbort
operation, the stream data will be free'd but the callback will
then still try to use this. Delay free'ing of the stream data when
a callback is dispatching
* src/fdstream.c: Delay stream free when callback is active
Although we create a temporary file, it is owned by root:root and have
rights 0600. In case qemu does not run under root, it is unable to write
to that file and thus we transfer 0B sized file.
addnhostsSave and hostsfileSave expect < 0 return value on error from
addnhostsWrite and hostsfileWrite but then pass err instead of -err
to virReportSystemError that expects an errno value.
Also addnhostsWrite returns -ENOMEM and errno, change this to -errno.
addnhostsWrite and hostsfileWrite tried to unlink the tempfile after
renaming it, making both fail on the final step. Remove the unnecessary
unlink calls.
networkSaveDnsmasqHostsfile was added in 8fa9c22142 (Apr 2010).
It has a force flag. If the dnsmasq hostsfile already exists force
needs to be true to overwrite it. networkBuildDnsmasqArgv sets force
to false, networkDefine sets it to true. This results in the
hostsfile being written only in networkDefine in the common case.
If no error occurred networkSaveDnsmasqHostsfile returns true and
networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq
command line.
networkSaveDnsmasqHostsfile was changed in 89ae9849f7 (24 Jun 2011)
to return a new dnsmasqContext instead of reusing one. This change broke
the logic of the force flag as now networkSaveDnsmasqHostsfile returns
NULL on error, but the early return -- if force was not set and the
hostsfile exists -- returns 0. This turned the early return in an error
case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option
anymore if the hostsfile already exists. It did because networkDefine
created the hostsfile already.
Then 9d4e2845d4 fixed the return 0 case in networkSaveDnsmasqHostsfile
but didn't apply the force option correctly to the new addnhosts file.
Now force doesn't control an early return anymore, but influences the
handling of the hostsfile context creation and dnsmasqSave is always
called now. This commit also added test cases that reveal several
problems. First, the tests now calls functions that try to write the
dnsmasq config files to disk. If someone runs this tests as root this
might overwrite actively used dnsmasq config files, this is a no-go. Also
the tests depend on configure --localstatedir, this needs to be fixed as
well, because it makes the tests fail when localstatedir is different
from /var.
This patch does several things to fix this:
1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv
to the caller to separate the command line generation from the config
file writing. This makes the command line generation testable without the
risk of interfering with system files, because the tests just don't call
dnsmasqSave.
2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag
useless as the saving happens somewhere else now. This fixes the wrong
usage of the force flag in combination with then newly added addnhosts
file by removing the force flag.
3) Adapt the wrong test cases to the correct behavior, by adding the
missing --dhcp-hostsfile option. Both affected tests contain DHCP host
elements but missed the necessary --dhcp-hostsfile option.
4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile,
because it doesn't save the dnsmasqContext anymore.
5) Move all directory creations in dnsmasq context handling code from
the *New functions to dnsmasqSave to avoid directory creations in system
paths in the test cases.
6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext
anymore the test case can create one with the localstatedir that is
expected by the tests instead of the configure --localstatedir given one.
Version 1.3 of <sys/sdt.h> uses this macro
#define STAP_CAST(t) (size_t)t
that breaks like this if t is a function
remote.c:1775: error: cast from function call of type 'const char *'
to non-matching type 'long unsigned int' [-Wbad-function-cast]
For that to work it should probably look like this
#define STAP_CAST(t) ((size_t)(t))
In systemtap 1.4 this was completely rewritten.
Anyway, before commit df0b57a95a t was always a variable, but now
also a function is used here, namely virNetSASLSessionGetIdentity.
Use an intermediate variable to avoid this problem.
./autobuild.sh died on several messages resembling:
../../src/rpc/virnetsocket.c: In function 'virNetSocketNewListenTCP':
../../src/rpc/virnetsocket.c:231:9: error: implicit declaration of function 'bind_used_without_requesting_gnulib_module_bind' [-Wimplicit-function-declaration]
../../src/rpc/virnetsocket.c:231:9: error: nested extern declaration of 'bind_used_without_requesting_gnulib_module_bind' [-Wnested-externs]
Basically, gnulib socket fds are not safe to pass to mingw socket
functions unless we pull in those gnulib modules.
* bootstrap.conf (gnulib_modules): Add modules to handle socket
functions on mingw.
Detected by gcc -O2, introduced in commit 532ce9c2. If dmidecode
outputs a field unrecognized by the parsers, then the code would
dereference an uninitialized eol variable.
* src/util/sysinfo.c (virSysinfoParseBIOS)
(virSysinfoParseSystem, virSysinfoParseProcessor)
(virSysinfoParseMemory): Avoid uninitialized variable.
The last patch was incomplete. The translated strings merely
moved between generated file names, rather than disappearing.
* cfg.mk (generated_files): Update generated file names.
* po/POTFILES.in: Add remote_dispatch.h
Detected by gcc -O2:
remote/remote_driver.c: In function 'doRemoteOpen':
remote/remote_driver.c:2753:26: error: 'sasl' may be used uninitialized in this function [-Werror=uninitialized]
* src/remote/remote_driver.c (remoteAuthSASL): Initialize sasl.
Add a page which documents how to configure lock managers,
focusing on use of sanlock with the QEMU/KVM driver
* docs/locking.html.in: Docs about lock managers
* docs/sitemap.html.in: Add lock manager config to
the deployment section
The current sanlock plugin requires a central management
application to manually add <lease> elements to each guest,
to protect resources that are assigned to it (eg writable
disks). This makes the sanlock plugin useless for usage
in more ad hoc deployment environments where there is no
central authority to associate disks with leases.
This patch adds a mode where the sanlock plugin will
automatically create leases for each assigned read-write
disk, using a md5 checksum of the fully qualified disk
path. This can work pretty well if guests are using
stable disk paths for block devices eg /dev/disk/by-path/XXXX
symlinks, or if all hosts have NFS volumes mounted in
a consistent pattern.
The plugin will create one lockspace for managing disks
with filename /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__.
For each VM disks, there will be another file to hold
a lease /var/lib/libvirt/sanlock/5903e5d25e087e60a20fe4566fab41fd
Each VM disk lease is usually 1 MB in size. The script
virt-sanlock-cleanup should be run periodically to remove
unused lease files from the lockspace directory.
To make use of this capability the admin will need to do
several tasks:
- Mount an NFS volume (or other shared filesystem)
on /var/lib/libvirt/sanlock
- Configure 'host_id' in /etc/libvirt/qemu-sanlock.conf
with a unique value for each host with the same NFS
mount
- Toggle the 'auto_disk_leases' parameter in qemu-sanlock.conf
Technically the first step can be skipped, in which case
sanlock will only protect against 2 vms on the same host
using the same disk (or the same VM being started twice
due to error by libvirt).
* src/locking/libvirt_sanlock.aug,
src/locking/sanlock.conf,
src/locking/test_libvirt_sanlock.aug: Add config params
for configuring auto lease setup
* libvirt.spec.in: Add virt-sanlock-cleanup program, man
page
* tools/virt-sanlock-cleanup.in: Script to purge unused
disk resource lease files
Introduce a configuration file with a single parameter
'require_lease_for_disks', which is used to decide whether
it is allowed to start a guest which has read/write disks,
but without any leases.
* libvirt.spec.in: Add sanlock config file and augeas
lens
* src/Makefile.am: Install sanlock config file and
augeas lens
* src/locking/libvirt_sanlock.aug: Augeas master lens
* src/locking/test_libvirt_sanlock.aug: Augeas test file
* src/locking/sanlock.conf: Example sanlock config
* src/locking/lock_driver_sanlock.c: Wire up loading
of configuration file
Allow a 'configFile' parameter to be passed into the lock
drivers to provide configuration. Wire up the QEMU driver
to pass in file names '/etc/libvirt/qemu-$NAME.conf
eg qemu-sanlock.conf
* src/locking/lock_driver.h, src/locking/lock_driver_nop.c,
src/locking/lock_driver_sanlock.c, src/locking/lock_manager.c,
src/locking/lock_manager.h: Add configFile parameter
* src/qemu/qemu_conf.c: Pass in configuration file path to
lock driver plugins
If a domain name is defined for a network, add the --expand-hosts
option to the dnsmasq commandline. This results in the domain being
added to any hostname that is defined in a dns <host> element and
contains no '.' characters (i.e. it is an "unqualified"
hostname). Since PTR records are automatically created for any name
defined in <host>, the result of a PTR request will change from the
unqualified name to the qualified name.
This also has the same effect on any hostnames that dnsmasq reads
from the host's /etc/hosts file.
(In the case of guest hostnames that were learned by dnsmasq via DHCP
requests, they were already getting the domain name added on, even
without --expand-hosts).
The standard remote protocol for libvirtd no longer needs to
include definitions of the generic message header/error structs
or status codes. This is all defined in the generic RPC protocol
* src/remote/remote_protocol.x: Remove all RPC message definitions
* src/remote/remote_protocol.h, src/remote/remote_protocol.c:
Re-generate
* daemon/remote_generate_stubs.pl: Delete obsolete script
This guts the libvirtd daemon, removing all its networking and
RPC handling code. Instead it calls out to the new virServerPtr
APIs for all its RPC & networking work
As a fallout all libvirtd daemon error reporting now takes place
via the normal internal error reporting APIs. There is no need
to call separate error reporting APIs in RPC code, nor should
code use VIR_WARN/VIR_ERROR for reporting fatal problems anymore.
* daemon/qemu_dispatch_*.h, daemon/remote_dispatch_*.h: Remove
old generated dispatcher code
* daemon/qemu_dispatch.h, daemon/remote_dispatch.h: New dispatch
code
* daemon/dispatch.c, daemon/dispatch.h: Remove obsoleted code
* daemon/remote.c, daemon/remote.h: Rewrite for new dispatch
APIs
* daemon/libvirtd.c, daemon/libvirtd.h: Remove all networking
code
* daemon/stream.c, daemon/stream.h: Update for new APIs
* daemon/Makefile.am: Link to libvirt-net-rpc-server.la
This guts the current remote driver, removing all its networking
handling code. Instead it calls out to the new virClientPtr and
virClientProgramPtr APIs for all RPC & networking work.
* src/Makefile.am: Link remote driver with generic RPC code
* src/remote/remote_driver.c: Gut code, replacing with RPC
API calls
* src/rpc/gendispatch.pl: Update for changes in the way
streams are handled
The libvirt sanlock plugin is intentionally leaking a file
descriptor to QEMU. To enable QEMU to use this FD under
SELinux, it must be labelled correctly. We dont want to use
the svirt_image_t for this, since QEMU must not be allowed
to actually use the FD. So instead we label it with svirt_t
using virSecurityManagerSetProcessFDLabel
* src/locking/domain_lock.c, src/locking/domain_lock.h,
src/locking/lock_driver.h, src/locking/lock_driver_nop.c,
src/locking/lock_driver_sanlock.c, src/locking/lock_manager.c,
src/locking/lock_manager.h: Optionally pass an FD back to
the hypervisor for security driver labelling
* src/qemu/qemu_process.c: label the lock manager plugin
FD with the process label
Add a new security driver method for labelling an FD with
the process label, rather than the image label
* src/libvirt_private.syms, src/security/security_apparmor.c,
src/security/security_dac.c, src/security/security_driver.h,
src/security/security_manager.c, src/security/security_manager.h,
src/security/security_selinux.c, src/security/security_stack.c:
Add virSecurityManagerSetProcessFDLabel & impl
The virSecurityManagerSetFDLabel method is used to label
file descriptors associated with disk images. There will
shortly be a need to label other file descriptors in a
different way. So the current name is ambiguous. Rename
the method to virSecurityManagerSetImageFDLabel to clarify
its purpose
* src/libvirt_private.syms,
src/qemu/qemu_migration.c, src/qemu/qemu_process.c,
src/security/security_apparmor.c, src/security/security_dac.c,
src/security/security_driver.h, src/security/security_manager.c,
src/security/security_manager.h, src/security/security_selinux.c,
src/security/security_stack.c: s/FDLabel/ImageFDLabel/
This is in response to bugzilla 664629
https://bugzilla.redhat.com/show_bug.cgi?id=664629
The patch below returns an appropriate error message if the chain of
nwfilters is found to contain unresolvable variables and therefore
cannot be instantiated.
Example: The following XMl added to a domain:
<interface type='bridge'>
<mac address='52:54:00:9f:80:45'/>
<source bridge='virbr0'/>
<model type='virtio'/>
<filterref filter='test'/>
</interface>
that references the following filter
<filter name='test' chain='root'>
<filterref filter='clean-traffic'/>
<filterref filter='allow-dhcp-server'/>
</filter>
now displays upon 'virsh start mydomain'
error: Failed to start domain mydomain
error: internal error Cannot instantiate filter due to unresolvable variable: DHCPSERVER
'DHPCSERVER' is contained in allow-dhcp-server.
We already have a public virDomainPinVcpu, which implies that
Pin and Vcpu are treated as separate words. Unreleased commit
e261987c introduced virDomainGetVcpupinInfo as the first public
API that used Vcpupin, although we had prior internal uses of
that spelling. For consistency, change the spelling to be two
words everywhere, regardless of whether pin comes first or last.
* daemon/remote.c: Treat vcpu and pin as separate words.
* include/libvirt/libvirt.h.in: Likewise.
* src/conf/domain_conf.c: Likewise.
* src/conf/domain_conf.h: Likewise.
* src/driver.h: Likewise.
* src/libvirt.c: Likewise.
* src/libvirt_private.syms: Likewise.
* src/libvirt_public.syms: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.
* src/remote/remote_protocol.x: Likewise.
* src/remote_protocol-structs: Likewise.
Suggested by Matthias Bolte.
Convert networkDnsmasqLeaseFileName to a replaceable function pointer
that allow the testsuite to use a version of that function that is not
depending on configure --localstatedir.
This fixes 5 of 6 test failures, when configure --localstatedir isn't
set to /var.
The build currently fails when trying to create virnetprotocol.c
into $(builddir)/rpc, which doesn't exist. But since the file
is part of the tarball, it should be generated into $(srcdir).
Caught by autobuild.sh.
* src/Makefile.am (VIR_NET_RPC_GENERATED): Generate into srcdir.
