Start a page describing some of the things that applications
using libvirt need to bear in mind to ensure security of their
systems.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Prefer using VFIO (if available) to the legacy KVM device passthrough.
With this patch a PCI passthrough device without the driver configured
will be started with VFIO if it's available on the host. If not legacy
KVM passthrough is checked and error is reported if it's not available.
Since 76b644c when the support for RAM filesystems was introduced,
libvirt accepted the following XML:
<source usage='1024' unit='KiB'/>
This was parsed correctly and internally stored in bytes, but it
was formatted as (with an extra 's'):
<source usage='1024' units='KiB'/>
When read again, this was treated as if the units were missing,
meaning libvirt was unable to parse its own XML correctly.
The usage attribute was documented as being in KiB, but it was not
scaled if the unit was missing. Transient domains still worked,
because this was balanced by an extra 'k' in the mount options.
This patch:
Changes the parser to use 'units' instead of 'unit', as the latter
was never documented (fixing persistent domains) and some programs
(libvirt-glib, libvirt-sandbox) already parse the 'units' attribute.
Removes the extra 'k' from the tmpfs mount options, which is needed
because now we parse our own XML correctly.
Changes the default input unit to KiB to match documentation, fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=1015689
Commit id 'c4a4603de' added an output <path> to the nodedev xml, but
did not update the schema.
This resulted in the failure of the 'virt-xml-validate' on a file
generated by 'virsh nodedev-dumpxml pci_0000_00_00_0' (for example).
This was found/seen by running autotest on my host.
This resolves one of the issues in:
https://bugzilla.redhat.com/show_bug.cgi?id=1003983
This device is identical to qemu's "intel-hda" device (known as "ich6"
in libvirt), but has a different PCI device ID (which matches the ID
of the hda audio built into the ich9 chipset, of course). It's not
supported in earlier versions of qemu, so it requires a capability
bit.
The xml files are generated in build directory and thus docs/newapi.xsl
was not able to find them in a VPATH build.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Useful to set custom forwarders instead of using the contents of
/etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to
resolve VM domain names from domain 0, when domain option is used.
Signed-off-by: Diego Woitasen <diego.woitasen@vhgroup.net>
Signed-off-by: Eric Blake <eblake@redhat.com>
Currently the XML parser already allows the following syntax:
<disk type='block' device='cdrom'>
<source startupPolicy='optional'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
But it if the dev value is NULL then it would not have the leading
"<source ", resulting in invalid XML.
qemu/KVM also supports a tftp URL while specifying the cdrom ISO image.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='tftp' name='/url/path'>
<host name='host.name' port='69'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
The ftps protocol is another protocol supported by qemu/KVM while specifying
the cdrom ISO image.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='ftps' name='/url/path'>
<host name='host.name' port='990'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
The https protocol is also accepted by qemu/KVM when specifying the cdrom ISO
image.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='https' name='/url/path'>
<host name='host.name' port='443'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
Describe some of the issues to be aware of when configuring LXC
guests with security isolation as a goal.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
First make sure that the input is xhtml as the stylesheets expect
namespaced element, then use a span element instead of a as a
is treated specially, finally adjust the makefile to check for
the new span element and replace it with the PHP code
Mention that user namespace can be enabled using the UID/GID
mapping schema.
Fix typo in link anchor for container args in domain XML docs.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Commits 905629f4 and 1716e7a6 have added support for specifying
an IPv4 range and a port range to be used by NAT:
<forward mode='nat'>
<nat>
<address start='10.20.30.40' end='10.20.30.44'/>
<port start='60000' end='65432'/>
</nat>
</forward>
https://bugzilla.redhat.com/show_bug.cgi?id=1004364
According to VMWare's documentation 'cdrom-raw' is an acceptable value
for deviceType for a CD-ROM drive. The documentation states that the VMX
configuration for a CD-ROM deviceType is as follows:
ide|scsi(n):(n).deviceType = "cdrom-raw|atapi-cdrom|cdrom-image"
From the documentation it appears the following is true:
- cdrom-image = Provides the ISO to the VM
- atapi-cdrom = Provides a NEC emulated ATAPI CD-ROM on top of the host
CD-ROM
- cdrom-raw = Passthru for a host CD-ROM drive. Allows CD-R burning from
within the guest.
A CD-ROM prior to this patch would always provide an 'atapi-cdrom' is
modeled as:
<disk type='block' device='cdrom'>
<source dev='/dev/scd0'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
This patch allows the 'device' attribute to be set to 'lun' for a raw
acccess CD-ROM such as:
<disk type='block' device='lun'>
<source dev='/dev/scd0'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
This corresponds to '-sd' and '-drive if=sd' on the qemu command line.
Needed for many ARM boards which don't provide any other way to
pass in storage.
Add an attribute named 'removable' to the 'target' element of disks,
which controls the removable flag. For instance, on a Linux guest it
controls the value of /sys/block/$dev/removable. This option is only
valid for USB disks (i.e. bus='usb'), and its default value is 'off',
which is the same behaviour as before.
To achieve this, 'removable=on' (or 'off') is appended to the '-device
usb-storage' parameter sent to qemu when adding a USB disk via
'-disk'. A capability flag QEMU_CAPS_USB_STORAGE_REMOVABLE was added
to keep track if this option is supported by the qemu version used.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=922495
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
'make distcheck' was failing with:
make[3]: Entering directory `/home/eblake/libvirt-tmp2/libvirt-1.1.1/_build/docs'
perl ../../docs/genaclperms.pl ../../src/access/viraccessperm.h > ../../docs/aclperms.htmlinc
/bin/sh: ../../docs/aclperms.htmlinc: Permission denied
when simulating the case of a user doing a VPATH build from a
read-only source tree. The culprit? BUILT_SOURCES are _always_
built, and so must NOT be built into srcdir and need not be part
of the tarball. On the other hand, shipped files must never
depend on files in the builddir. While it would be possible to
fix the problem by generating aclperms.htmlinc into builddir,
we then have the problem that we ship acl.html - we'd have to
rejigger a lot of things to not ship pre-built html. So this
patch goes the other direction - we don't need BUILT_SOURCES,
but instead ensure that we have proper dependencies so that
all files in srcdir are up-to-date at the time the tarball is
created. And because we ship html files in the tarball, that
implies we don't expect users to be able to rebuild them, so
we must not clean any files that would trigger a rebuild except
under the maintainer rules.
* docs/Makefile.am (BUILT_SOURCES): Delete.
(CLEANFILES): Downgrade aclperms.htmlinc cleanup...
(maintainer-clean-local): ...and move hvsupport.html.in...
(MAINTAINERCLEANFILES): ...to a maintainer action.
(hvsupport.html.in): Write into srcdir.
(hvsupport.html): Ensure files are built in order.
(aclperms.htmlinc): Honor silent make.
(EXTRA_DIST): Ship aclperms.htmlinc.
Signed-off-by: Eric Blake <eblake@redhat.com>
With the 1.1.1 tarball, if a user does 'make && make distcheck',
things pass, but if they do 'make distcheck' after 'make clean',
there is an odd failure:
GEN ../../docs/devhelp/index.html
I/O error : Permission denied
I/O error : Permission denied
runtime error: file ../../docs/devhelp/devhelp.xsl line 43 element document
xsltDocumentElem: unable to save to ../../docs/devhelp/libvirt-virterror.html
I/O error : Permission denied
I/O error : Permission denied
This implies that the rules for 'make dist' are missing a
dependency - the generated documentation needs to be up-to-date
before creating the tarball, or else the tarball will be missing
files, where the end user will end up trying to rebuild files in
srcdir, and that fails when srcdir is read-only.
1.1.1 plus this patch now works without issues (other issues have
crept in to 1.1.2-rc1 that prevent 'make distcheck' from working,
but those will be cleaned up in later patches).
* docs/Makefile.am (dist-local): New dependency.
Signed-off-by: Eric Blake <eblake@redhat.com>
<controller type='pci' index='0' model='pci-root'>
<pcihole64 unit='KiB'>1048576</pcihole64>
</controller>
It can be used to adjust (or disable) the size of the 64-bit
PCI hole. The size attribute is in kilobytes (different unit
can be specified on input), but it gets rounded up to
the nearest GB by QEMU.
Disabling it will be needed for guests that crash with the
64-bit PCI hole (like Windows XP), see:
https://bugzilla.redhat.com/show_bug.cgi?id=990418
The ftp protocol is already recognized by qemu/KVM so add this support to
libvirt as well.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='ftp' name='/url/path'>
<host name='host.name' port='21'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
QEMU/KVM already allows a HTTP URL for the cdrom ISO image so add this support
to libvirt as well.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='http' name='/url/path'>
<host name='host.name' port='80'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
Consistently use "is" or "is not" to compare variables to None,
because doing so is preferrable, as per PEP 8
(http://www.python.org/dev/peps/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
Add more iSCSI examples including having a secret attached. There are 4 new
examples; one for each way to have an iSCSI - a network disk using virtio,
a passthrough network lun using scsi, a volume disk using "mode='host'",
and a volume disk using "mode='direct'"
https://bugzilla.redhat.com/show_bug.cgi?id=924153
Commit 904e05a2 (v0.9.9) added a per-<disk> seclabel element with
an attribute relabel='no' in order to try and minimize the
impact of shutdown delays when an NFS server disappears. The idea
was that if a disk is on NFS and can't be labeled in the first
place, there is no need to attempt the (no-op) relabel on domain
shutdown. Unfortunately, the way this was implemented was by
modifying the domain XML so that the optimization would survive
libvirtd restart, but in a way that is indistinguishable from an
explicit user setting. Furthermore, once the setting is turned
on, libvirt avoids attempts at labeling, even for operations like
snapshot or blockcopy where the chain is being extended or pivoted
onto non-NFS, where SELinux labeling is once again possible. As
a result, it was impossible to do a blockcopy to pivot from an
NFS image file onto a local file.
The solution is to separate the semantics of a chain that must
not be labeled (which the user can set even on persistent domains)
vs. the optimization of not attempting a relabel on cleanup (a
live-only annotation), and using only the user's explicit notation
rather than the optimization as the decision on whether to skip
a label attempt in the first place. When upgrading an older
libvirtd to a newer, an NFS volume will still attempt the relabel;
but as the avoidance of a relabel was only an optimization, this
shouldn't cause any problems.
In the ideal future, libvirt will eventually have XML describing
EVERY file in the backing chain, with each file having a separate
<seclabel> element. At that point, libvirt will be able to track
more closely which files need a relabel attempt at shutdown. But
until we reach that point, the single <seclabel> for the entire
<disk> chain is treated as a hint - when a chain has only one
file, then we know it is accurate; but if the chain has more than
one file, we have to attempt relabel in spite of the attribute,
in case part of the chain is local and SELinux mattered for that
portion of the chain.
* src/conf/domain_conf.h (_virSecurityDeviceLabelDef): Add new
member.
* src/conf/domain_conf.c (virSecurityDeviceLabelDefParseXML):
Parse it, for live images only.
(virSecurityDeviceLabelDefFormat): Output it.
(virDomainDiskDefParseXML, virDomainChrSourceDefParseXML)
(virDomainDiskSourceDefFormat, virDomainChrDefFormat)
(virDomainDiskDefFormat): Pass flags on through.
* src/security/security_selinux.c
(virSecuritySELinuxRestoreSecurityImageLabelInt): Honor labelskip
when possible.
(virSecuritySELinuxSetSecurityFileLabel): Set labelskip, not
norelabel, if labeling fails.
(virSecuritySELinuxSetFileconHelper): Fix indentation.
* docs/formatdomain.html.in (seclabel): Document new xml.
* docs/schemas/domaincommon.rng (devSeclabel): Allow it in RNG.
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.xml:
* tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.args:
* tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-*-labelskip.xml:
New test files.
* tests/qemuxml2argvtest.c (mymain): Run the new tests.
* tests/qemuxml2xmltest.c (mymain): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
In one of my previous patches I am removing the hard_limit heuristic to
guess the correct value if none set. However, it turned out, this limit
is hard to guess even for users. We should advise them to not set the
limit as their domains may be OOM killed. Sigh.
Feedback from the polkit developers indicates that the
"_detail_XXXX" attributes are a private implementation
detail. Our examples should be recommending use of the
"action.lookup('XXX')" method instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This resolves the issue that prompted the filing of
https://bugzilla.redhat.com/show_bug.cgi?id=928638
(although the request there is for something much larger and more
general than this patch).
commit f3868259ca disabled the
forwarding to upstream DNS servers of unresolved DNS requests for
names that had no domain, but were just simple host names (no "."
character anywhere in the name). While this behavior is frowned upon
by DNS root servers (that's why it was changed in libvirt), it is
convenient in some cases, and since dnsmasq can be configured to allow
it, it must not be strictly forbidden.
This patch restores the old behavior, but since it is usually
undesirable, restoring it requires specification of a new option in
the network config. Adding the attribute "forwardPlainNames='yes'" to
the <dns> elemnt does the trick - when that attribute is added to a
network config, any simple hostnames that can't be resolved by the
network's dnsmasq instance will be forwarded to the DNS servers listed
in the host's /etc/resolv.conf for an attempt at resolution (just as
any FQDN would be forwarded).
When that attribute *isn't* specified, unresolved simple names will
*not* be forwarded to the upstream DNS server - this is the default
behavior.
The description for <permissions> was copied from the storage volume
section to the storage pool section, but the semantics are different:
1. Currently only the "dir", "fs" and "netfs" storage pools use it.
2. They use it only to build the final directory.
3. A default for the storage volumes can't be set.
Signed-off-by: Philipp Hahn <hahn@univention.de>
Commit ab92ae333 added a cool feature, but didn't document it.
* docs/hacking.html.in: Document debugging a subset of tests.
* HACKING: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Add to the docs/drvlxc.html.in documentation to describe how to
configure systemd to auto-activate a container when a client
connects to a socket
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
