From 306124c3475faa9f50bddddb1f2c58bce31657eb Mon Sep 17 00:00:00 2001 From: Jurgen Pole Date: May 22 2023 07:46:43 +0000 Subject: Fix typos --- diff --git a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc index e7a166f..d96e322 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc @@ -141,7 +141,7 @@ refresh]: Specifically, with networks without DHCP you may get a _[FAILED] Failed to start NetworkMan…[0m - Network Manager Wait Online._ -which you savely can ignore for now. +which you safely can ignore for now. We continue with this form in the step after describing the Cockpit way of instantiation. @@ -164,7 +164,7 @@ Fill in the input fields as appropriate and leave "__Connection__" on "__System_ + image::virtualization/diskimg-fedoraserver-03.png[Network re-configuration] + -Modigy Interface tpye to Direct attachment and Source to the physical host external interface. Leave Model and MAC address unchanged! Save bringts you bak zu the Overview screen. +Modify Interface type to Direct attachment and Source to the physical host external interface. Leave Model and MAC address unchanged! Save brings you back to the Overview screen. 5. In the row "Network interfaces" select Add network interface on the right side. + @@ -284,7 +284,7 @@ The virtual server is up and running now, and ready for log in. The initial conf 2. *Optionally: Adjust locale and non-US keyboard layout* + -Users of a non-US keyborad layout probably want to customize the keyboard layout first of all. This facilitates any subsequent operation. First, check the current locale configuration +Users of a non-US keyboard layout probably want to customize the keyboard layout first of all. This facilitates any subsequent operation. First, check the current locale configuration + [source,] ---- @@ -318,11 +318,11 @@ Determine applicable key mapping and apply it […]# localectl set-keymap de-nodeadkeys ---- + -The setting is immediately activ. +The setting is immediately active. 3. *Set hostname* + -A correct hostname is specifically important for DHCP of the internal network to work properly. A correct time is important vor various tasks, sopecifically syncronization. +A correct hostname is specifically important for DHCP of the internal network to work properly. A correct time is important for various tasks, specifically synchronization. + a. __Check hostname__. You need a correct static hostname. + @@ -368,7 +368,7 @@ d. Correct time if necessary: + a. At first *check your interfaces* + -If you followrd the example instantiation above you should find +If you followed the example installation above you should find + [source,] ---- @@ -386,7 +386,7 @@ If you followrd the example instantiation above you should find ... ---- + -If the external interface doesn't provide DHCP you wont find an assigned IP address for enp1s0. That's what we would need to fix next. +If the external interface doesn't provide DHCP you won't find an assigned IP address for enp1s0. That's what we would need to fix next. b. Next let's *check and fix NetworkManager naming* + @@ -425,7 +425,7 @@ We take the external interface as an example here. […]# systemctl restart NetworkManager ---- -d. The interface enp2s0 for the internal libvirt network may show an IPv6 IP, which we don't use. Therefor, you should disable IPv6 on the internal interface +d. The interface enp2s0 for the internal libvirt network may show an IPv6 IP, which we don't use. Therefore, you should disable IPv6 on the internal interface + [source,] ---- @@ -471,7 +471,7 @@ Anyway, you should now test to connect via ssh to the system, if it provides an Fedora Server KVM follows the same storage organization principles as the base installation. The xref:installation/index.adoc#Planning_ahead[Fedora Server Installation Guide] explains the principles and the available choices. You have to make the same choice here. -The distributed disk image features adisk size of about 7 gb. This is not intended as a default value to use but as a starting value for adaptation to the specific installation requirement. You have probably already adjusted the total desired size at the xref:#instantiation_of_a_server_virtual_machine[begin of installation]. If not, shutdown the virtual machine and adjust the size now. As already noted, you need not to be too sparing in the choice. You can easiy enlarge the maximum size later. And thanks to the qcow2 format, it allocates just the space that is actually needed and doesn't waste resources. On the other hand, there is also no reason to be overly generous. +The distributed disk image features a disk size of about 7 gb. This is not intended as a default value to use but as a starting value for adaptation to the specific installation requirement. You have probably already adjusted the total desired size at the xref:#instantiation_of_a_server_virtual_machine[begin of installation]. If not, shutdown the virtual machine and adjust the size now. As already noted, you need not to be too sparing in the choice. You can easiy enlarge the maximum size later. And thanks to the qcow2 format, it allocates just the space that is actually needed and doesn't waste resources. On the other hand, there is also no reason to be overly generous. At this point, we have to specify the allocation and adjustment of the intended maximum disc size. Unfortunately, Cockpit doesn't provide graphical support for editing an existing partition table. So we are bound to CLI for the first step. @@ -539,7 +539,7 @@ As you see, the complete space is occupied by a Logical Volume (LV). 1. Enlarge the LVM partition to file all of the free space and enlarge the root file system alike. In this way, there is no separation of system and user data. This is convenient, but in no way recommendable. 2. Enlarge the LVM partition to file all of the free space and enlarge the root file system to a reasonable value between 10 and 15 gb, depending on the intended total size of the disc. In the free space, the administrator later creates logical volumes for user data as needed. This is the recommended way. 3. Enlarge the existing VG and the root file system to a reasonable size. Create a new VG in the remaining region, which later accommodates LVs for user data. This pushes the separation even further. -4. Enlarge the distributed virtual disk to a reasinable size to accomodate the root file system only and create one or more separate virtual disk(s) to accomodate user data. +4. Enlarge the distributed virtual disk to a reasonable size to accommodate the root file system only and create one or more separate virtual disk(s) to accommodate user data. ==== Alternative 2: Enlarge the VG to fill the disk, and root LV to a reasonable size @@ -628,7 +628,7 @@ For the last 2 steps you can also switch to __Cockpit__. But the 2 lines may not 1. Perform the steps described in alternative 2, but specify the size of the LVM partition by e.g. 20G and the root LV to 12G. In this way, there is still some room for disposition in case of surprises. -2. Use cfdisk zu create a _new partition_, _/dev/vda4_ in this example. of type 'Linux LVM' using the complete remaining diskspace. +2. Use cfdisk to create a _new partition_, _/dev/vda4_ in this example, of type 'Linux LVM' using the complete remaining diskspace. 3. Create a Physical Volume (PV) in the new partition + @@ -656,7 +656,7 @@ Later, use usrvg to create LVs for user data as needed. ==== Alternative 4: Create a separate virtual disk for user data -The prerequisite is that the configuration of the system disk has been completed. Perform the steps described in alternative 2, but enlarge the distribute system virtual diskimage and corresponidingly the VG to e.g. 20G and the root LV to 12G. In this way, there is still some room for disposition in case of surprises. With a separate data disk, alternative 1 would be an option, too. +The prerequisite is that the configuration of the system disk has been completed. Perform the steps described in alternative 2, but enlarge the distributed system virtual diskimage and correspondingly the VG to e.g. 20G and the root LV to 12G. In this way, there is still some room for disposition in case of surprises. With a separate data disk, alternative 1 would be an option, too. You can use either _CLI_ or _Cockpit_ for this step. @@ -746,7 +746,7 @@ Later, use usrvg to create LVs for user data as needed. + image::virtualization/diskimg-fedoraserver-30.png[Cockpit add disk form] + -Most of the input fields are suitably preconfigured. Enter a (file) name for the disk image. Use a consistent naming scheme to facilitate long-term system maintenance. Specify the intended maximum size of the disk and decide on "Always atttach". It is best to leave the other properties untouched. +Most of the input fields are suitably preconfigured. Enter a (file) name for the disk image. Use a consistent naming scheme to facilitate long-term system maintenance. Specify the intended maximum size of the disk and decide on "Always attach". It is best to leave the other properties untouched. + Select _Add_ to complete the task. @@ -768,8 +768,8 @@ It is advisable to review all the tasks in the general xref:installation/postins == Import via CLI and elaborated initial configuration -The procedure described so far work well and efficiently when only one virtual machine is to be set up, or even with multiple machines that differ. +The procedure described so far works well and efficiently when only one virtual machine is to be set up, or even with multiple machines that differ. -To add an elaborated initial configuration is specifically useful, if multiple similiar instantiations are on the agenda. This works very similiar, but uses guestfs-tool's _virt-customize_ before the virt-install step, either by means of command line parameters or a configuration file. +To add an elaborated initial configuration is specifically useful, if multiple similar instantiations are on the agenda. This works very similar, but uses guestfs-tool's _virt-customize_ before the virt-install step, either by means of command line parameters or a configuration file. Details TBD