dmidecode displays processor information, followed by BIOS, system and
memory-DIMM details.
Calls to virSysinfoParseBIOS(), virSysinfoParseSystem() would update
the buffer pointer 'base', so the processor information would be lost
before virSysinfoParseProcessor() was called. Sysinfo would therefore
not be able to display processor details -- It only described <bios>,
<system> and <memory_device> details.
This patch attempts to insulate sysinfo from ordering of dmidecode
output.
Before the fix:
---------------
virsh # sysinfo
<sysinfo type='smbios'>
<bios>
....
</bios>
<system>
....
</system>
<memory_device>
....
</memory_device>
After the fix:
-------------
virsh # sysinfo
<sysinfo type='smbios'>
<bios>
....
</bios>
<system>
....
</system>
<processor>
....
</processor>
<memory_device>
....
</memory_device>
Input to the volume cloning code is a source volume and an XML
descriptor for the new volume. It is possible for the new volume
to have a greater size than source volume, at which point libvirt
will just stick 0s on the end of the new image (for raw format
anyways).
Unfortunately a logic error messed up our tracking of the of the
excess amount that needed to be written: end result is that sparse
clones were made very much non-sparse, and cloning regular disk
images could end up excessively sized (though data unaltered).
Drop the 'remain' variable entriely here since it's redundant, and
track actual allocation directly against the desired 'total'.
See: https://bugzilla.redhat.com/show_bug.cgi?id=785269
The specfile requires avahi during install if libvirt was built with
avahi support, but there are many situations where it is undesirable
to install avahi due to security concerns. This patch requires only
the avahi-libs package, which is needed by libvirt to call the
function that tries to attach to the avahi daemon, but will instead
silently fail because the avahi-daemon is in the main avahi package,
and that package isn't installed.
If you are sitting in front of a physical machine and logged in as
a regular user, you can connect to the system libvirtd instance
by providing a root password to policykit. This is how most
virt-manager users talk to libvirt.
However, if you are launching virt-manager over ssh -X, or over
VNC started from say /etc/sysconfig/vncservers, our policykit policy
rejects the user outright, providing no option to provide the root
password. This is confusing to users and doesn't seem to serve much
point.
Change the policy to allow inactive (VNC) and non-local (SSH, VNC)
to provide root credentials for accessing system libvirtd. We use
auth_admin rather than auth_admin_keep so that credentials aren't
cached at all, and every subsequent reconnection to libvirt requires
auth.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=625115
Similar change to PackageKit policy:
https://bugzilla.redhat.com/show_bug.cgi?id=528511
As we already link with libvirt.la which contains libvirt_utils.la.
Double linking causes global symbols to be presented twice and
thus confusion. This partially reverts c700613b8d
gcc 4.7 complains:
util/virhashcode.c:49:17: error: always_inline function might not be inlinable [-Werror=attributes]
util/virhashcode.c:35:17: error: always_inline function might not be inlinable [-Werror=attributes]
Normal 'inline' is a hint that the compiler may ignore; the fact
that the function is static is good enough. We don't care if the
compiler decided not to inline after all.
* src/util/virhashcode.c (getblock, fmix): Relax attribute.
Someone mentioned to me that they interpreted this section of the KVM
driver page as suggesting that new guests should be created by
creating a qemu commandline and converting it to XML with
domxml-from-native. I don't think that's the intent of
domxml-from-native, so I added that clarification.
On CentOS5:
If "virsh edit $DOM" is used and an error happens (for example changing
any live cycle action to a non-existing value), libvirt forgets that
$DOM exists, since it is already removed from the internal hash tables,
which are used for domain lookup.
In once case (unreproducible) even the persistent configuration
/etc/xen/$DOM was deleted.
Instead of using the compound function xenXMConfigSaveFile() explicitly
use xenFomatXM() and virConfWriteFile() to distinguish between a failure
in converting the libvirt definition to the xen-xm format and a problem
when writing the file.
Signed-off-by: Philipp Hahn <hahn@univention.de>
Commit b170eb99 introduced a bug: domains that had an explicit
<seclabel type='none'/> when started would not be reparsed if
libvirtd restarted. It turns out that our testsuite was not
exercising this because it never tried anything but inactive
parsing. Additionally, the live XML for such a domain failed
to re-validate. Applying just the tests/ portion of this patch
will expose the bugs that are fixed by the other two files.
* docs/schemas/domaincommon.rng (seclabel): Allow relabel under
type='none'.
* src/conf/domain_conf.c (virSecurityLabelDefParseXML): Per RNG,
presence of <seclabel> with no type implies dynamic. Don't
require sub-elements for type='none'.
* tests/qemuxml2xmltest.c (mymain): Add test.
* tests/qemuxml2argvtest.c (mymain): Likewise.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.xml: Add file.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.args: Add file.
Reported by Ansis Atteka.
Move myself from 'Previous maintainers' section to 'the primary maintainers and
people with commit access rights' section, because I have a commit rights now.
Signed-off-by: Alex Jia <ajia@redhat.com>
Commit fad5cd2108 introduces a new flag
that allows to show domain's title with domains. This commit introduced
resource leak while listing inactive domains with titles.
On CentOS5 with xen-3.0.3:
Program received signal SIGSEGV, Segmentation fault.
virFree (ptrptr=0x8) at util/memory.c:310
310 free(*(void**)ptrptr);
(gdb) bt
#0 virFree (ptrptr=0x8) at util/memory.c:310
#1 0x00002aaaaae167c8 in xenXMDomainDefineXML (conn=0x694e80, xml=0x6b2ce0 "P\fk") at xen/xm_internal.c:1199
#2 0x00002aaaaae070d7 in xenUnifiedDomainDefineXML (conn=0x8,
xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at xen/xen_driver.c:1524
#3 0x00002aaaaada7803 in virDomainDefineXML (conn=0x694e80,
xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at libvirt.c:7823
#4 0x0000000000426173 in cmdEdit (ctl=0x7fffffffb8e0, cmd=<value optimized out>) at virsh.c:14882
#5 0x000000000041c9ce in vshCommandRun (ctl=0x7fffffffb8e0, cmd=0x658c50) at virsh.c:17712
#6 0x000000000042c3b9 in main (argc=1, argv=<value optimized out>) at virsh.c:19317
Signed-off-by: Philipp Hahn <hahn@univention.de>
Calling qemuDomainMigrateGraphicsRelocate notifies spice clients to
connect to destination qemu so that they can seamlessly switch streams
once migration is done. Unfortunately, current qemu is not able to
accept any connections while incoming migration connection is open.
Thus, we need to delay opening the migration connection to the point
spice client is already connected to the destination qemu.
Detected by valgrind. the codes are allocating 0 bytes memory to variable
cpumap by vshCalloc function, and then the function VIR_USE_CPU will access
it later, a invalid read error will be hit.
* tools/virsh.c(cmdVcpuPin): fix invalid read error.
* How to reproduce?
% valgrind -v --read-var-info=yes virsh vcpupin <domain> 0 0
* Actual result:
==27271== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 8 from 6)
==27271==
==27271== 1 errors in context 1 of 2:
==27271== Invalid read of size 1
==27271== at 0x39CF087E2E: __GI_memcpy (in /lib64/libc-2.12.so)
==27271== by 0x39CF114FDC: xdrmem_putbytes (in /lib64/libc-2.12.so)
==27271== by 0x39CF114707: xdr_opaque (in /lib64/libc-2.12.so)
==27271== by 0x4D56194: xdr_remote_domain_pin_vcpu_args (remote_protocol.c:1844)
==27271== by 0x4D6CCE1: virNetMessageEncodePayload (virnetmessage.c:341)
==27271== by 0x4D5A44B: virNetClientProgramCall (virnetclientprogram.c:327)
==27271== by 0x4D36EDB: callWithFD (remote_driver.c:4546)
==27271== by 0x4D36F7B: call (remote_driver.c:4567)
==27271== by 0x4D3B2C1: remoteDomainPinVcpu (remote_client_bodies.h:1566)
==27271== by 0x4D199D3: virDomainPinVcpu (libvirt.c:8585)
==27271== by 0x4241F4: cmdVcpuPin (virsh.c:5262)
==27271== by 0x4150A6: vshCommandRun (virsh.c:17712)
==27271== Address 0x5602b80 is 0 bytes after a block of size 0 alloc'd
==27271== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==27271== by 0x4C89BDF: virAllocN (memory.c:129)
==27271== by 0x423868: _vshCalloc.clone.2 (virsh.c:454)
==27271== by 0x423EF9: cmdVcpuPin (virsh.c:5190)
==27271== by 0x4150A6: vshCommandRun (virsh.c:17712)
==27271== by 0x426583: main (virsh.c:19289)
==27271==
==27271==
==27271== 4 errors in context 2 of 2:
==27271== Invalid read of size 1
==27271== at 0x424133: cmdVcpuPin (virsh.c:5245)
==27271== by 0x4150A6: vshCommandRun (virsh.c:17712)
==27271== by 0x426583: main (virsh.c:19289)
==27271== Address 0x5602b80 is 0 bytes after a block of size 0 alloc'd
==27271== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==27271== by 0x4C89BDF: virAllocN (memory.c:129)
==27271== by 0x423868: _vshCalloc.clone.2 (virsh.c:454)
==27271== by 0x423EF9: cmdVcpuPin (virsh.c:5190)
==27271== by 0x4150A6: vshCommandRun (virsh.c:17712)
==27271== by 0x426583: main (virsh.c:19289)
Signed-off-by: Alex Jia <ajia@redhat.com>
Unlike .cvsignore under CVS, git allows for ignoring nested
names. We weren't very consistent where new tests were
being ignored (some in .gitignore, some in tests/.gitignore),
and I found it easier to just consolidate everything.
* .gitignore: Subsume entries from subdirectories.
* daemon/.gitignore: Delete.
* docs/.gitignore: Likewise.
* docs/devhelp/.gitignore: Likewise.
* docs/html/.gitignore: Likewise.
* examples/dominfo/.gitignore: Likewise.
* examples/domsuspend/.gitignore: Likewise.
* examples/hellolibvirt/.gitignore: Likewise.
* examples/openauth/.gitignore: Likewise.
* examples/domain-events/events-c/.gitignore: Likewise.
* include/libvirt/.gitignore: Likewise.
* src/.gitignore: Likewise.
* src/esx/.gitignore: Likewise.
* tests/.gitignore: Likewise.
* tools/.gitignore: Likewise.
This eliminates the warning message reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=624447
It was caused by a failure to open an image file that is not
accessible by root (the uid libvirtd is running as) because it's on a
root-squash NFS share, owned by a different user, with permissions of
660 (or maybe 600).
The solution is to use virFileOpenAs() rather than open(). The
codepath that generates the error is during qemuSetupDiskCGroup(), but
the actual open() is in a lower-level generic function called from
many places (virDomainDiskDefForeachPath), so some other pieces of the
code were touched just to add dummy (or possibly useful) uid and gid
arguments.
Eliminating this warning message has the nice side effect that the
requested operation may even succeed (which in this case isn't
necessary, but shouldn't hurt anything either).
virFileOpenAs previously would only try opening a file as the current
user, or as a different user, but wouldn't try both methods in a
single call. This made it cumbersome to use as a replacement for
open(2). Additionally, it had a lot of historical baggage that led to
it being difficult to understand.
This patch refactors virFileOpenAs in the following ways:
* reorganize the code so that everything dealing with both the parent
and child sides of the "fork+setuid+setgid+open" method are in a
separate function. This makes the public function easier to understand.
* Allow a single call to virFileOpenAs() to first attempt the open as
the current user, and if that fails to automatically re-try after
doing fork+setuid (if deemed appropriate, i.e. errno indicates it
would now be successful, and the file is on a networkFS). This makes
it possible (in many, but possibly not all, cases) to drop-in
virFileOpenAs() as a replacement for open(2).
(NB: currently qemuOpenFile() calls virFileOpenAs() twice, once
without forking, then again with forking. That unfortunately can't
be changed without at least some discussion of the ramifications,
because the requested file permissions are different in each case,
which is something that a single call to virFileOpenAs() can't deal
with.)
* Add a flag so that any fchown() of the file to a different uid:gid
is explicitly requested when the function is called, rather than it
being implied by the presence of the O_CREAT flag. This just makes
for less subtle surprises to consumers. (Commit
b1643dc15c added the check for O_CREAT
before forcing ownership. This patch just makes that restriction
more explicit.)
* If either the uid or gid is specified as "-1", virFileOpenAs will
interpret this to mean "the current [gu]id".
All current consumers of virFileOpenAs should retain their present
behavior (after a few minor changes to their setup code and
arguments).
Rename the src/util/netlink files to src/util/virnetlink to
better fit the naming scheme. Also rename nlComm to virNetlinkCommand.
Signed-off-by: D. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
When libvirt's virDomainDestroy API is shutting down the qemu process,
it first sends SIGTERM, then waits for 1.6 seconds and, if it sees the
process still there, sends a SIGKILL.
There have been reports that this behavior can lead to data loss
because the guest running in qemu doesn't have time to flush its disk
cache buffers before it's unceremoniously whacked.
This patch maintains that default behavior, but provides a new flag
VIR_DOMAIN_DESTROY_GRACEFUL to alter the behavior. If this flag is set
in the call to virDomainDestroyFlags, SIGKILL will never be sent to
the qemu process; instead, if the timeout is reached and the qemu
process still exists, virDomainDestroy will return an error.
Once this patch is in, the recommended method for applications to call
virDomainDestroyFlags will be with VIR_DOMAIN_DESTROY_GRACEFUL
included. If that fails, then the application can decide if and when
to call virDomainDestroyFlags again without
VIR_DOMAIN_DESTROY_GRACEFUL (to force the issue with SIGKILL).
(Note that this does not address the issue of existing applications
that have not yet been modified to use VIR_DOMAIN_DESTROY_GRACEFUL.
That is a separate patch.)
This patch starts the process of elevating the python binding code
to be on the same level as the rest of libvirt when it comes to
requiring good coding styles. Statically linking against the
libvirt_util library makes it much easier to write good code,
rather than having to open-code and reinvent things locally.
Done by global search and replace of s/free(/VIR_FREE(/, followed
by hand-inspection of remaining malloc and redundant memset.
* cfg.mk (exclude_file_name_regexp--sc_prohibit_raw_allocation):
Remove python from exemption.
* python/Makefile.am (INCLUDES): Add gnulib and src/util. Drop
$(top_builddir)/$(subdir), as automake already guarantees that.
(mylibs, myqemulibs): Pull in libvirt_util and gnulib.
(libvirtmod_la_CFLAGS): Catch compiler warnings if configured to
use -Werror.
* python/typewrappers.c (libvirt_charPtrSizeWrap)
(libvirt_charPtrWrap): Convert free to VIR_FREE.
* python/generator.py (print_function_wrapper): Likewise.
* python/libvirt-override.c: Likewise.
Our HACKING discourages use of malloc and free, for at least
a couple of years now. But we weren't enforcing it, until now :)
For now, I've exempted python and tests, and will clean those up
in subsequent patches. Examples should be permanently exempt,
since anyone copying our examples won't have use of our
internal-only memory.h via libvirt_util.la.
* cfg.mk (sc_prohibit_raw_allocation): New rule.
(exclude_file_name_regexp--sc_prohibit_raw_allocation): and
exemptions.
* src/cpu/cpu.c (cpuDataFree): Avoid false positive.
* src/conf/network_conf.c (virNetworkDNSSrvDefParseXML): Fix
offenders.
* src/libxl/libxl_conf.c (libxlMakeDomBuildInfo, libxlMakeVfb)
(libxlMakeDeviceModelInfo): Likewise.
* src/rpc/virnetmessage.c (virNetMessageSaveError): Likewise.
* tools/virsh.c (_vshMalloc, _vshCalloc): Likewise.
I noticed some redundant code while preparing my next patch.
* python/generator.py (py_types): Fix 'const char *' mapping.
* python/typewrappers.h (libvirt_charPtrConstWrap): Drop.
* python/typewrappers.c (libvirt_charPtrConstWrap): Delete, since
it is identical to libvirt_constcharPtrWrap.
Sometimes, its easier to run children with 2>&1 in shell notation,
and just deal with stdout and stderr interleaved. This was already
possible for fd handling; extend it to also work when doing string
capture of a child process.
* docs/internals/command.html.in: Document this.
* src/util/command.c (virCommandSetErrorBuffer): Likewise.
(virCommandRun, virExecWithHook): Implement it.
* tests/commandtest.c (test14): Test it.
* daemon/remote.c (remoteDispatchAuthPolkit): Use new command
feature.
This patch fixes the access of variable "con" in two files where the
variable was declared only on SELinux builds and thus the build failed
without SELinux. It's a rather nasty fix but helps fix the build
quickly and without any major changes to the code.
Detected by valgrind. Leak is introduced in commit 397e6a7.
* src/conf/domain_conf.c(virDomainDiskDefParseXML): fix memory leak.
How to reproduce?
% make -C tests check TESTS=qemuxml2argvtest
% cd tests && valgrind -v --leak-check=full ./qemuxml2argvtest
* Actual result:
==16352== 4 bytes in 1 blocks are definitely lost in loss record 12 of 147
==16352== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==16352== by 0x39D90A67DD: xmlStrndup (xmlstring.c:45)
==16352== by 0x4E83D5: virDomainDiskDefParseXML (domain_conf.c:2894)
==16352== by 0x4F542D: virDomainDefParseXML (domain_conf.c:7626)
==16352== by 0x4F8683: virDomainDefParseNode (domain_conf.c:8390)
==16352== by 0x4F904E: virDomainDefParse (domain_conf.c:8340)
==16352== by 0x41C626: testCompareXMLToArgvHelper (qemuxml2argvtest.c:105)
==16352== by 0x41DED1: virtTestRun (testutils.c:142)
==16352== by 0x418172: mymain (qemuxml2argvtest.c:486)
==16352== by 0x41D5C7: virtTestMain (testutils.c:697)
==16352== by 0x39CF01ECDC: (below main) (in /lib64/libc-2.12.so)
Signed-off-by: Alex Jia <ajia@redhat.com>
To allow the container to access /dev and /dev/pts when under
sVirt, set an explicit mount option. Also set a max size on
the /dev mount to prevent DOS on memory usage
* src/lxc/lxc_container.c: Set /dev mount context
* src/lxc/lxc_controller.c: Set /dev/pts mount context
For the sake of backwards compat, LXC guests are *not*
confined by default. This is because it is not practical
to dynamically relabel containers using large filesystem
trees. Applications can create confined containers though,
by giving suitable XML configs
* src/Makefile.am: Link libvirt_lxc to security drivers
* src/lxc/libvirtd_lxc.aug, src/lxc/lxc_conf.h,
src/lxc/lxc_conf.c, src/lxc/lxc.conf,
src/lxc/test_libvirtd_lxc.aug: Config file handling for
security driver
* src/lxc/lxc_driver.c: Wire up security driver functions
* src/lxc/lxc_controller.c: Add a '--security' flag to
specify which security driver to activate
* src/lxc/lxc_container.c, src/lxc/lxc_container.h: Set
the process label just before exec'ing init.
Curently security labels can be of type 'dynamic' or 'static'.
If no security label is given, then 'dynamic' is assumed. The
current code takes advantage of this default, and avoids even
saving <seclabel> elements with type='dynamic' to disk. This
means if you temporarily change security driver, the guests
can all still start.
With the introduction of sVirt to LXC though, there needs to be
a new default of 'none' to allow unconfined LXC containers.
This patch introduces two new security label types
- default: the host configuration decides whether to run the
guest with type 'none' or 'dynamic' at guest start
- none: the guest will run unconfined by security policy
The 'none' label type will obviously be undesirable for some
deployments, so a new qemu.conf option allows a host admin to
mandate confined guests. It is also possible to turn off default
confinement
security_default_confined = 1|0 (default == 1)
security_require_confined = 1|0 (default == 0)
* src/conf/domain_conf.c, src/conf/domain_conf.h: Add new
seclabel types
* src/security/security_manager.c, src/security/security_manager.h:
Set default sec label types
* src/security/security_selinux.c: Handle 'none' seclabel type
* src/qemu/qemu.conf, src/qemu/qemu_conf.c, src/qemu/qemu_conf.h,
src/qemu/libvirtd_qemu.aug: New security config options
* src/qemu/qemu_driver.c: Tell security driver about default
config
This re-introduces parsing & formatting for per device seclabels.
There is a new virDomainDeviceSeclabelPtr struct and corresponding
APIs for parsing/formatting.
Revert parsing changes:
commit 302fe95ffa
Author: Eric Blake <eblake@redhat.com>
Date: Wed Jan 4 16:01:24 2012 -0700
seclabel: fix regression in libvirtd restart
commit b43432931a
Author: Eric Blake <eblake@redhat.com>
Date: Thu Dec 22 17:47:50 2011 -0700
seclabel: allow a seclabel override on a disk src
These two commits changed the sec label parsing code so that
the same code dealt with both the VM level sec label, and the
per device label. Unfortunately, as we add more options to the
VM level sec label, the logic required to use the same parsing
code for the per device label becomes unintelligible.
* src/conf/domain_conf.c: Remove support for parsing per
device sec labels
The storage pools page contains details about the capabilities of the
various pool types, but not an overview of how they are intended to be
used. This patch adds some explanation of what pools and volumes can
be used for and why an administrator might want to use them.
Detected by valgrind. Leak is introduced in commit 3bb6bcf.
Free 'vol' memory before allocating memory, the codes will miss one time
free when 'vol_i = nvolumes' in for loop, so plug memory leak.
* tools/virsh.c: fix memory leak on cmdUndefine.
* How to reproduce?
% dd if=/dev/null of=/var/lib/libvirt/images/foo bs=1 count=1 seek=10M
% virsh define foo.xml (disk source file points to '/var/lib/libvirt/images/foo')
% virsh vol-clone foo foo-clone default (the original guest name is 'foo')
% virsh pool-refresh default
% virsh vol-list default (make sure 'foo-clone' volume exists)
% virsh define foo-clone.xml (disk source file points to '/var/lib/libvirt/images/foo-clone')
% valgrind -v --leak-check=full virsh undefine foo-clone --remove-all-storage
* Actual results:
1. virsh output
Domain foo-clone has been undefined
Volume '/var/lib/libvirt/images/foo-clone' removed.
error: Failed to disconnect from the hypervisor, 1 leaked reference(s)
2. valgrind result
==6515== 92 (40 direct, 52 indirect) bytes in 1 blocks are definitely lost in loss record 46 of 69
==6515== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==6515== by 0x4C89B71: virAlloc (memory.c:101)
==6515== by 0x4CFCACE: virGetStorageVol (datatypes.c:724)
==6515== by 0x4D4A8E0: remoteStorageVolLookupByPath (remote_driver.c:4664)
==6515== by 0x4D07153: virStorageVolLookupByPath (libvirt.c:12508)
==6515== by 0x4270E6: cmdUndefine (virsh.c:2828)
==6515== by 0x4151B6: vshCommandRun (virsh.c:17693)
==6515== by 0x4264D3: main (virsh.c:19270)
==6515==
==6515== LEAK SUMMARY:
==6515== definitely lost: 40 bytes in 1 blocks
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=786674
Signed-off-by: Alex Jia <ajia@redhat.com>
