[libvirt PATCH 0/2] kbase: Reorder contents for rpm-deployment
Andrea Bolognani (2): kbase: Reorder sections kbase: Reorder deployments docs/kbase/rpm-deployment.rst | 134 +++++++++++++++++----------------- 1 file changed, 67 insertions(+), 67 deletions(-) -- 2.38.1
Users are likely more interested in the main deployment scenarios than in the detailed list of every existing RPM package. Reorder sections accordingly. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- docs/kbase/rpm-deployment.rst | 134 +++++++++++++++++----------------- 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst index b5ee7fd827..d1180fb0c3 100644 --- a/docs/kbase/rpm-deployment.rst +++ b/docs/kbase/rpm-deployment.rst @@ -20,6 +20,73 @@ of the drivers will be disabled at build time, so not all of the packages listed on this page will exist. +Deployment choices +================== + +Client only install +------------------- + +If an application is capable of using multiple different virtualization drivers +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 hypervisor 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 host. +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 minimise +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 a lot 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 can +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. + + RPM packages ============ @@ -308,70 +375,3 @@ RPM packages between libvirt and its daemons. Since production deployments should all be using a TLS encrypted, this only useful for development hosts with a libvirt daemon configured without encryption. - - -Deployment choices -================== - -Client only install -------------------- - -If an application is capable of using multiple different virtualization drivers -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 hypervisor 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 host. -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 minimise -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 a lot 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 can -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. -- 2.38.1
On 12/14/22 11:39, Andrea Bolognani wrote:
Users are likely more interested in the main deployment scenarios than in the detailed list of every existing RPM package. Reorder sections accordingly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- docs/kbase/rpm-deployment.rst | 134 +++++++++++++++++----------------- 1 file changed, 67 insertions(+), 67 deletions(-)
Reviewed-by: Jim Fehlig <jfehlig@suse.com> Regards, Jim
diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst index b5ee7fd827..d1180fb0c3 100644 --- a/docs/kbase/rpm-deployment.rst +++ b/docs/kbase/rpm-deployment.rst @@ -20,6 +20,73 @@ of the drivers will be disabled at build time, so not all of the packages listed on this page will exist.
+Deployment choices +================== + +Client only install +------------------- + +If an application is capable of using multiple different virtualization drivers +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 hypervisor 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 host. +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 minimise +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 a lot 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 can +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. + + RPM packages ============
@@ -308,70 +375,3 @@ RPM packages between libvirt and its daemons. Since production deployments should all be using a TLS encrypted, this only useful for development hosts with a libvirt daemon configured without encryption. - - -Deployment choices -================== - -Client only install -------------------- - -If an application is capable of using multiple different virtualization drivers -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 hypervisor 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 host. -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 minimise -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 a lot 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 can -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.
List the various options so that the most likely ones come first. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- docs/kbase/rpm-deployment.rst | 52 +++++++++++++++++------------------ 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst index d1180fb0c3..31805c2280 100644 --- a/docs/kbase/rpm-deployment.rst +++ b/docs/kbase/rpm-deployment.rst @@ -23,32 +23,6 @@ listed on this page will exist. Deployment choices ================== -Client only install -------------------- - -If an application is capable of using multiple different virtualization drivers -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 hypervisor 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 host. -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 --------------------------------- @@ -65,6 +39,21 @@ footprint of the daemons is also relatively large since a lot of code is loaded. +Client only install +------------------- + +If an application is capable of using multiple different virtualization drivers +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 hypervisor 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`. + + Minimal features for one virt driver ------------------------------------ @@ -87,6 +76,17 @@ and host devices, leaving only the bare minimum functionality for managing KVM guests. +Every possible virt driver +-------------------------- + +There is rarely a need to install every virt driver at once on a given host. +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. + + RPM packages ============ -- 2.38.1
On 12/14/22 11:39, Andrea Bolognani wrote:
List the various options so that the most likely ones come first.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- docs/kbase/rpm-deployment.rst | 52 +++++++++++++++++------------------ 1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst index d1180fb0c3..31805c2280 100644 --- a/docs/kbase/rpm-deployment.rst +++ b/docs/kbase/rpm-deployment.rst @@ -23,32 +23,6 @@ listed on this page will exist. Deployment choices ==================
-Client only install -------------------- - -If an application is capable of using multiple different virtualization drivers -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 hypervisor 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 host. -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 ---------------------------------
@@ -65,6 +39,21 @@ footprint of the daemons is also relatively large since a lot of code is loaded.
+Client only install +------------------- + +If an application is capable of using multiple different virtualization drivers +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 hypervisor 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`. + +
IMO, these days the "Minimal features for one virt driver" is as likely or more so than client-only. But you can choose the color of the shed :-). Reviewed-by: Jim Fehlig <jfehlig@suse.com> Regards, Jim
Minimal features for one virt driver ------------------------------------
@@ -87,6 +76,17 @@ and host devices, leaving only the bare minimum functionality for managing KVM guests.
+Every possible virt driver +-------------------------- + +There is rarely a need to install every virt driver at once on a given host. +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. + + RPM packages ============
participants (2)
-
Andrea Bolognani -
Jim Fehlig