#33 Some minor refinements
Merged 3 years ago by pboy. Opened 3 years ago by pboy.
pboy/fedora-server main  into  main

Some minor refinements
Peter Boy • 3 years ago  
@@ -10,20 +10,37 @@ 

  ****

  Author: Peter Boy (pboy) | Creation Date: 2021-03-31 | Last update: N/A | Affected Fedora Version(s): 33,34

  ****

- Libvirt is the standard virtualization method in Fedora and provides a management toolkit for KVM / QEMU. This includes a local virtual network for protected communication between the virtual guest systems with each other and with the host. 

+ Qemu-kvm in combination with Libvirt management toolkit is the standard virtualization methodology in Fedora. This includes a local virtual network for protected communication between the virtual guest systems with each other and with the host. 

  

  == Preparation

  

- KVM / QEMU  require hardware virtualization support. The first thing to do is to make sure that it is available.

+ QEMU / KVM require hardware virtualization support. The first thing to do is to make sure that it is available.

  [source,bash]

  ----

  […]# grep --color vmx /proc/cpuinfo

  ----

  The output spans multiple lines. Several times 'vmx' must be highlighted in red. If not, you should first check in the BIOS whether virtualization is disabled. 

  

- Libvirt stores its data including the image files of the virtual hard disk(s) for the guest systems in /var/lib/libvirt. If you adhere to the default partitioning concept, the libvirt application data is stored in its own logical volume that you have to create in advance. You need to specify the size of the memory area, a unique name, and the accommodating VG (fedora_fedora in case of default partitioning). In the new logical volume, create an xfs file system and mount at /var/lib/libvirt. 

+ Libvirt stores its data including the image files of the virtual hard disk(s) for the guest systems in /var/lib/libvirt. If you adhere to the default partitioning concept, the libvirt application data is stored in its own logical volume that you have to create in advance. You need to specify the size of the storage area, a unique name, and the accommodating VG (fedora_fedora in case of default partitioning). In the new logical volume, create an xfs file system and mount at /var/lib/libvirt. 

  

- The easiest way is to use Cockpit. Select the target volume group in the device list (At the top of the right column).  to create a logical volume, e.g. named libvirt, format it with XFS and mount it at the position /var/lib/libvirt. Cockpit creates this directory automatically. 

+ === Cockpit

+ 

+ The easiest way is to use Cockpit. Start your favorite browser and navigate to your server, named example.com here.

+ [source,bash]

+ ----

+ https://example.com:9090

+ ----

+ If there is no valid public certificate installed so far, a browser warning appears and you have to accept an exception for the self-signed certificate. The subsequent login can use either the root account or an unprivileged administrative user account.

+ 

+ In Cockpit select "Storage" in the left navigation column and then the target volume group in the device list at the top of the right column of the opening window. The center content area changes to show the selected volume group at the top and a list of existing logical volumes below it that may be empty for now. 

+ 

+ To create a logical volume select "Create logical volume" next to the 'Logical volumes' section title. In the form that opens, fill in the name of the new logical volume at the top, e.g. in this case 'libvirt'. Leave the usage field as 'File system' and adjust the size at the bottom, e.g. 500 GiB. Then create the LV.  

+ 

+ In the 'Logical volumes' list, a new line appears with the LV name, libvirt in this example, as part of the device part on the right side. Expand that line and select 'format' on the right side. In the form that opens, fill in the name of the new file system, e.g. in this case 'libvirt', and the mount point, /var/lib/libvirt in this case. Leave the other fields at their default values.  Select 'Format' and Cockpit will handle everything else.

+ 

+ After completion, the file system is immediately available and is also permanently configured in the system accordingly.

+ 

+ === Command line

  

  Some administrators may prefer the command line for easy scripting. Adjust size and VG name accordingly.

  [source,bash]
@@ -76,7 +93,7 @@ 

  

  The internal network should be used for the internal, protected communication of the VMs with each other and with the host. For this purpose, it is advantageous to set up a DNS for the internal network so that the VMs can be addressed by their names.

  

- The first step is to decide about a domain name. A top-level ".local" is explicitly not recommended, nor taking one if the official top-level names. But for example, you can take the official domain name and replace the top-level domain with 'lan' or 'internal'. The example domain example.com then becomes example.lan. We use that one throughout this tutorial. The host gets the name  host.example.lan.

+ The first step is to decide about a domain name. A top-level ".local" is explicitly not recommended, nor taking one if the official top-level names. But for example, you can take the official domain name and replace the top-level domain with 'lan' or 'internal'. An official domain example.com would translate to an internal domain example.lan. We use that one throughout this tutorial. The host gets the internal name host.example.lan.

  

  Modify libvirt default network

  [source,xml]
@@ -160,3 +177,5 @@ 

  […]# ping host.example.com

  […]# ping guardian.co.uk

  ----

+ 

+ Virtualization is now ready to use on the server and you can start setting up guest VMs.

@@ -4,7 +4,7 @@ 

  

  [NOTE]

  ====

- Work in progress! 

+ **Beta 1**! Please comment on server mailing list

  ==== 

  [sidebar]

  ****
@@ -40,7 +40,7 @@ 

  […]# sha256sum --ignore-missing -c *-CHECKSUM  

  ----

  +

- Because the *CHECKSUM file contains the values for all cloud images, we ignore th missing. So the check should result in one OK.

+ Because the *CHECKSUM file contains the values for all cloud images, we ignore the missing. So the check should result in one OK.

  

  2. Check the forwarding configuration:

  +
@@ -93,7 +93,7 @@ 

  

  === Installation alternative 1: minimal configuration effort

  

- This type of installation uses the --cloud-init parameter without any value or subparameters. This approach causes the generation and display of a root password shortly after the start of installation, enabling a one-time login. You have to note or copy it. To get the full benefit, DHCP should be available for all Ethernet interfaces. Otherwise, the interface will be set up, but no connection will be established. Beyond that cloud-init is executed with sensible default settings.  Finally, it is deactivated and not executed during subsequent boot processes.

+ This type of installation uses the --cloud-init parameter without any value or subparameters. This approach causes the generation and display of a root password shortly after the start of installation, enabling a one-time login. You have to note or copy it, of course. To get the full benefit, DHCP should be available for all Ethernet interfaces. Otherwise, the interface will be set up, but no connection will be established. Beyond that cloud-init is executed with sensible default settings.  Finally, it is deactivated and not executed during subsequent boot processes.

  

  The installation begins by creating a copy of the download image as a (fully installed) virtual disk in the directory /var/lib/libvirt/images, by convention the virtual disk pool. 

  
@@ -124,27 +124,26 @@ 

  

  ----

  You see a lot of output:

- [source,bash]

+ [source,text]

  ----

  WARNING  Defaulting to --cloud-init root-password-generate=yes,disable=yes

- Installation startet …


+ 

+ Starting install...

  Password for first root login is: OtMQshytI0E8xZGD


  Installation will continue in 10 seconds (press Enter to skip)...

- Running text console command: …


- Connected to Domain: VM_NAME


+ Connected to Domain: VM_NAM


  Escape character is ^] (Ctrl + ])


- [    0.000000] Linux version 5.8.15-301.fc33.x86_64 (mockbuild@bkernel01.iad2.fedoraproject

+ [    0.000000] Linux version … … …

  …


  …


  …


- [   29.271451] cloud-init[721]: Cloud-init v. 19.4 finished ... 

- Datasource DataSourceNoCloud …


+ […] cloud-init[757]: Cloud-init v. 20.4 finished …  Datasource DataSourceNoCloudc …

  [FAILED] Failed to start Execute cloud user/final scripts.


  See 'systemctl status cloud-final.service' for details.


  [  OK  ] Reached target Cloud-init target.



  

- Fedora 33 (Cloud Edition)


- Kernel 5.8.15-301.fc33.x86_64 on an x86_64 (ttyS0)

+ Fedora 34 (Cloud Edition)


+ Kernel 5.11.12-300.fc34.x86_64 on an x86_64 (ttyS0)

  

  localhost login:

  ----
@@ -189,21 +188,16 @@ 

  # ping host.example.com

  # ping guardian.co.uk

  ----

- The VM can connect to internal and external destinations.

+ The VM can connect to internal and external destinations. The name resolution for the vm itself can't work because the static hostname is not set yet.

  

- If your DHCP server provides dynamic DNS as well, you should be able to connect to your VM from the public network:

- [source,]

- ----

- ping VM_NAME.example.com

- ----

- Network should work fine out of the box. Internal and external network access is working.

+ The network configuration is stored in /etc/sysconfig/network-scripts. There is only a file for the first, external interface. The internal interface to libvirt virbr0 is generated with every boot process.

  

  In case the virtual disk size has been changed, the partition sizes must be adjusted.

  [source,bash]

  ----

  […]# cfdisk  /dev/vda

  ----

- Select resize an than write.

+ The only partition should already have the adjusted size. Otherwise select resize and then write.

  

  What remains is the resizing of the file system.

  [source,bash]
@@ -219,7 +213,13 @@ 

  

  Exit and close the console by <ctrl>+].

  

- You may reboot and than check /var/lib/libvirt/dnsmasq/virbr0.status again. It’s now listing a hostname, name resolution is working now.

+ You may reboot the VM and than check /var/lib/libvirt/dnsmasq/virbr0.status again. It’s now listing a hostname, internal name resolution is working now.

+ 

+ If your external DHCP server provides dynamic DNS as well, you should be able to connect to your VM from the public network:

+ [source,batch]

+ ----

+ […]# ping VM_NAME.example.com

+ ----

  

  Last action is to enable autostart of the VM.

  [source,]
@@ -246,9 +246,9 @@ 

  The file referenced by *_meta-data_* contains information about the runtime environment, including a static network configuration, if required. Here only the mandatory parameter instance-id is filled in, which must be unique in a cloud environment, but can be chosen arbitrarily in a nocloud environment.

  [source,]

  ----

- […]# mkdir /var/lib/libdir/boot/cloud-init 


- […]# vim /var/lib/libdir/boot/cloud-init/meta-data 


- instance-id: web-app

+ […]# mkdir /var/lib/libvirt/boot/cloud-init 


+ […]# vim /var/lib/libvirt/boot/cloud-init/meta-data 


+ instance-id: myapp

  ----

  According to specifications a static network connection is configured in meta-data. Basically it works. But some – obviously long standing – bugs require manual intervention in any case. So it is easier to make an adjustment manually on the basis of the default initialization in the other, custom specific file user-data.

  
@@ -260,20 +260,20 @@ 

  1. Setting the hostname 

  2. Set up the user root, the public RSA key is copied into the file as well as set up the fallback account "hostmin" (or alike) which should also be able to log in by password. It will be assigned to the group wheel and his public key will be copied into the file

  3. Set up a first-time password for both users for initial login and to be changed immediately

- 4. Install required additional packages, e.g. the firewall, fail2ban, postfix (needed by fail2ban) and the webserver

+ 4. Install required additional packages, e.g. the firewall, fail2ban, postfix (needed by fail2ban) and custom specific software, maybe a webserver

  5. Some packages need additional configuration files

  6. The VM needs an update of all packages

  7. Several configuration commands are required

  a. Optional: convert interface eth0 as static

  b. Assign zone trusted to the interface eth1 (2nd position in the dbus path, so the order of the network parameters when calling libvirt is crucial!) and rename it according to naming convention. The modification also persists to a configuration file (still in /etc/sysconfig/network-scripts/ )

- c. Start the firewall and add the web services

+ c. Start the firewall and add required services

  d. If the size of the virtual disk has been changed, the file system must be updated.

  e. Finally disable cloud-init 

  

  The first line must necessarily contain some kind of shebang, which cloud-init uses to determine the format of the following data. The formatting itself is yaml.

  [source,]

  ----

- […]# vim /var/lib/libdir/boot/cloud-init/user-data

+ […]# vim /var/lib/libvirt/boot/cloud-init/user-data

  #cloud-config

  

  # (1) setting hostname
@@ -284,13 +284,13 @@ 

  # (2) set up root and fallback account including rsa key copied into this file

  users:

    - name: root

-     ssh-authorized-keys:


+     ssh_authorized_keys:


        - ssh-rsa AAAAB3NzaC1yc2EAAAADAQA...jSMt9rC4uKDPR8whgw==

  

    - name: hostmin

      groups: users,wheel

      ssh_pwauth: True

-     ssh-authorized-keys:

+     ssh_authorized_keys:

        - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAIAQDix...Mt9rC4uKDPR8whgw==

        

  # (3) set up a first-time password for both accounts

@@ -378,8 +378,8 @@ 

  [source,bash]

  ----

  […]# virt-install  --name VM_NAME \

-      --memory 3074  --cpu host --vcpus 3 --graphics none\

-      --os-type linux --os-variant fedora33\

+      --memory 3074  --cpu host --vcpus 3 --graphics none \

+      --os-type linux --os-variant fedora33 \

       --import  \

       --graphics none \

       --disk /var/lib/libvirt/images/VM_NAME.qcow2,format=qcow2,bus=virtio \
@@ -388,11 +388,22 @@ 

       --cloud-init meta-data=/var/lib/libvirt/boot/cloud-init/meta-data,user-data=/var/lib/libvirt/boot/cloud-init/user-data

  ----

  It takes some time, be patient. After a while a login prompt is shown. Don’t try to login immediately. After some seconds the initialization process will continue. Finally, you see a message like

+ [source,text]

+ ----

+ ...

+ [  OK  ] Finished Network Manager Wait Online.

+ [  OK  ] Reached target Network is Online.

  

- _[  OK  ] Finished man-db-cache-update.service. A <return> ..._  

+ Fedora 34 (Cloud Edition)

+ Kernel 5.11.12-300.fc34.x86_64 on an x86_64 (ttyS0)

+ 

+ eth0: 192.168.yyy.zzz 2003:ca:xxxx:yyyy:zzzz:aa:bb:cc

+ eth1: 192.168.mmm.nnn 

+ my-vm login:

+ ----

  

  If the network environment issues IP addresses based on MAC addresses via DHCP, add to the the first network configuration the MAC address:

- [source,]

+ [source,text]

  ----

  --network type=direct,source=enpXsY,source_mode=bridge,mac=52:54:00:aa:bb:cc,model=virtio

  ----

no initial comment

Pull-Request has been merged by pboy

3 years ago