[libvirt] virt-install and custom distros
by Kay Williams
We have an application that builds custom distributions based on RHEL, CentOS or
Fedora. We would like to install these over the network using virt-install, but
we've run into an issue with the distro check logic. Specifically, virt-install
fails unless it finds a string "Red Hat Enterprise Linux", "Fedora" or "CentOS"
within the family field of the .treeinfo file.
Our application currently sets the family field to the user-provided distro name
(see below). We have avoided using the base distro name given trademark concerns.
[general]
family = <user provided value>
variant = <user provided value>
We can get virt-install to pass the distro check by setting the family name to
one of the accepted values, e.g.
[general]
family = Fedora
variant = [user provided distro name]
Is this the expected/desired use for the family and variant fields? Or is there
another approach we should consider?
Thanks,
Kay
16 years, 4 months
[libvirt] [PATCH] Fix serial console telnet protocol support
by Mark McLoughlin
With e.g.:
<serial type='tcp'>
<source mode='bind' host='127.0.0.1' service='4444'/>
<protocol type='telnet'/>
<target port='0'/>
</serial>
You currently get:
Unknown option: listen
qemu: could not open serial device 'telnet:127.0.0.1:4444,listen'
With the telnet protocol, qemu expects "server" as an option
rather than "listen".
Signed-off-by: Mark McLoughlin <markmc(a)redhat.com>
Index: libvirt/src/qemu_conf.c
===================================================================
--- libvirt.orig/src/qemu_conf.c 2008-08-13 18:14:34.000000000 +0100
+++ libvirt/src/qemu_conf.c 2008-08-13 18:35:20.000000000 +0100
@@ -685,12 +685,19 @@
break;
case VIR_DOMAIN_CHR_TYPE_TCP:
- if (snprintf(buf, buflen, "%s:%s:%s%s",
- dev->data.tcp.protocol == VIR_DOMAIN_CHR_TCP_PROTOCOL_TELNET ? "telnet" : "tcp",
- dev->data.tcp.host,
- dev->data.tcp.service,
- dev->data.tcp.listen ? ",listen" : "") >= buflen)
- return -1;
+ if (dev->data.tcp.protocol == VIR_DOMAIN_CHR_TCP_PROTOCOL_TELNET) {
+ if (snprintf(buf, buflen, "telnet:%s:%s%s",
+ dev->data.tcp.host,
+ dev->data.tcp.service,
+ dev->data.tcp.listen ? ",server" : "") >= buflen)
+ return -1;
+ } else {
+ if (snprintf(buf, buflen, "tcp:%s:%s%s",
+ dev->data.tcp.host,
+ dev->data.tcp.service,
+ dev->data.tcp.listen ? ",listen" : "") >= buflen)
+ return -1;
+ }
break;
case VIR_DOMAIN_CHR_TYPE_UNIX:
16 years, 4 months
[libvirt] [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization
by James Morris
This is to announce the formation of the sVirt project, which aims to
integrate SELinux and Linux-based virtualization (KVM et al).
The idea has been discussed a few times over the last year or so, and in
recent weeks, a few Fedora folk (such as Dan Walsh, Daniel Berrange and
myself) have put together some requirements and had some preliminary
technical discussions.
The requirements document and initital technical considerations are
included below inline for review and discussion.
In a nutshell, we'd like to be able to apply distinct security labels to
individual VM instances and their resources, so that they can be isolated
from each other via MAC policy. We want this to "just work" when
configuring and managing VMs via the libvirt toolchain, e.g. provide a
simple option during VM creation to make the VM "isolated", and have the
toolchain do all the labeling and policy configuration behind the scenes.
Greater detail may be found in the requirements document.
If you wish to contribute, please reply to this email with any
enhancements to the requirements, technical ideas, issues etc. I'd
suggest joining the libvir-list (in the to: line) if not already on it, as
that is where the integration work is expected to happen.
There's also a wiki page:
http://selinuxproject.org/page/SVirt
------------------------------------------------------------------------
11 Aug 2008
sVirt: Integration of SELinux and Linux-based Virtualization
Requirements and Design Considerations v1.0
1. Introduction
This document establishes a set of functional and technical
requirements for integrating SELinux with Linux-based
virtualization (i.e. Linux-as-hypervisor schemes such as KVM/Qemu
amd lguest).
Note that non-Linux hypervisor models such as Xen are not covered
explicitly in this document, although may be afforded some MAC
coverage due to shared infrastructure (e.g. libvirt). Non-Linux
hypervisor models may considered further at a later stage.
Also, while this document focuses on SELinux as the MAC scheme,
consideration should be given to ensuring support for other
label-based MAC schemes.
1.1 Rationale
With increased use of virtualization, one security benefit of
physically separated systems -- strong isolation -- is reduced, an
issue which may be ameliorated with the application of Mandatory
Access Control (MAC) security in the host system.
Integration of MAC with virtualization will also help increase the
overall robustness and security assurance of both host and guest
systems. Many threats arising from flaws in the VM environment, or
misconfiguration, may be mitigated through tighter isolation and
specific MAC policy enforcement.
By incorporating MAC support into the virtualization toolchain and
documentation, users will also be able to make more use of the MAC
security capabilities provided by the OS.
1.2 Use-cases
The following use-cases have been identified:
o Providing virtualized services with a level of isolation
similar to that previously afforded by physical separation.
o Increased protection of the host from untrusted VM guests (e.g.
for VM hosting providers, grid/cloud servers etc.).
o Increased protection of VM guests from each other in the event
of host flaws or misconfiguration. Some protection may also be
provided against a compromised host.
o Consolidating access to multiple networks which require strong
isolation from each other (e.g. military, government, corporate
extranets, internal "Chinese wall" separation etc.)
o Strongly isolating desktop applications by running them in
separately labeled VMs (e.g. online banking in one VM and World
of Warcraft in another; opening untrusted office documents in
an isolated VM for view/print only).
o Forensic analysis of disk images, binaries, browser scripts
etc. in a highly isolated VM, protecting both the host system
and the integrity of the components under analysis.
o Isolated test environments, preventing e.g. simulated trades
from entering a production system, leakage of sensitive
customer data to internal networks etc.
o General ability to specify a wide range of high-level security
goals for virtualization through flexible MAC policy.
2. Current Situation
SELinux is already able to provide general MAC protection to
Linux-based virtualization, such as protecting the integrity and
confidentiality of disk images and providing strong isolation of
Linux hypervisor processes from the rest of the system.
There is, however, no explicit support for Linux-based
virtualization in SELinux, and all VMs currently run in the same
security context. Thus, there is no MAC isolation applied between
VMs.
3. Functional Security Requirements
3.1 Strong isolation between active VMs
Running different VMs with different MAC labels allows stronger
isolation between VMs, reducing risks arising from flaws in or
misconfiguration of the VM environment. For example, the threat of
a rogue VM exploiting a flaw in KVM could be greatly reduced if it
is isolated from other VMs by MAC security policy.
3.2 Improved control over access to VM resources
Distinct MAC labeling of resources belonging to VMs (disk images,
disk partitions etc.) binds VM instances to those resources,
ensuring that VMs can only access their own resources. This can
protect the VM from invalid VM resources; and protect VM resources
from flawed or misconfigured VMs.
3.3 Improved control over access to shared resources
Where VMs may share resources (e.g. miscellaneous devices, virtual
networking, read-only disk images etc.), fine-grained MAC policy
may be specified to control information flow between VMs.
3.4 Fine-grained interaction with the host
With distinct labeling of VMs and their resources, interactions
with host entities on a per-VM basis may then be controlled by MAC
policy.
An example of this would be to safely allow different users on the
host to administer different VMs. Configuration of this could be
managed via the RBAC scheme integrated with SELinux.
3.5 Coarse MAC containment of VMs
High-level security constraints may be applied to different VMs, to
allow simplified lock-down of the overall system. For example, a
VM may be restricted so that it cannot transmit TCP traffic on port
25 via virtual networking (i.e. the guest cannot be used as a spam
bot even if it is compromised via a rootkit).
3.6 Leverage general MAC architecture
As MAC is extended to the desktop, it will be possible to apply
uniform MAC policy to the OS, desktop and Linux-based
virtualization components. This will provide a basis for a variety
of sophisticated security applications such as a virtualized MLS
desktop with different windows running VMs at different security
levels.
4. Design Considerations
4.1 Consensus in preliminary discussion appears to be that adding
MAC to libvirt will be the most effective approach. Support
may then be extended to virsh, virt-manager, oVirt etc.
4.2 Initially, sVirt should "just work" as a means to isolate VMs,
with minimal administrative interaction. e.g. an option is
added to virt-manager which allows a VM to be designated as
"isolated", and from then on, it is automatically run in a
separate security context, with policy etc. being generated
and managed by libvirt.
4.3 We need to consider very carefully exactly how VMs will be
launched and controlled e.g. overall security ultimately must
be enforced by the host kernel, even though VM launch will be
initially controlled by host userspace.
4.4 We need to consider overall management of labeling both
locally and in distributed environments (e.g. oVirt), as well
as situations where VMs may be migrated between systems,
backed up etc.
One possible approach may be to represent the security label
as the UUID of the guest and then translate that to locally
meaningful values as needed.
4.5 MAC controls/policy will need to be considered for any control
planes (e.g. /dev/kvm).
4.6 We need to ensure that we have high-level management tools
available from the start, avoiding past mistakes with SELinux
where we dropped a bunch of complicated pieces in the user's
lap. All aspects of sVirt must be managed by the via the virt
tools and only present high-level abstractions to the user
(and then, only if essential).
4.7 As sVirt involves creating and managing arbitrary numbers of
security labels, we will need to address the effects of label
space explosion and resulting complexity.
Possible approaches already discussed include:
- SELinux RBAC or IBAC mechanisms.
- MCS labels. This has the possible advantage of not
requiring any policy changes for simple isolation: just
have a general policy which applies to all MCS labels, and
possibly customize behavior via the type.
e.g.
system_u:object_r:virt_image_t:c1
^ ^
type mcs label
'c0' = isolated inactive VM image/device.
'cN' = dynamically assigned MCS label for active VM, bound
to the UUID, and translated via MCS translation
file. i.e. a user running ls -Z or ps -Z will see
the UUID instead of cN.
'virt_image_t' = standard VM which is also isolated if an
MCS label is present.
'virt_image_nonet_t' = VM with no network access at all.
etc.
So, MCS is used to enforce VM isolation, Type is used to
enforce general security behavior. We can then provide a
high-level GUI interface for selecting this behavior
without the admin knowing anything about SELinux.
Note: proof of concept testing has been performed using
MCS labels, which appears to be workable at this stage.
- Utilize the new hierarchical types being proposed upstream by
NEC. (No analysis done yet).
4.8 Accessing images via shared storage will present challenges as
we do not yet have labeling for networked filesystems.
4.9 We must ensure that any MAC support integrated into libvirt is
readily debuggable. e.g. hook into auditsp to actively
process policy violations and handle them via the virt
toolchain; also develop good setroubleshoot plugins.
4.10 {lib}semanage needs performance optimization work to reduce
impact on the virt toolchain.
------------------------------------------------------------------------
16 years, 4 months
[libvirt] fail to run virsh
by Jun Koi
Hi,
I installed libvirt (cvs version), and can confirm that libvirtd is
running. However, virsh failed to work. I got the below message when
running virsh with debugging information.
How to fix this problem?
Many thanks,
Jun
# LIBVIRT_DEBUG=1 virsh
DEBUG: libvirt.c: virInitialize (register drivers)
DEBUG: libvirt.c: virConnectOpenAuth (name=(null), auth=0xb7f53b84, flags=0)
DEBUG: libvirt.c: do_open (Probed qemu:///system)
DEBUG: lxc_driver.c: lxcCheckContainerSupport (clone call returned
EINVAL, container support is not enabled)
DEBUG: libvirt.c: do_open (Using qemu:///system as default URI, 1
hypervisor found)
DEBUG: libvirt.c: do_open (name "qemu:///system" to URI components:
scheme qemu
opaque (null)
authority (null)
server (null)
user (null)
port 0
path /system
)
DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...)
DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 1 (QEMU) ...)
DEBUG: libvirt.c: do_open (driver 1 QEMU returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 2 (Xen) ...)
DEBUG: libvirt.c: do_open (driver 2 Xen returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 3 (OPENVZ) ...)
DEBUG: libvirt.c: do_open (driver 3 OPENVZ returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 4 (LXC) ...)
DEBUG: libvirt.c: do_open (driver 4 LXC returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 5 (remote) ...)
DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = qemu:///system)
libvir: Remote error : No such file or directory
DEBUG: libvirt.c: do_open (driver 5 remote returned ERROR)
DEBUG: hash.c: virUnrefConnect (unref connection 0x806b588 qemu:///system 1)
DEBUG: hash.c: virReleaseConnect (release connection 0x806b588 qemu:///system)
error: failed to connect to the hypervisor
16 years, 4 months
[libvirt] [PATCH] fix minor typo
by John Levon
Fix a typo in the message for the 'dump' command in virsh.
Signed-off-by: John Levon <john.levon(a)sun.com>
Index: src/virsh.c
===================================================================
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.157
diff -u -r1.157 virsh.c
--- src/virsh.c 22 Jul 2008 16:12:01 -0000 1.157
+++ src/virsh.c 13 Aug 2008 15:50:09 -0000
@@ -1320,7 +1320,7 @@
return FALSE;
if (virDomainCoreDump(dom, to, 0) == 0) {
- vshPrint(ctl, _("Domain %s dumpd to %s\n"), name, to);
+ vshPrint(ctl, _("Domain %s dumped to %s\n"), name, to);
} else {
vshError(ctl, FALSE, _("Failed to core dump domain %s to %s"),
name, to);
16 years, 4 months
[libvirt] Reusing dumpxml output
by Stefan de Konink
I would like to reuse configurations that have been edited using the
libvirt api. For example by attaching interfaces.
Now the output that dumpxml generates, is very 'specific' to an active
configuration. I am not able to use a stored configuration from an active
domain to redefine it after it has been undefined. Is there a trick to do
so? Or should one really strip all 'live' attributes first?
Stefan
16 years, 4 months
[libvirt] breaking out of virsh console?
by Schroeder, Paul
Hello all...
In my VM's inittab, I set agetty to run on ttyS0 so I could do "virsh
console myvm" and log in from the host machine's command line. It works
perfectly. Trouble is, I don't know how to break out of it to get back
to the command line on my host. I've only been able to do so by killing
the virsh process. There's gotta be a better way.. Right?
Thanks...Paul...
16 years, 4 months
[libvirt] VMWare support, any news?
by Yushu Yao
Hi All,
I noticed there are some discussion about VMWare support of libvirt
several back in April-May. Just wondering is there a prototype yet?
The function I¹m interested in is to stop/start a VM by VMWare
player/workstation/free server.
Thanks,
-Yushu
16 years, 4 months
[libvirt] [PATCH] get memory in openvz driver
by Evgeniy Sokolov
OpenVZ has several parameters for memory management. All of them can be
configured independetly.
Patch allow to get configuration of memory from container config and
then calculate total usage of memory.
It is open question how to manage memory?
16 years, 4 months
[libvirt] [PATCH] kvm/virtio: Set IFF_VNET_HDR when setting up tap fds
by Mark McLoughlin
Hey,
Here's a patch that allows libvirt created guests to use KVM's recent
GSO support in order to increase the throughput achieved with virtio_net
network interfaces.
We shouldn't apply this yet - we need the kernel and kvm TUNGETIFF
patches to be applied first - so this is just intended as an RFC.
See also:
http://marc.info/?l=linux-netdev&m=121863813904363
and:
http://marc.info/?l=kvm&m=121863857305255
Cheers,
Mark.
Subject: [PATCH] kvm/virtio: Set IFF_VNET_HDR when setting up tap fds
IFF_VNET_HDR is a tun/tap flag that allows you to send and receive
large (i.e. GSO) packets and packets with partial checksums. Setting
the flag means that every packet is proceeded by the same header which
virtio uses to communicate GSO/csum metadata.
By enabling this flag on the tap fds we create, we greatly increase
the achievable throughput with virtio_net.
However, we need to be careful to only set the flag when a) KVM has
support for this ABI and b) the value of the flag is queryable using
the TUNGETIFF ioctl.
Signed-off-by: Mark McLoughlin <markmc(a)redhat.com>
Index: libvirt/src/bridge.c
===================================================================
--- libvirt.orig/src/bridge.c 2008-08-13 15:40:34.000000000 +0100
+++ libvirt/src/bridge.c 2008-08-13 15:40:53.000000000 +0100
@@ -275,10 +275,52 @@
#endif
/**
+ * brProbeVnetHdr:
+ * @tapfd: a tun/tap file descriptor
+ *
+ * Check whether it is safe to enable the IFF_VNET_HDR flag on the
+ * tap interface.
+ *
+ * Setting IFF_VNET_HDR enables KVM's virtio_net driver to allow
+ * guests to pass larger (GSO) packets, with partial checksums, to
+ * the host. This greatly increases the achievable throughput.
+ *
+ * It is only useful to enable this when we're setting up a virtio
+ * interface. And it is only *safe* to enable it when we know for
+ * sure that a) qemu has support for IFF_VNET_HDR and b) the running
+ * kernel implements the TUNGETIFF ioctl(), which qemu needs to query
+ * the supplied tapfd.
+ *
+ * Returns 0 in case of success or an errno code in case of failure.
+ */
+static int
+brProbeVnetHdr(int tapfd)
+{
+#if defined(IFF_VNET_HDR) && defined(TUNGETFEATURES) && defined(TUNGETIFF)
+ unsigned int features;
+ struct ifreq dummy;
+
+ if (ioctl(tapfd, TUNGETFEATURES, &features) != 0)
+ return 0;
+
+ if (!(features & IFF_VNET_HDR))
+ return 0;
+
+ if (ioctl(tapfd, TUNGETIFF, &dummy) != -1 || errno != EBADFD)
+ return 0;
+
+ return 1;
+#else
+ return 0;
+#endif
+}
+
+/**
* brAddTap:
* @ctl: bridge control pointer
* @bridge: the bridge name
* @ifname: the interface name (or name template)
+ * @vnet_hdr: whether to try enabling iFF_VNET_HDR
* @tapfd: file descriptor return value for the new tap device
*
* This function creates a new tap device on a bridge. @ifname can be either
@@ -292,6 +334,7 @@
brAddTap(brControl *ctl,
const char *bridge,
char **ifname,
+ int vnet_hdr,
int *tapfd)
{
int id, subst, fd;
@@ -307,6 +350,9 @@
if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
return errno;
+ if (vnet_hdr)
+ vnet_hdr = brProbeVnetHdr(fd);
+
do {
struct ifreq try;
int len;
@@ -315,6 +361,11 @@
try.ifr_flags = IFF_TAP|IFF_NO_PI;
+#ifdef IFF_VNET_HDR
+ if (vnet_hdr)
+ try.ifr_flags |= IFF_VNET_HDR;
+#endif
+
if (subst) {
len = snprintf(try.ifr_name, BR_IFNAME_MAXLEN, *ifname, id);
if (len >= BR_IFNAME_MAXLEN) {
Index: libvirt/src/bridge.h
===================================================================
--- libvirt.orig/src/bridge.h 2008-08-13 15:40:34.000000000 +0100
+++ libvirt/src/bridge.h 2008-08-13 15:40:53.000000000 +0100
@@ -61,6 +61,7 @@
int brAddTap (brControl *ctl,
const char *bridge,
char **ifname,
+ int vnet_hdr,
int *tapfd);
int brSetInterfaceUp (brControl *ctl,
Index: libvirt/src/qemu_conf.c
===================================================================
--- libvirt.orig/src/qemu_conf.c 2008-08-13 15:40:34.000000000 +0100
+++ libvirt/src/qemu_conf.c 2008-08-13 15:41:15.000000000 +0100
@@ -474,6 +474,8 @@
*flags |= QEMUD_CMD_FLAG_DRIVE;
if (strstr(help, "boot=on"))
*flags |= QEMUD_CMD_FLAG_DRIVE_BOOT;
+ if (strstr(help, "IFF_VNET_HDR"))
+ *flags |= QEMUD_CMD_FLAG_VNET_HDR;
if (ver >= 9000)
*flags |= QEMUD_CMD_FLAG_VNC_COLON;
}
@@ -545,7 +547,8 @@
int **tapfds,
int *ntapfds,
virDomainNetDefPtr net,
- int vlan)
+ int vlan,
+ int vnet_hdr)
{
virNetworkObjPtr network = NULL;
char *brname;
@@ -593,7 +596,7 @@
}
if ((err = brAddTap(driver->brctl, brname,
- &net->ifname, &tapfd))) {
+ &net->ifname, vnet_hdr, &tapfd))) {
if (errno == ENOTSUP) {
/* In this particular case, give a better diagnostic. */
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
@@ -1011,9 +1014,16 @@
case VIR_DOMAIN_NET_TYPE_NETWORK:
case VIR_DOMAIN_NET_TYPE_BRIDGE:
{
- char *tap = qemudNetworkIfaceConnect(conn, driver,
- tapfds, ntapfds,
- net, vlan);
+ char *tap;
+ int vnet_hdr = 0;
+
+ if (qemuCmdFlags & QEMUD_CMD_FLAG_VNET_HDR &&
+ net->model && !strcmp(net->model, "virtio"))
+ vnet_hdr = 1;
+
+ tap = qemudNetworkIfaceConnect(conn, driver,
+ tapfds, ntapfds,
+ net, vlan, vnet_hdr);
if (tap == NULL)
goto error;
ADD_ARG(tap);
Index: libvirt/src/qemu_conf.h
===================================================================
--- libvirt.orig/src/qemu_conf.h 2008-08-13 15:40:34.000000000 +0100
+++ libvirt/src/qemu_conf.h 2008-08-13 15:41:15.000000000 +0100
@@ -47,6 +47,7 @@
QEMUD_CMD_FLAG_DRIVE = (1 << 3),
QEMUD_CMD_FLAG_DRIVE_BOOT = (1 << 4),
QEMUD_CMD_FLAG_NAME = (1 << 5),
+ QEMUD_CMD_FLAG_VNET_HDR = (1 << 6),
};
/* Main driver state */
16 years, 4 months
