From nobody Mon Feb 9 06:27:11 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1492694024587342.61370560461523; Thu, 20 Apr 2017 06:13:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D0218FD15; Thu, 20 Apr 2017 13:13:42 +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 714CE8FF7F; Thu, 20 Apr 2017 13:13:42 +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 1EE2618523D2; Thu, 20 Apr 2017 13:13:24 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v3KD6Dtk027908 for ; Thu, 20 Apr 2017 09:06:13 -0400 Received: by smtp.corp.redhat.com (Postfix) id C73D14DA37; Thu, 20 Apr 2017 13:06:13 +0000 (UTC) Received: from beluga.usersys.redhat.com (dhcp129-94.brq.redhat.com [10.34.129.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 277485C886; Thu, 20 Apr 2017 13:06:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9D0218FD15 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=libvir-list-bounces@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9D0218FD15 From: Erik Skultety To: libvir-list@redhat.com Date: Thu, 20 Apr 2017 15:05:54 +0200 Message-Id: In-Reply-To: References: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Cc: Erik Skultety Subject: [libvirt] [PATCH v2 04/10] docs: Utilize our XSLT list generating template more 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: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 20 Apr 2017 13:13:43 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Since we do have this template at hand, why not using it wherever possible (list of supported pool types and remote access section). Also, perform some stylistic micro adjustments. Signed-off-by: Erik Skultety --- docs/remote.html.in | 106 +++++++++++++++--------------------------------= ---- docs/storage.html.in | 62 ++++++------------------------ 2 files changed, 41 insertions(+), 127 deletions(-) diff --git a/docs/remote.html.in b/docs/remote.html.in index 443683d51..117ee3477 100644 --- a/docs/remote.html.in +++ b/docs/remote.html.in @@ -7,57 +7,11 @@ Libvirt allows you to access hypervisors running on remote machines through authenticated and encrypted connections.

- -

+
    + +

    Basic usage -

    +

    On the remote machine, libvirtd should be running in general. See the section @@ -95,9 +49,9 @@ relating to failures in the remote transport itself.

  • Remote calls are handled synchronously, so they will be much slower than, say, direct hypervisor calls.
    • -

    +

    Transports -

    +

    Remote libvirt supports a range of transports:

    @@ -156,9 +110,9 @@ netcat is required on the remote side.

    The default transport, if no other is specified, is tls.

    -

    +

    Remote URIs -

    +

    See also: documentation on ordinary ("local") URIs.

    @@ -203,9 +157,9 @@ and use a different known_hosts file. Connect to a remote host using a ssh connection with the libssh driver and use a different known_hosts file. -

    +

    Extra parameters -

    +

    Extra parameters can be added to remote URIs as part of the query string (the part following ?). @@ -409,12 +363,12 @@ Note that parameter values must be Example: sshauth=3Dprivkey,agent -

    +

    Generating TLS certificates -

    -

    +

    +

    Public Key Infrastructure set up -

    +

    If you are unsure how to create TLS certificates, skip to the next section. @@ -517,9 +471,9 @@ next section.

  • For the root user, the global default locations will always be = used.
    • -

    +

    Background to TLS certificates -

    +

    Libvirt supports TLS certificates for verifying the identity of the server and clients. There are two distinct checks involved: @@ -552,9 +506,9 @@ they have a valid certificate issued by the CA for thei= r own IP address. You may want to change this to make it less (or more) permissive, depending on your needs.

    -

    +

    Setting up a Certificate Authority (CA) -

    +

    You will need the GnuTLS certtool program documented here. In Fedora, it is in the @@ -623,9 +577,9 @@ This is all that is required to set up your CA. Keep t= he CA's private key carefully as you will need it when you come to issue certificates for your clients and servers.

    -

    +

    Issuing server certificat= es -

    +

    For each server (libvirtd) you need to issue a certificate with the X.509 CommonName (CN) field set to the hostname @@ -706,9 +660,9 @@ which can be installed on the server as /etc/pki/libvirt/servercert.pem. -

    +

    Issuing client certificat= es -

    +

    For each client (ie. any program linked with libvirt, such as virt-manager) @@ -759,9 +713,9 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem -

    +

    Troubleshooting TLS certifica= te problems -

    +
    failed to verify client's certificate
    @@ -777,9 +731,9 @@ tell you enough to diagnose the problem. to analyze the setup on the client or server machines, preferably as root. It will try to point out the possible problems and provide solutions to fix the set up up to a point where you have secure remote access.

    -

    +

    libvirtd configuration fil= e -

    +

    Libvirtd (the remote daemon) is configured from a file called /etc/libvirt/libvirtd.conf, or specified on @@ -945,9 +899,9 @@ Blank lines and comments beginning with # = are ignored. -

    +

    IPv6 support -

    +

    The libvirtd service and libvirt remote client driver both use the getaddrinfo() functions for name resolution and are @@ -958,9 +912,9 @@ address resolved for a service is reachable over IPv6, = then an IPv6 connection will be made, otherwise IPv4 will be used. In summary it should just 'do the right thing(tm)'.

    -

    +

    Limitations -

    + =20 =20 -

    iSCSI volume pools

    +

    iSCSI pool

    This provides a pool based on an iSCSI target. Volumes must be pre-allocated on the iSCSI server, and cannot be created via @@ -473,7 +433,7 @@ The iSCSI volume pool does not use the volume format type element.

    =20 -

    SCSI volume pools

    +

    SCSI pool

    This provides a pool based on a SCSI HBA. Volumes are preexisting SC= SI LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX nam= es @@ -505,7 +465,7 @@ The SCSI volume pool does not use the volume format type element.

    =20 -

    Multipath pools

    +

    Multipath pool

    This provides a pool that contains all the multipath devices on the host. Therefore, only one Multipath pool may be configured per host. @@ -538,7 +498,7 @@ The Multipath volume pool does not use the volume format type elemen= t.

    =20 -

    RBD pools

    +

    RBD pool

    This storage driver provides a pool which contains all RBD images in a RADOS pool. RBD (RADOS Block Device) is part @@ -611,7 +571,7 @@ The RBD pool does not use the volume format type element.

    =20 -

    Sheepdog pools

    +

    Sheepdog pool

    This provides a pool based on a Sheepdog Cluster. Sheepdog is a distributed storage system for QEMU/KVM. @@ -670,7 +630,7 @@ The Sheepdog pool does not use the volume format type element.

    =20 -

    Gluster pools

    +

    Gluster pool

    This provides a pool based on native Gluster access. Gluster is a distributed file system that can be exposed to the user via @@ -756,7 +716,7 @@ pool type.

    =20 -

    ZFS pools

    +

    ZFS pool

    This provides a pool based on the ZFS filesystem. Initially it was d= eveloped for FreeBSD, and since 1.3.2 experiment= al support @@ -794,7 +754,7 @@

    The ZFS volume pool does not use the volume format type element.

    -

    Vstorage pools

    +

    Vstorage pool

    This provides a pool based on Virtuozzo storage. Virtuozzo Storage is a highly available distributed software-defined storage with built-in --=20 2.12.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list