If you want to access your VM remotely, however, and it is not running, or to clone a new one and activate it, you have a little bit of a problem. We will discuss soon how to use the GUI remotely, but this requires having a home system that runs an X server. Alternately, there are command-line tools to handle all of the virtualization tasks. We will begin to discuss a few of them in this section:

virt-clone  - clone a new VM from an existing VM

virsh - control (start, reboot, examine) a VM

Cloning a new VM

Given a powered-down VM that you want to use as the master, it is simple to clone a new VM using the command-line. The only required arguments to virt-clone are

• the name of the existing virtual machine as -o existingVMname
• the name of the new virtual machine as -n newVMname
• the path to your new virtual machine's disk file (if your existing VM has multiple disk image files this is more complicated):   -f pathtoVMimage

For example, if the master VM is VM-master and you want to use the default naming convention, here's the command to clone VM-master and create a new VM myVM:

virt-clone -o VM-master -n myVM -f /var/lib/libvirt/images/myVM.img

The virsh command 

virsh is used for most command-line operations on VMs. It is fully featured. We will discuss virsh in more detail later, but for now we will just introduce a few virsh commands. You can either start virsh, then issue these commands interactively, or just issue one command from the bash command-line by preceding the command with virsh:

Note: in KVM terminology the name of the VM is called the domain-id.

dominfo domain-id   show the status (running/stopped/managedsave/persistence) of domain-id

list --all    list all known virtual machines (domain-ids) and whether they are running or not.

start domain-id    start the VM

autostart [--disable] domain-id    set (or unset) whether the VM should be autostarted (started when the host is started)

reboot domain-id    issue a reboot command on domain-id

destroy domain-id   hard-reset the domain. (Like pulling the power cord.) This is equivalent to force off in the menu.

managedsave-remove domain-id  deletes the saved image of domain-id. The saved image is created when the host is rebooted and the VM is running. The intention is to resume the VM using the saved image, but sometimes this does not work. If the saved image cannot be restarted you must remove it before you can boot the VM

shutdown domain-id    issue a shutdown command on domain-id (note if a user is logged in on the GUI of the VM this will bring up a confirmation message. The GUI user will have some amount of time to avoid the action. This is true of virsh reboot as well.)

undefine domain-id  --remove-all-storage  delete the XML description for the VM. The VM should first be shutoff first using destroy (or shutdown). Unless you use the --remove-all-storage option, you must physically delete the image file. (As is the case using virt-manager, virsh will sometimes give you an error when it tries to remove the image file. In this case you must remove it by hand at the command-line as root.)

Connecting to the VM remotely

Once your VM is running, you can ssh to it if you know its IP address. In the next section we will change our VMs to use static IP addresses.  If your VM uses DHCP when it starts, it will announce its IP address using ARP. You can use this fact to narrow down the choices for where your VM is.

$ ip neighbor list
192.168.122.228 dev virbr0 lladdr 52:54:00:3d:5d:91 STALE
192.168.1.1 dev eth0 lladdr 00:0f:b5:e7:9b:e0 STALE

You can see from this output that one VM has announced itself as 192.168.122.228. If you had just started your VM and it was using DHCP this would probably be it. Go ahead and try to ssh to it!

(Note: I may have given you a shell script that more reliably finds VMs on the host, called findVMs. Use it if you have it. It is more reliable than ip neighbor list. But the simpler method is to access your VM using its GUI console the first time and immediately change to static addressing!)

Changing your VM to use static addressing

The virtual machine environment on your host will have one or more virtual networks configured. Each VM is on one of these virtual networks.

You can examine the virtual networks on your host using these virsh commands

• net-list  - lists your virtual networks. Our class will have its VMs on a virtual network indicated by our class or on the default network
• net-info name  - lists information about network name.
  
• net-dumpxml name - dumps the XML information for network name. Very important here is the IP address range of the network and the DHCP range of the network. You can examine your VM's XML file using dumpxml name
  

Each virtual network will be divided into DHCP addresses (those given out automatically in response to a DHCP request) and static addresses. All of our virtual networks are /24 (which means there are 256 hosts on the network), and the first and last 5 addresses are reserved (.0 - .4 and .251-.255). The remaining range is broken into static addresses (most of the range - the low numbers) and a smaller area for DHCP addresses.

In an exercise you will allocate a consecutive range of IP addresses for your use using a tool I provide for your class. These addresses will be yours for the duration of the class, and you can use them on any host. This means that once you set your VM to static addressing using one of your IP addresses, you can copy it to any host and it will not conflict with any other addresses in use. This will enable you to backup your VM to another host, should you so desire. When you are assigned a host, you will also be assigned a backup host. We will discuss the use of the backup host later, but, as you more fully configure your VM over the course, you may want to periodically back it up to your backup host.

Changing your VM to use static addressing is very simple. Simply open the Network Connections control panel, edit your ethernet adaptor (which should be eth1), and set it as follows

• make sure it is connected automatically and available to all users
• in the IPV4 panel:

• switch from DHCP to Manual
• add an address. Then enter your IP address in the address box, 255.255.255.0 in the netmask box and duplicate your IP address in the gateway box after changing the last dotted portion to 1
• The DNS server should be the same as the gateway address
• Search paths should be acrc.ccsf.edu,ccsf.edu
  

• The IPv6 panel can be left as automatic or set to Ignore.

You can now reset your VM to a static address using service network restart

Test your VM's configuration by ssh-ing to it from it's host.

libvirtd

libvirtd is a daemon that performs management functions for virtualization guests. This includes providing control interfaces for the guests (such as for starting, stopping, and connected to their consoles) and managing virtual networks.

libvirtd responds to changes in guest configuration that are done through the standard tools such as virsh. If a change is made externally, libvirtd must be restarted. This type of change includes

• editing a guest's XML file by hand.
• copying a guest image and/or XML file into the appropriate directories.
• changing the network interface of the host system

To restart libvirtd simply use service libvirtd restart. The hypervisor will be disconnected, and all the guests in the virt-manager window will disappear until you manually reconnect to the hypervisor (right-click on the virt-manger window and choose Connect OR use virsh connect)

If your virtual machine starts experiencing inexplicable problems such as an inability to connect to the network, a DNS failure, or not seeing a guest that you know is there, you might want to restart libvirtd. Although restarting the service will disrupt any connections to your VM that are managed by libvirtd (such as through the GUI), it will not affect your VM nor any ssh connections to it.

If you restart libvirtd to try to fix a networking problem you may want to restart the network on the VM as well. Of course, this last step will disrupt any ssh connections as well.

auto-updates

Scientific Linux 6 and all 7 systems have an annoying habit of updating themselves each morning. This may not be advisable - sometimes updates can break your system. If you want to disable this, you should take the following corrective actions:

SL6 version - The yum-autoupdate package is probably not installed on your VM, but, if it is, it does the auto updates.

SL7 and RH7 versions - There is a systemd service packagekit-offline-update that is manages auto-updates. It can be disabled using the following commands (in either order)

This will leave the packagekit service enabled, so it will 'inform you' (annoyingly) about updates that are available. If you want to disable that, repeat the commands above using the name packagekit.

Late note: unfortunately, this is much more difficult on RH7. The system insists on running packagekit, even if it is disabled. You can, however, stop it from auto-installing and downloading updates. This, however, requires a dconf configuration, which is beyond our scope in this section. The interested reader is referred to the dconf settings on our host machines under /etc/dconf/db/local.d. Note that adding the corresponding lock file is also advisable.