Kernel-based Virtual Machine (KVM) is a popular virtualization solution supported by modern Linux kernels. It takes advantage of the CPU support for virtualization (Intel VT and AMD-V). You can run unmodified operating systems such as Linux, FreeBSD, and Microsoft Windows using KVM. For more information, see the compatibility list.

The --cdrom parameter points to the installation disc image and the --disk parameter points to the final installed OS image. In this example, we also specify the use of a bridge (the network device br0 in this case) to make it appear on the local host’s network as a regular host. The parameter --graphics specifies Spice as the means of connecting to the VM console.

Naturally, you can also use a GUI (virt-manager) to create the VM, but the command line is more fun, isn’t it? 😉 The man page for virt-install has the requisite information on how to use it. More examples are also available in the man page.

Mounting Raw and qcow2 images in order to inspect and use them doesn’t have to be difficult. After searching the internet, we found a couple of recommendations on how to do it. Here is what we did ourselves on an Ubuntu 16.04 Linux host.

Mounting The Raw Image

Associate the raw image with a loop device:

losetup /dev/loop0 image.raw

Map the partitions to loop devices:

kpartx -a /dev/loop0

You should be able to mount the partitions now:

mount /dev/mapper/loop0p1 /mnt/t01

where /mnt/t01 is a previously-existing mount point or directory.

For LVM partitions, determine the volume group name and activate it:

vgscan
vgchange -ay vg_volgroupname

Mount the desired logical volume:

mount /dev/mapper/vg_volgroupname-lg_logicalgroupname /mnt/t02

where /mnt/t02 is another pre-existing mount point or directory.

Unmounting The Raw Image

Unmount the previously mounted partitions:

umount /dev/t02
umount /dev/t01

Deactivate the volume group:

vgchange -an vg_volgroupname

Undo the mapping of the partitions to the loop devices:

kpartx -d /dev/loop0

Destroy the loop:

losetup -d /dev/loop0

Mounting The qcow2 Image

Here, we shall use the QEMU Network Block Device Driver for the purposes of mounting the qcow2 image.

First, load the nbd driver.

modprobe nbd max_part=63

Connect nbd to the image using qemu-nbd:

qemu-nbd -c /dev/nbd0 disk1.qcow2

Using fdisk, check the existing partitions. Mount the regular Linux partitions as is:

mount /dev/nbd0p1 /mnt/t01

For LVM partitions, associate a loopback device to the LVM partition:

losetup /dev/loop0 /dev/nbd0p2

See the LVM partitions under /dev/mapper:

ls -l /dev/mapper

You should also be able to display the logical partitions using lvdisplay and the volume groups with vgdisplay. Use vgchange as above to activate the volume group.

Mount the regular LVM partitions as usual:

mount /dev/mapper/vg_volgroupname-lv_logicalgroupname /mnt/t02

Unmounting the qcow2 Image

Unmount the partitions from the qcow2 image:

umount /mnt/t02
umount /mnt/t01

Deactivate the volume group:

vgchange -an vg_volgroupname

Remove the loopback device:

losetup -d /dev/loop0

Disconnect the nbd device:

qemu-nbd -d /dev/nbd0

Finally, remove the nbd kernel module:

rmmod nbd

We have successfully used the above procedures in mounting and unmounting raw and qcow2 images used in Linux KVM.

The procedures described above have been adapted for this article from these URLs:

Digital certificates are used to help secure communications across networks, including the Internet. Web servers that are accessed via the HTTPS protocol involve the use of digital certificates on the server side and, in some circumstances, on the client side as well. Signing and encrypting email with the use of S/MIME also involves the use of client and server-side digital certificates. Certain VPN software might also use digital certificates on both sides of the communication line.

The question one might ask is how to get these digital certificates and install them for use by applications on the client and server sides. Usually, organizations and individuals acquire their digital certificates from vendors that participate in an ecosystem of providers officially recognized by applications requiring digital certificates to enable secure communications. These providers are called certificate authorities (CAs).

Organizations can also become CAs within their own domain involving themselves and other parties that communicate with them. Software is readily available to give organizations the ability to become CAs. Platforms such as Linux, Microsoft Windows (Server), and Apple Mac OS have the necessary software to generate digital certificates. OpenSSL is one such software available on most platforms. Note that OpenSSL is not the only software available for this purpose.

Creating A Certificate Authority Digital Certificate

It is possible to become a certificate authority (CA) by generating your own CA digital certificate and private key. The CA digital certificate and private key are used to sign and generate digital certificates for servers and clients for the purpose of encrypting communications and digitally signing digital assets such as software, computer documents and email. The one caveat is that, unless you become one of globally-accepted certificate authorities, your CA is limited to your use within your own organization and with trusted third-parties.

The above commands assume that CA.key, CA.csr, and CA.crt are the private key, certificate signing request, and the CA certificate, respectively. The extension v3_ca refers to a section in the OpenSSL configuration file openssl.cnf that tags the generated certificate as a CA certificate. In CentOS, the configuration file is in /etc/pki/tls. A sample openssl.cnf file is shown at the end of this article.

If an error is encountered about a couple of missing files in /etc/pki/CA, there may be a need to create these files in /etc/pki/CA before generating the certificate:

touch index.txt
echo 00 > serial

Note: Some would generate a subordinate CA using the above root CA certificate. The subordinate CA certificate and private key are then used to generate other certificates while the root CA certificate and private key are kept securely offline unless needed. It is of utmost importance to protect the root CA and private key.

Creating Other Certificates

Once the CA certificate and private key exist, creating other certificates should be reasonably easy: