Virt-Manager and virsh: Remote Administration via SSH - SMB Networks

General index of the series: Computer Networks for SMEs: Introduction

Hello friends!

We hope you have followed our articles published so far, which are:

Precisely in the post Qemu-Kvm + Virt-Manager on Debian - Computer Networks for SMEs, we specify that, having a single workstation with Virt-Manager installed, we can remotely manage as many hypervisors as necessary. In other words, in servers dedicated to virtualization, it is not mandatory to install a Desktop or other graphical environment.

We must do remote servers as indicated in Workstation Installation - Computer Networks for SMEs, or be guided by the next articles in which we will discuss other distributions such as CentOS and maybe OpenSuSE, and later it will only be necessary to install virtualization support in each one of them. In practical terms, on those servers, after a clean installation of the Base Operating System and updating the installed packages according to the available repositories, it will only be necessary to install the packages qemu-sq.m, libvirt-bin y bridge-utils, or some other package specific to each distribution, which does not mean that if we need other programs, we do not install it.

Remote hypervisor «jessie»

The characteristics of this server are the following:

Domain Name: desdelinux.fan
Name of the team : jessie
FQDN: Jessie.desdelinux.fan
IP adress : 10.10.10.5
SubNet: 10.10.10.0/24
RAM : 2G
Hard Drive 1: 20GB
Hard Drive 2: 80GB
Disk 2 mount point: / home / vms
Normal user: buzz
User full name: Debian First OS Buzz

We prepare the hypervisor «Jessie»

Since we don't have a DNS on the network, we will have to continue using the IPs. Vía ssh or directly in the server console, we execute the following commands:

buzz @ sysadmin: ~ $ ssh 10.10.10.5
[email protected]'s password:

buzz @ jessie: ~ $ sudo nano / etc / ssh / sshd_config
# Authentication: LoginGraceTime 120 # PermitRootLogin without-password
AllowRootLogin yes             
Strict Modes yes

buzz @ jessie: ~ $ sudo service ssh restart
buzz @ jessie: ~ $ sudo service ssh status
● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Sun 2016-12-11 12:15:24 EST; 3s ago Main PID: 14960 (sshd)

buzz @ jessie: ~ $ sudo aptitude install qemu-kvm libvirt-bin
[sudo] password for buzz:

After finishing the above operations, we open the Virt Manager in our administration workstation, and we proceed to manage the remote hypervisor «jessie».

In order to make this article more didactic, we have packed all the images for download, and we give the link below, so that while reading the description of the "Step by Step", you can view the images locally in your Viewer. Pictures preferred. We believe that this is much more comfortable. We are doing it while we write the article.

Download images of the «Step by Step» (961.1 kB).

We manage Jessie through the Virt-Manager and Virsh, via SSH

The first thing we must do in our Workstation, is to install a graphical program to manage the Passwords of the users what does he ask of us libvirt remote. It is essential that, to connect remotely, the demon libvirtd is running correctly, and that the chosen user belong to libvirt group on the remote computer, or that is the user himself root.

buzz @ sysadmin: ~ $ sudo aptitude search askpass
p ksshaskpass - interactively prompt users for a passphrase for ssh-add p razorqt-openssh-askpass - OpenSSH helper component for Razor-qt desktop environment p ssh-askpass - under X, asks user for a passphrase for ssh-add p ssh-askpass -fullscreen - Under Gnome2, asks user for a passphrase for ssh-add p ssh-askpass-gnome - interactive X program to prompt users for a passphrase for ssh-add

We chose the ssh-askpass-gnome, because we have installed the MATE-Desktop.

buzz @ sysadmin: ~ $ sudo aptitude install ssh-askpass-gnome

To avoid problems, and following the recommendation of the Virt-Manager itself, which by default points to the user root to connect, is why we allow access to the rootVia ssh, when we prepared the Jessie hypervisor. Note that we did not become a member of the group libvirt to normal user buzz.

Basically, to remotely manage a hypervisor and its virtual machines, we proceed much the same as when we manage the local hypervisor.

Step by Step with downloaded images

  • Imagen 01: The first thing we do is create a New Connection in the Virt-Manager. For this we browse Menu -> + Add connection ... and then a dialog window will open.
  • Imagen 02: Dialog window where we declare the main values ​​of the new connection that we intend to establish:
    • Hypervisor: QEMU / KVM
    • Connect to remote computer by Method: SSH
    • User name: root
    • Name of the team: 10.10.10.5 (we still do not have DNS)
    • Auto connect: implies that when we start the local Virt-Manager, it will try to connect to the remote hypervisor automatically. We suggest do not mark it
    • URIs «Uniform Resource Identifier" generated: qemu+ssh://[email protected]/ System

  • Imagen 03: After pressing the button Connect in the previous step, the program ssh-askpass asks us, if we had not yet made a connection ssh remote prior, if we wish to continue, to which we reply that «Yes»Typed in clear text, even if the dialog window does not show us what we have written. After answering affirmatively, we click on the button OK

  • Imagen 04: Dialog window where we must type the user's password root of the remote hypervisor. After entering, click on OK.
  • Imagen 05: The local Virt-Manager already shows the two connections: the remote one 10.10.10.5 (QEMU), and the local localhost (QEMU). Now, and keeping the remote connection selected, we navigate through the Menu -> Edit -> Connection details, and all the details of the selected connection will be displayed, both informative and configurable.
  • Imagen 06: Eyelash "Review»With the connection details. In it we read that the connection is qemu+ssh://[email protected]/ System. The team name is Jessie.desdelinux.fan. And other details regarding the amount of memory, architecture, CPU usage and memory usage of the remote hypervisor.
  • Imagen 07: Eyelash "Virtual Networks«. In it we see that the network «default" should not Auto start when starting the equipment, that the network is 192.168.122.0/24, which is enabled and with a defined range the DHCP, and that Forwarding is through NAT «Network Address Translation«.

Let's take a parenthesis here and ask ourselves How do we change the default network configuration to the necessary parameters for the enterprise LAN?.

We change the "default" network of the remote hypervisor using virsh

We start the console Virsh

buzz @ sysadmin: ~ $ sudo virsh
[sudo] password for buzz: Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit

We connect with the remote hypervisor team jessie

virsh # connect qemu+ssh://[email protected]/ System
[email protected]'s password:

And we already entered the remote hypervisor

virsh # net-list --all
 Name State Autostart Persistent ---------------------------------------------- ------------ default inactive no yes

virsh #net-info default
Name: default UUID: 18ce4bbb-fddb-4300-9f13-65b4d999690c Active: no Persistent: yes
Autostart: no
Bridge: virbr0

We find the following configuration of the NETWORK default. Note that what is defined is the network bridge interface, and not the network itself. Any machine that we want to connect to the interface virbr0, you must share the same network.

virsh # net-edit default
default 18ce4bbb-fddb-4300-9f13-65b4d999690c 

We modify the network configuration default of the remote hypervisor according to subnet of our corporate LAN, which is 192.168.10.0/24

virsh # net-edit default
default 18ce4bbb-fddb-4300-9f13-65b4d999690cvirbr0'stp =' on 'delay =' 0 '/>192.168.10.1'netmask =' 255.255.255.0 '>

We mark the network default of the remote hypervisor so that self-initiate

virsh # net-autostart default
Network default marked as autostarted

virsh #net-info default
Name: default UUID: 18ce4bbb-fddb-4300-9f13-65b4d999690c
Active: no
Persistent: yes
Autostart: yes
Bridge: virbr0

And finally we start the network default remote hypervisor

virsh # net-start default
Network default started

virsh#net-list
 Name State Autostart Persistent ---------------------------------------------- ------------ default active yes yes

virsh #net-info default
Name: default UUID: 18ce4bbb-fddb-4300-9f13-65b4d999690c
Active: yes
Persistent: yes
Autostart: yes
Bridge: virbr0

After these modifications, we must «Disconnect" and go back to "Connect»The connection with the remote computer in Virt-Manager to view the changes.

Continuation Step by Step with downloaded images

  • Image 07a: Eyelash "Virtual Networks" with the Web default already modified and running
  • Imagen 08: Eyelash "Storage»From the remote hypervisor. Initially we only have the Storage Deposit default, and this one has the option of Auto start. If we are not going to store virtual machine images in the directory / var / lib / libvirt / images for whatever reason, it is recommended to uncheck the option Auto start. In this dialog window, we click on the button «+»To add a new Storage Repository.
  • Imagen 09: It is the first of the wizard to add a new deposit. He Name of the new deposit is jessie-vms-images and is a File System Directory.
  • Imagen 10: Since we have an 80GB disk mounted on / home / vms for the storage of the images, we specify that the Destination path it will be precisely that.
  • Imagen 11: Once the wizard is finished, we return to «Storage»And we find that the new repository already exists, that it has copied a CD image for the creation of new virtual machines, that it is Active, and you have the option Auto start selected. We create a new volume for a new virtual machine, by clicking on the button «New volume«.
  • Imagen 12: The Name of the new volume is samba-ad-dc, its format qcow2 and Maximum capacity dynamic growth is 15GB. In passing we check that in the deposit «jessie-vms-images«, The available capacity before creating the new volume, is 77.95 GB. To finish with the creation of the new volume, we click on the button «Finalize«
  • Imagen 13: Again we return to «Storage»And we check that the image was created correctly. If not, we are going to modify something else in «Connection details«, As is our case, we close the window by clicking on the« buttonX» from the top left, and not through the «File» menu option, because then the Virt-Manager will close and we will have to reopen it. 
  • Imagen 14: We check that the connection is selected in the Virt-Manager 10.10.10.5 (QEMU), because it is where we are going to create a new virtual machine using its assistant. We click on the button «Create a new virtual machine«, Or we sail Menu -> File -> New virtual machine. The wizard is displayed and in the first dialog window it indicates that the Connection is 10.10.10.5 (QEMU / KVM), and we select that we will create the machine from an ISO or CDROM image.
  • Imagen 15: We specify the path of the ISO image. If we click on the button To explore… window opens Locate ISO media volume, we select the deposit jessie-vms-images and in it, to the image debian-8.0.0-amd64-CD-1.iso. After selected, the absolute path to the image is shown /home/vms/debian-8.0.0-amd64-CD-1.iso. Later we indicate that OS type and Version. Finally we click on the button Forward.
  • Imagen 16: In this dialog box we indicate the amount of RAM) and the amount of CPU that we will give to the virtual machine, an amount that logically cannot be greater than that of the Host or Hypervisor equipment.
  • Imagen 17: In addition to selecting Enable storage for this virtual machine, we select which will be the disk image that we will assign to the machine, in the same way that we select the ISO image. In the end we choose the volume /home/vms/samba-ad-dc.qcow2.
  • Imagen 18: We reached the end of the wizard. We indicate that the Name of the Guest will samba-ad-dc; what do we want Customize settings before installing, which we will use to connect to the corporate LAN Virtual network 'default': NAT, and Define a static MAC address for the network interface, which is generated randomly. So far the machine has not been created. When we click on the button Finalize, is when it will be created.
  • Imagen 19: Window that shows us why we choose Customize before installing. By default, the Virt-Manager selects the Default SPICE Monitor. If we have communication or display problems, we can try with the VNC server for this Monitor. If we change any parameter, we must click on the button Apply of each virtual hardware resource. Otherwise, the Virt-Manager complains. 
  • Imagen 20: In the same way as in the previous election, when faced with problems, we tried the VideoDefault Model VMVGA. To start the installation of the newly created Guest remote, we click the button «Start installation».
  • Imagen 21: After the installation has started, and every time we want to connect to a remote virtual machine or Guest, the Virt-Manager will ask us again for the authentication of the user who connected remotely.
  • Imagen 22: Finally we begin with the installation of the Operating System chosen for the remote Guest, just as we do for a physical machine or server.
  • Imagen 23: The Virt-manager with his Guests running, both local and remote.
  • Imagen 24: The virtual machine samba-ad-dc in action.

So far, the Step by Step through commented images, which still seems to me the best method for this type of article. Personally, it is quite annoying for me to pass images and read messages between them. Of course, if you are reading the post from a smartphone, you may prefer the old method. I don't know, it is better to listen to their opinions about the format that I have followed.

Many will wonder if it is possible to execute all the previous steps through a normal console, the command console Virsh, as well as the virt-viewer. The answer is yes. What happens is that it would be a too long and very technical post, and we do not want to overwhelm readers with little experience in Virtualization any more.

If any reader is interested in the how is it done with virsh, please contact us via E..

Next delivery

We are not sure to continue with Workstation with OpenSuSE o CentOS Workstation. Which one do you choose?

Until the next adventure, friends!


Add as preferred source