From nobody Wed Apr 24 21:35:41 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434091; cv=none; d=zohomail.com; s=zohoarc; b=VtlOtDfGgTZ3JrJ66ahUTUaOBJr/5y+8c8nvJa+mXhttqpgOON9++qbTTVQWapIoYfmUVEZaqZougt2M1Y3eNPynX5G4n4xEAvuX7wKuQeMAnTBHc64a2kfEHOzeLPZhCRd1Qw2ycoGTXzctd2xzjsj/gxi7x838MTgLfvReKGA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434091; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=VdZVLUN98lJgC4QByX/XJTT3YfqFHk8E+zDd8LmG/v8=; b=csSyToomvW4RgDgaqsVLYs13ng+tBsqnA48N4I8LAKAjhLV5s/aFvKfaqewqqDsY27/ZBHo3vLLJuLVAYb+QbGomDFBqYGBx+MjbsKC/eIsSt9OZYlRWVHeRBrL8tgX0UES3+kUgkzczWxLpbkg1ROjzCuEc3gDZtDpHUqVPDLY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1574434091327296.23767059197667; Fri, 22 Nov 2019 06:48:11 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-45-RDdIR6A8PGKoAWXcPWPUzA-1; Fri, 22 Nov 2019 09:48:07 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 70223100551D; Fri, 22 Nov 2019 14:48:00 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3A0551036C80; Fri, 22 Nov 2019 14:48:00 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id AF7F7180880C; Fri, 22 Nov 2019 14:47:59 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElkvb018313 for ; Fri, 22 Nov 2019 09:47:46 -0500 Received: by smtp.corp.redhat.com (Postfix) id 4AE751036C8E; Fri, 22 Nov 2019 14:47:46 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 942A81036C7E; Fri, 22 Nov 2019 14:47:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434090; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=VdZVLUN98lJgC4QByX/XJTT3YfqFHk8E+zDd8LmG/v8=; b=VKiZJhRFHdNvi9BHjS1j1hIhgPbG/62frOm8ufnaZAnEoBb7KkejrpV5zsDoKTXzM6WRlk xqphgZefXMv/qdHfGKTY1/bN2pgutaDNxx1Hw96FXO0nGSnTBoYVE1HK5ybAqBGjYE/qk6 1FdNZS1Lo4re6tFvwwotVDGsRsuelQs= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:47:02 +0000 Message-Id: <20191122144702.3780548-16-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 15/15] docs: add a kbase page about RPM packaging options X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: RDdIR6A8PGKoAWXcPWPUzA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) The libvirt RPM packaging is quite fine grained but it is not obvious to users which package is best to install. Add a kbase doc that describes the different RPMs, and illustrates some example deployment use cases. Signed-off-by: Daniel P. Berrang=C3=A9 --- docs/kbase.html.in | 4 + docs/kbase/rpm-deployment.rst | 410 ++++++++++++++++++++++++++++++++++ 2 files changed, 414 insertions(+) create mode 100644 docs/kbase/rpm-deployment.rst diff --git a/docs/kbase.html.in b/docs/kbase.html.in index 97d3f4c384..a5504a540f 100644 --- a/docs/kbase.html.in +++ b/docs/kbase.html.in @@ -21,6 +21,10 @@ capture
Comparison between different methods of capturing domain state
+ +
RPM deployment
+
Explanation of the different RPM packages and illustration of + which to pick for installation
=20 diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst new file mode 100644 index 0000000000..8f1584d7ea --- /dev/null +++ b/docs/kbase/rpm-deployment.rst @@ -0,0 +1,410 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +RPM Deployment Guidance +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. contents:: + +A complete libvirt build includes a wide range of features, many of which = are +dynamically loadable at runtime. Applications using libvirt typically only +need to use a subset of these features, and so do not require a full insta= ll +of all libvirt RPM packages. + +This document provides some guidance on the RPM packages available with li= bvirt +on Fedora and related distributions, to enable applications and administra= tors +to pick the optimal set for their needs. + +The RHEL and CentOS distributions use the same RPM packaging split, but ma= ny +of the drivers will be disabled at build time, so not all of the packages +listed on this page will exist. + + +RPM packages +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +* libvirt + + This is an empty package that exists solely as a convenient way to insta= ll + every other libvirt RPM package. Almost every deployment scenario would = be + better served by picking one of the other RPMs listed below. + +* libvirt-admin + + The virt-admin tool, used for administrative operations on any libvirt + daemons. Most usefully it allows for logging filters and outputs to be + reconfigured on a running daemon without a restart. This is recommended + to be installed on any host running a libvirt daemon. + + +* libvirt-bash-completion + + Argument auto-completion support for the Bash shell. This is shared code= that + is pulled in by either the libvirt-admin or libvirt-clients RPMs, so the= re is + no need to explicitly ask for this package to be installed. + + +* libvirt-client + + The virsh tool, used for interacting with any libvirt driver, both prima= ry + virt drivers and secondary drivers for storage, networking, etc. All lib= virt + installs should have this installed as it provides a useful way to view = and + debug what is being done by other applications using libvirt. + + +* libvirt-daemon + + The monolithic libvirtd daemon, traditionally used for running all the + stateful drivers. This package does not contain any drivers, so further + packages need to be installed to provide the desired drivers. + + +* libvirt-daemon-config-network + + The sample configuration file providing the 'default' virtual network th= at + enables outbound NAT based connectivity for virtual machines. This is us= eful + on desktop installations, but is not typically desired on server + installations where VMs will use full bridged connectivity. + + +* libvirt-daemon-config-nwfilter + + The sample configuration files providing the network filters for protect= ing + against common malicious guest traffic. This includes protection against= ARP, + MAC and IP spoofing. This is typically desired on server installations, = if + the mgmt app is using libvirt's network filtering features. + + +* libvirt-daemon-driver-interface + + The dynamically loadable driver providing an implementation of the host + network interface management APIs, as well as the virtinterfaced daemon + binary. + + +* libvirt-daemon-driver-libxl + + The dynamically loadable driver providing an implementation of the hyper= visor + APIs for Xen using the libxl library, as well as the virtxend daemon + binary. + + Note that this is a minimal package so does not actually pull in the full + Xen hypervisor package set. This be must requested separately. + + +* libvirt-daemon-driver-lxc + + The dynamically loadable driver providing an implementation of the hyper= visor + APIs for Linux containers, as well as the virtlxcd daemon binary. + + +* libvirt-daemon-driver-network + + The dynamically loadable driver providing an implementation of the virtu= al + network interface management APIs, as well as the virtinterfaced daemon + binary. Typically the libvirt-daemon-config-network RPM will also be des= ired + when this is installed. + + +* libvirt-daemon-driver-nodedev + + The dynamically loadable driver providing an implementation of the host + device management APIs, as well as the virtnodedevd daemon binary. + + +* libvirt-daemon-driver-nwfilter + + The dynamically loadable driver providing an implementation of the host + network firewall management APIs, as well as the virtnwfilterd daemon + binary. + + +* libvirt-daemon-driver-qemu + + The dynamically loadable driver providing an implementation of the hyper= visor + network interface management APIs, as well as the virtqemud daemon + binary. + + Note that this is a minimal package so does not actually pull in the full + QEMU or KVM package set. This be must requested separately. + + +* libvirt-daemon-driver-secret + The dynamically loadable driver providing an implementation of the secret + data management APIs, as well as the virtsecretd daemon binary. + + +* libvirt-daemon-driver-storage + + This is an empty package that exists only as a convenient way to request + installation of all the storage pool drivers. + + If the application only supports a subset of storage pool types, then + a smaller install footprint can be obtained by requesting the individual + drivers. + + +* libvirt-daemon-driver-storage-core + + The dynamically loadable driver providing an implementation of the host + storage pool/volume management APIs, as well as the virtstoraged daemon + binary. + + Note that this is a minimal package so does not actually pull in any pool + implementations. + + +* libvirt-daemon-driver-storage-disk + + The dynamically loadable driver providing an implementation of the disk + partition storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-gluster + + The dynamically loadable driver providing an implementation of the Glust= erFS + file storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-iscsi + + The dynamically loadable driver providing an implementation of the ISCSI + disk storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-iscsi-direct + + The dynamically loadable driver providing an implementation of the ISCSI + network storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-logical + + The dynamically loadable driver providing an implementation of the LVM + storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-mpath + + The dynamically loadable driver providing an implementation of the multi= path + disk storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-rbd + + The dynamically loadable driver providing an implementation of the RBD + network storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-scsi + + The dynamically loadable driver providing an implementation of the SCSI + disk storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-sheepdog + + The dynamically loadable driver providing an implementation of the Sheep= Dog + network storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-storage-zfs + + The dynamically loadable driver providing an implementation of the ZFS + file storage pool type, for the storage pool management APIs. + + +* libvirt-daemon-driver-vbox + + The dynamically loadable driver providing an implementation of the host + network interface management APIs, as well as the virtinterfaced daemon + binary. + + +* libvirt-daemon-kvm + + This is an empty package that exists only as a convenient way to request + installation of all the libvirt features that are relevant to the manage= ment + of KVM guests. This includes the QEMU driver, and the secondary drivers = for + secrets, storage pools, virtual networks, host interfaces, host devices + and network filtering. + + It will also pull in the full set of QEMU features that can be utilized = with + native architecture KVM guests. + + This is a good default for an installation to use KVM if the specific se= t of + required features is not known. To have finer grained control over the + features, the subset of libvirt-daemon-driver-XXX packages should be used + instead. + + +* libvirt-daemon-lxc + + This is an empty package that exists only as a convenient way to request + installation of all the libvirt features that are relevant to the manage= ment + of Linux containers. This includes the LXC driver, and the secondary dri= vers + for secrets, storage pools, virtual networks, host interfaces, host devi= ces + and network filtering. + + This is a good default for an installation to use LXC if the specific se= t of + required features is not known. To have finer grained control over the + features, the subset of libvirt-daemon-driver-XXX packages should be used + instead. + + +* libvirt-daemon-qemu + + This is an empty package that exists only as a convenient way to request + installation of all the libvirt features that are relevant to the manage= ment + of QEMU guests. This includes the QEMU driver, and the secondary drivers= for + secrets, storage pools, virtual networks, host interfaces, host devices + and network filtering. + + It will also pull in the full set of QEMU features that can be utilized = to + emulate any guests architecture supported by QEMU. + + This is a good default for an installation to use QEMU if the specific s= et of + required features is not known. To have finer grained control over the + features, the subset of libvirt-daemon-driver-XXX packages should be used + instead. + + +* libvirt-daemon-vbox + + This is an empty package that exists only as a convenient way to request + installation of all the libvirt features that are relevant to the manage= ment + of KVM guests. This includes the QEMU driver, and the secondary drivers = for + secrets, storage pools, virtual networks, host interfaces, host devices + and network filtering. + + This is a good default for an installation to use VirtualBox if the spec= ific + set of required features is not known. To have finer grained control ove= r the + features, the subset of libvirt-daemon-driver-XXX packages should be used + instead. + + +* libvirt-daemon-xen + + This is an empty package that exists only as a convenient way to request + installation of all the libvirt features that are relevant to the manage= ment + of KVM guests. This includes the QEMU driver, and the secondary drivers = for + secrets, storage pools, virtual networks, host interfaces, host devices + and network filtering. + + It will also pull in the full set of Xen features that can be utilized w= ith + Xen guests. + + This is a good default for an installation to use Xen if the specific se= t of + required features is not known. To have finer grained control over the + features, the subset of libvirt-daemon-driver-XXX packages should be used + instead. + + +* libvirt-devel + + The header files required to build applications, or language bindings ag= ainst + the libvirt C library. This should never be required on a production hos= t, + only development hosts. + +* libvirt-docs + + A local copy of the `libvirt website `_ website con= tent + that matches the deployed version of libvirt. + +* libvirt-libs + + The ELF libraries providing the main application interface to libvirt. T= hese + have stateless drivers (VMWare ESX, HyperV, etc) built-in, and are able = to + take to the libvirt daemons to utilize stateful drivers (QEMU, Xen, BHyv= e, + LXC, VZ, etc). This is needed on all libvirt hosts, both client and serv= er. + +* libvirt-lock-sanlock + + A plugin for locking disks that communicates with the sanlock daemon. It= is + optional and only relevant to hosts with the QEMU driver and oVirt manag= ement + application. + +* libvirt-login-shell + + A simple login shell that automatically spawns an LXC container for the = user + logging in and places them in a shell inside that container. + + +* libvirt-nss + + A NSS plugin that provides hostname resolution for guests attached to a + libvirt virtual network. It is recommended to be installed on any host w= ith + guests using the libvirt virtual network connectivity. + + +* libvirt-wireshark + + A wireshark plugin that allows for dissecting the XDR based RPC protocol= used + between libvirt and its daemons. Since production deployments should all= be + using a TLS encrypted, this only useful for development hosts with a lib= virt + daemon configured without encryption. + + +Deployment choices +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Client only install +------------------- + +If an application is capable of using multiple different virtualization dr= ivers +it is undesirable to force the installation of a specific set of drivers. = In +this case the application will merely wish to request a client only install + +Alternatively if an application is intended to communicate with a hypervis= or on +a remote host there is no need to install drivers locally, only a client is +needed + +The only required package is the `libvirt-libs`, however, it is useful to +also install `libvirt-client`. + + +Every possible virt driver +-------------------------- + +There is rarely a need to install every virt driver at once on a given hos= t. +In the unlikely event that this is needed, however, the `libvirt` package +should be installed. + +Note that this doesn't actually pull in the hypervisors, only the libvirt +code to talk to the hypervisors. + + +Full features for one virt driver +--------------------------------- + +This is a common default installation profile when there is no need to min= imise +the on-disk footprint. + +This is achieved by installing the `libvirt-daemon-XXXX` package for the +virtualization driver that is desired. This will also pull in the default +set of hypervisor packages too. + +Since this installs every possible libvirt feature for the virtualization +driver in question, the on-disk footprint is quite large. The in-memory +footprint of the daemons is also relatively large since alot of code is +loaded. + + +Minimal features for one virt driver +------------------------------------ + +This is the best installation profile when it is desired to minimize the +on-disk footprint. + +This is achieved by installing the individual `libvirt-daemon-driver-XXX` +packages needed for the features that will be used. This will not pull in= the +hypervisor packages, allowing a fine grained set of hypervisor features to= be +chosen separately. + +Since this allows fine grained installation of individual libvirt drivers, +this results in the lowest on-disk footprint. The in-memory footprint of +the daemons is also minimized by reducing the code loaded. + +As an example, the smallest possible installation for running KVM guests c= an +be achieved by installing `libvirt-daemon-driver-qemu` and `qemu-kvm-core`. +This will exclude all the secondary libvirt drivers for storage, networking +and host devices, leaving only the bare minimum functionality for managing +KVM guests. --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list