A console is a graphical window that allows you to view the start up screen, shut down screen, and desktop of a virtual machine, and to interact with that virtual machine in a similar way to a physical machine. In Ybox, the default application for opening a console to a virtual machine is Remote Viewer, which must be installed on the client machine prior to use.

The details on installing/setting up consoles are described in the Console Client Resources page.

Starting Virtual Machines

1. Click the Virtual Machines tab and select a virtual machine with a status of Down.

2. Click the run () button.

   Alternatively, right-click the virtual machine and select Run.

The Status of the virtual machine changes to Up, and the operating system installation begins. Open a console to the virtual machine if one does not open automatically.

Use Remote Viewer to connect to a virtual machine.

Connecting to Virtual Machines

1. Install Remote Viewer if it is not already installed.
2. Click the Virtual Machines tab and select a virtual machine.
3. Click the console button or right-click the virtual machine and select Console.
   • If the connection protocol is set to SPICE, a console window will automatically open for the virtual machine.
   • If the connection protocol is set to VNC, a console.vv file will be downloaded. Click on the file and a console window will automatically open for the virtual machine.

Use Remote Viewer to connect to a virtual machine.

Connecting to Virtual Machines

1. Install Remote Viewer if it is not already installed. See Installing Console Components.
2. Click the Virtual Machines tab and select a virtual machine.
3. Click the console button or right-click the virtual machine and select Console.
   • If the connection protocol is set to SPICE, a console window will automatically open for the virtual machine.
   • If the connection protocol is set to VNC, a console.vv file will be downloaded. Click on the file and a console window will automatically open for the virtual machine.

The ovirt guest agents and drivers are installed on Enterprise Linux virtual machines using the ovirt-engine-guest-agent package provided by the ovirt Agent repository.

Install VirtIO-optimized disk and network device drivers during your Windows installation by attaching the virtio-win.vfd diskette to your virtual machine. These drivers provide a performance improvement over emulated device drivers.

Use the Run Once option to attach the diskette in a one-off boot different from the Boot Options defined in the New Virtual Machine window. This procedure presumes that you added a VirtIO network interface and a disk that uses the VirtIO interface to your virtual machine.

Note: The virtio-win.vfd diskette is placed automatically on ISO storage domains that are hosted on the Engine server. An administrator must manually upload it to other ISO storage domains using the engine-iso-uploader tool.

Installing VirtIO Drivers during Windows Installation

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Run Once.
3. Expand the Boot Options menu.
4. Select the Attach Floppy check box, and select virtio-win.vfd from the drop-down list.
5. Select the Attach CD check box, and select the required Windows ISO from the drop-down list.
6. Move CD-ROM to the top of the Boot Sequence field.
7. Configure the rest of your Run Once options as required.
8. Click OK.

The Status of the virtual machine changes to Up, and the operating system installation begins. Open a console to the virtual machine if one does not open automatically.

Windows installations include an option to load additional drivers early in the installation process. Use this option to load drivers from the virtio-win.vfd diskette that was attached to your virtual machine as A:. For each supported virtual machine architecture and Windows version, there is a folder on the disk containing optimized hardware device drivers.

Use Remote Viewer to connect to a virtual machine.

Connecting to Virtual Machines

1. Install Remote Viewer if it is not already installed.
2. Click the Virtual Machines tab and select a virtual machine.
3. Click the console button or right-click the virtual machine and select Console.
   • If the connection protocol is set to SPICE, a console window will automatically open for the virtual machine.
   • If the connection protocol is set to VNC, a console.vv file will be downloaded. Click on the file and a console window will automatically open for the virtual machine.

The oVirt guest agents and drivers provide additional information and functionality for Enterprise Linux and Windows virtual machines. Key features include the ability to monitor resource usage and gracefully shut down or reboot virtual machines from the User Portal and Administration Portal. Install the oVirt guest agents and drivers on each virtual machine on which this functionality is to be available.

oVirt Guest Drivers

oVirt Guest Agents and Tools

Using IPA (IdM)

To configure single sign-on for Enterprise Linux virtual machines using GNOME and KDE graphical desktop environments and IPA (IdM) servers, you must install the ovirt-engine-guest-agent package on the virtual machine and install the packages associated with your window manager.

Important: The following procedure assumes that you have a working IPA configuration and that the IPA domain is already joined to the Engine. You must also ensure that the clocks on the Engine, the virtual machine and the system on which IPA (IdM) is hosted are synchronized using NTP.

Configuring Single Sign-On for Enterprise Linux Virtual Machines

1. Log in to the Enterprise Linux virtual machine.
2. Enable the required repositories.

3. Download and install the guest agent packages:

   	# yum install ovirt-engine-guest-agent-common
   

4. Install the single sign-on packages:

   	# yum install ovirt-engine-guest-agent-pam-module
   	# yum install ovirt-engine-guest-agent-gdm-plugin
   

5. Install the IPA packages:

   	# yum install ipa-client
   

6. Run the following command and follow the prompts to configure ipa-client and join the virtual machine to the domain:

   	# ipa-client-install --permit --mkhomedir
   

   Note: In environments that use DNS obfuscation, this command should be:

   	# ipa-client-install --domain=FQDN --server==FQDN
   

7. For Enterprise Linux 7.2, run:

   	# authconfig --enablenis --update
   

   Note: Enterprise Linux 7.2 has a new version of the System Security Services Daemon (SSSD), which introduces configuration that is incompatible with the oVirt Engine guest agent single sign-on implementation. The command will ensure that single sign-on works.

8. Fetch the details of an IPA user:

   	# getent passwd IPA_user_name
   

   This will return something like this:

   	some-ipa-user:*:936600010:936600001::/home/some-ipa-user:/bin/sh
   

   You will need this information in the next step to create a home directory for some-ipa-user.

9. Set up a home directory for the IPA user:

   1. Create the new user's home directory:

                 # mkdir /home/some-ipa-user
      

   2. Give the new user ownership of the new user's home directory:

                 # chown 935500010:936600001 /home/some-ipa-user
      

Log in to the User Portal using the user name and password of a user configured to use single sign-on and connect to the console of the virtual machine. You will be logged in automatically.

Using Active Directory

To configure single sign-on for Enterprise Linux virtual machines using GNOME and KDE graphical desktop environments and Active Directory, you must install the ovirt-engine-guest-agent package on the virtual machine, install the packages associated with your window manager and join the virtual machine to the domain.

Important: The following procedure assumes that you have a working Active Directory configuration and that the Active Directory domain is already joined to the Engine. You must also ensure that the clocks on the Engine, the virtual machine and the system on which Active Directory is hosted are synchronized using NTP.

Configuring Single Sign-On for Enterprise Linux Virtual Machines

1. Log in to the Enterprise Linux virtual machine.
2. Enable the oVirt Agent channel.

3. Download and install the guest agent packages:

            # yum install ovirt-engine-guest-agent-common
   

4. Install the single sign-on packages:

            # yum install ovirt-agent-gdm-plugin-ovirtcred
   

5. Install the Samba client packages:

            # yum install samba-client samba-winbind samba-winbind-clients
   

6. On the virtual machine, modify the /etc/samba/smb.conf file to contain the following, replacing DOMAIN with the short domain name and REALM.LOCAL with the Active Directory realm:

            [global]
               workgroup = DOMAIN
               realm = REALM.LOCAL
               log level = 2
               syslog = 0
               server string = Linux File Server
               security = ads
               log file = /var/log/samba/%m
               max log size = 50
               printcap name = cups
               printing = cups
               winbind enum users = Yes
               winbind enum groups = Yes
               winbind use default domain = true
               winbind separator = +
               idmap uid = 1000000-2000000
               idmap gid = 1000000-2000000
               template shell = /bin/bash
   

7. Join the virtual machine to the domain:

            net ads join -U user_name
   

8. Start the winbind service and ensure it starts on boot:

   • For Enterprise Linux 6

                 # service winbind start
                 # chkconfig winbind on
     

9. For Enterprise Linux 7

            # systemctl start winbind.service
            # systemctl enable winbind.service
   

10. Verify that the system can communicate with Active Directory:

    1. Verify that a trust relationship has been created:

                   # wbinfo -t
       

    2. Verify that you can list users:

                   # wbinfo -u
       

    3. Verify that you can list groups:

                   # wbinfo -g
       

11. Configure the NSS and PAM stack:

    1. Open the Authentication Configuration window:

                   # authconfig-tui
       

    2. Select the Use Winbind check box, select Next and press Enter.
    3. Select the OK button and press Enter.

Log in to the User Portal using the user name and password of a user configured to use single sign-on and connect to the console of the virtual machine. You will be logged in automatically.

To configure single sign-on for Windows virtual machines, the Windows guest agent must be installed on the guest virtual machine. The oVirt Guest Tools ISO file provides this agent. If the oVirt-toolsSetup.iso image is not available in your ISO domain, contact your system administrator.

Configuring Single Sign-On for Windows Virtual Machines

1. Select the Windows virtual machine. Ensure the machine is powered up.
2. Click Change CD.
3. Select oVirt-toolsSetup.iso from the list of images.
4. Click OK.
5. Click the Console icon and log in to the virtual machine.
6. On the virtual machine, locate the CD drive to access the contents of the guest tools ISO file and launch oVirt-ToolsSetup.exe. After the tools have been installed, you will be prompted to restart the machine to apply the changes.

Log in to the User Portal using the user name and password of a user configured to use single sign-on and connect to the console of the virtual machine. You will be logged in automatically.

The following procedure explains how to disable single sign-on for a virtual machine.

Disabling Single Sign-On for Virtual Machines

1. Select a virtual machine and click Edit.
2. Click the Console tab.
3. Select the Disable Single Sign On check box.
4. Click OK.

USB redirection Native mode allows KVM/SPICE USB redirection for Linux and Windows virtual machines. Virtual (guest) machines require no guest-installed agents or drivers for native USB. On Enterprise Linux clients, all packages required for USB redirection are provided by the virt-viewer package. On Windows clients, you must also install the usbdk package. Native USB mode is supported on the following clients and guests:

• Client
  • Enterprise Linux 7.1 and higher
  • Enterprise Linux 6.0 and higher
  • Windows 10
  • Windows 8
  • Windows 7
  • Windows 2008
  • Windows 2008 Server R2
• Guest
  • Enterprise Linux 7.1 and higher
  • Enterprise Linux 6.0 and higher
  • Windows 7
  • Windows XP
  • Windows 2008

Note: If you have a 64-bit architecture PC, you must use the 64-bit version of Internet Explorer to install the 64-bit version of the USB driver. The USB redirection will not work if you install the 32-bit version on a 64-bit architecture. As long as you initially install the correct USB type, you then can access USB redirection from both 32 and 64-bit browsers.

The usbdk driver must be installed on the Windows client for the USB device to be redirected to the guest. Ensure the version of usbdk matches the architecture of the client machine. For example, the 64-bit version of usbdk must be installed on 64-bit Windows machines.

Using USB Devices on a Windows Client

1. When the usbdk driver is installed, select a virtual machine that has been configured to use the SPICE protocol.
2. Ensure USB support is set to Native:
   1. Click Edit.
   2. Click the Console tab.
   3. Select Native from the USB Support drop-down list.
   4. Click OK.
3. Click the Console Options button and select the Enable USB Auto-Share check box.
4. Start the virtual machine and click the Console button to connect to that virtual machine. When you plug your USB device into the client machine, it will automatically be redirected to appear on your guest machine.

The usbredir package enables USB redirection from Enterprise Linux clients to virtual machines. usbredir is a dependency of the virt-viewer package, and is automatically installed together with that package.

Using USB devices on a Enterprise Linux client

1. Click the Virtual Machines tab and select a virtual machine that has been configured to use the SPICE protocol.
2. Ensure USB support is set to Native:
   1. Click Edit.
   2. Click the Console tab.
   3. Select Native from the USB Support drop-down list.
   4. Click OK.
3. Click the Console Options button and select the Enable USB Auto-Share check box.
4. Start the virtual machine and click the Console button to connect to that virtual machine. When you plug your USB device into the client machine, it will automatically be redirected to appear on your guest machine.

A maximum of four displays can be configured for a single Enterprise Linux virtual machine when connecting to the virtual machine using the SPICE protocol.

1. Start a SPICE session with the virtual machine.
2. Open the View drop-down menu at the top of the SPICE client window.
3. Open the Display menu.

4. Click the name of a display to enable or disable that display.

   Note: By default, Display 1 is the only display that is enabled on starting a SPICE session with a virtual machine. If no other displays are enabled, disabling this display will close the session.

If you are prompted to download a console.vv file when attempting to open a console to a virtual machine using the native client console option, and Remote Viewer is already installed, then you can manually associate console.vv files with Remote Viewer so that Remote Viewer can automatically use those files to open consoles.

Manually Associating console.vv Files with Remote Viewer

1. Start the virtual machine.

2. Open the Console Options window.

   • In the Administration Portal, right-click the virtual machine and click Console Options.
   • In the User Portal, click the Edit Console Options button.

   The User Portal Edit Console Options Button

   

3. Change the console invocation method to Native client and click OK.
4. Attempt to open a console to the virtual machine, then click Save when prompted to open or save the console.vv file.
5. Navigate to the location on your local machine where you saved the file.
6. Double-click the console.vv file and select Select a program from a list of installed programs when prompted.
7. In the Open with window, select Always use the selected program to open this kind of file and click the Browse button.
8. Navigate to the C:\Users\[user name]\AppData\Local\virt-viewer\bin directory and select remote-viewer.exe.
9. Click Open and then click OK.

When you use the native client console invocation option to open a console to a virtual machine, Remote Viewer will automatically use the console.vv file that the Ybox Engine provides to open a console to that virtual machine without prompting you to select the application to use.

You can add a watchdog card to a virtual machine to monitor the operating system's responsiveness.

Adding Watchdog Cards to Virtual Machines

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Edit.
3. Click the High Availability tab.
4. Select the watchdog model to use from the Watchdog Model drop-down list.
5. Select an action from the Watchdog Action drop-down list. This is the action that the virtual machine takes when the watchdog is triggered.
6. Click OK.

To activate a watchdog card attached to a virtual machine, you must install the watchdog package on that virtual machine and start the watchdog service.

Installing Watchdogs

1. Log in to the virtual machine on which the watchdog card is attached.

2. Install the watchdog package and dependencies:

   	 # yum install watchdog
   

3. Edit the /etc/watchdog.conf file and uncomment the following line:

   	 watchdog-device = /dev/watchdog
   

4. Save the changes.
5. Start the watchdog service and ensure this service starts on boot:

   • Enterprise Linux 6:

                 # service watchdog start
                 # chkconfig watchdog on
     

   • Enterprise Linux 7:

                 # systemctl start watchdog.service
                 # systemctl enable watchdog.service
     

Confirm that a watchdog card has been attached to a virtual machine and that the watchdog service is active.

Warning: This procedure is provided for testing the functionality of watchdogs only and must not be run on production machines.

Confirming Watchdog Functionality

1. Log in to the virtual machine on which the watchdog card is attached.

2. Confirm that the watchdog card has been identified by the virtual machine:

   	 # lspci | grep watchdog -i
   

3. Run one of the following commands to confirm that the watchdog is active:

   • Trigger a kernel panic:

                 # echo c > /proc/sysrq-trigger
     

   • Terminate the watchdog service:

                 # kill -9 `pgrep watchdog`
     

The watchdog timer can no longer be reset, so the watchdog counter reaches zero after a short period of time. When the watchdog counter reaches zero, the action specified in the Watchdog Action drop-down menu for that virtual machine is performed.

The following is a list of options for configuring the watchdog service available in the /etc/watchdog.conf file. To configure an option, you must uncomment that option and restart the watchdog service after saving the changes.

Note: For a more detailed explanation of options for configuring the watchdog service and using the watchdog command, see the watchdog man page.

watchdog.conf variables

Update the guest agents and drivers on your Enterprise Linux virtual machines to use the latest version.

Updating the Guest Agents and Drivers on Enterprise Linux

1. Log in to the Enterprise Linux virtual machine.

2. Update the ovirt-guest-agent-common package:

   	# yum update ovirt-guest-agent-common
   

3. Restart the service:

   • For Enterprise Linux 6

                # service ovirt-guest-agent restart
     

   • For Enterprise Linux 7

                # systemctl restart ovirt-guest-agent.service
     

The guest tools comprise software that allows Ybox Engine to communicate with the virtual machines it manages, providing information such as the IP addresses, memory usage, and applications installed on those virtual machines. The guest tools are distributed as an ISO file that can be attached to guests. This ISO file is packaged as an RPM file that can be installed and upgraded from the machine on which the Ybox Engine is installed.

Updating the Guest Agents and Drivers on Windows

1. On the Ybox Engine, update the oVirt Guest Tools to the latest version:

   	# yum update -y ovirt-guest-tools-iso*
   

2. Upload the ISO file to your ISO domain, replacing [ISODomain] with the name of your ISO domain:

   	engine-iso-uploader --iso-domain=[ISODomain] upload /usr/share/ovirt-guest-tools-iso/ovirt-tools-setup.iso
   

   Note: The ovirt-tools-setup.iso file is a symbolic link to the most recently updated ISO file. The link is automatically changed to point to the newest ISO file every time you update the ovirt-guest-tools-iso package.

3. In the Administration or User Portal, if the virtual machine is running, use the Change CD button to attach the latest ovirt-tools-setup.iso file to each of your virtual machines. If the virtual machine is powered off, click the Run Once* button and attach the ISO as a CD.
4. Select the CD Drive containing the updated ISO and execute the ovirt-ToolsSetup.exe file.

As the SuperUser, the system administrator manages all aspects of the Administration Portal. More specific administrative roles can be assigned to other users. These restricted administrator roles are useful for granting a user administrative privileges that limit them to a specific resource. For example, a DataCenterAdmin role has administrator privileges only for the assigned data center with the exception of the storage for that data center, and a ClusterAdmin has administrator privileges only for the assigned cluster.

A template administrator is a system administration role for templates in a data center. This role can be applied to specific virtual machines, to a data center, or to the whole virtualized environment; this is useful to allow different users to manage certain virtual resources.

The template administrator role permits the following actions:

• Create, edit, export, and remove associated templates.
• Import and export templates.

Note: You can only assign roles and permissions to existing users.

The table below describes the administrator roles and privileges applicable to virtual machine administration.

oVirt System Administrator Roles

The table below describes the user roles and privileges applicable to virtual machine users. These roles allow access to the User Portal for managing and accessing virtual machines, but they do not confer any permissions for the Administration Portal.

oVirt System User Roles

If you are creating virtual machines for users other than yourself, you have to assign roles to the users before they can use the virtual machines. Note that permissions can only be assigned to existing users.

The User Portal supports three default roles: User, PowerUser and UserVmEngine. However, customized roles can be configured via the Administration Portal. The default roles are described below.

• A User can connect to and use virtual machines. This role is suitable for desktop end users performing day-to-day tasks.
• A PowerUser can create virtual machines and view virtual resources. This role is suitable if you are an administrator or manager who needs to provide virtual resources for your employees.
• A UserVmEngine can edit and remove virtual machines, assign user permissions, use snapshots and use templates. It is suitable if you need to make configuration changes to your virtual environment.

When you create a virtual machine, you automatically inherit UserVmEngine privileges. This enables you to make changes to the virtual machine and assign permissions to the users you manage, or users who are in your Identity Management (IdM) or RHDS group.

Assigning Permissions to Users

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Permissions tab on the details pane.
3. Click Add.
4. Enter a name, or user name, or part thereof in the Search text box, and click Go. A list of possible matches display in the results list.
5. Select the check box of the user to be assigned the permissions.
6. Select UserRole from the Role to Assign drop-down list.
7. Click OK.

The user's name and role display in the list of users permitted to access this virtual machine.

Note: If a user is assigned permissions to only one virtual machine, single sign-on (SSO) can be configured for the virtual machine. With single sign-on enabled, when a user logs in to the User Portal, and then connects to a virtual machine through, for example, a SPICE console, users are automatically logged in to the virtual machine and do not need to type in the user name and password again. Single sign-on can be enabled or disabled on a per virtual machine basis.

Removing Access to Virtual Machines from Users

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Permissions tab on the details pane.
3. Click Remove. A warning message displays, asking you to confirm removal of the selected permissions.
4. To proceed, click OK. To abort, click Cancel.

A snapshot is a view of a virtual machine's operating system and applications on any or all available disks at a given point in time. Take a snapshot of a virtual machine before you make a change to it that may have unintended consequences. You can use a snapshot to return a virtual machine to a previous state.

Important: Before taking a live snapshot of a virtual machine using OpenStack Volume (Cinder) disks, you must freeze and thaw the guest filesystem manually. This cannot be done with the Engine, and must be executed using the REST API.

Creating a Snapshot of a Virtual Machine

1. Click the Virtual Machines tab and select a virtual machine.

2. Click the Snapshots tab in the details pane and click Create.

   Create snapshot

   

3. Enter a description for the snapshot.
4. Select Disks to include using the check boxes.
5. Use the Save Memory check box to denote whether to include the virtual machine's memory in the snapshot.
6. Click OK.

Note: If you are taking a snapshot of a virtual machine with an OpenStack Volume (Cinder) disk, you must thaw the guest filesystem when the snapshot is complete using the REST API.

The virtual machine's operating system and applications on the selected disk(s) are stored in a snapshot that can be previewed or restored. The snapshot is created with a status of Locked, which changes to Ok. When you click on the snapshot, its details are shown on the General, Disks, Network Interfaces, and Installed Applications tabs in the right side-pane of the details pane.

A snapshot can be used to restore a virtual machine to its previous state.

Using Snapshots to Restore Virtual Machines

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Snapshots tab in the details pane to list the available snapshots.
3. Select a snapshot to restore in the left side-pane. The snapshot details display in the right side-pane.

4. Click the drop-down menu beside Preview to open the Custom Preview Snapshot window.

   Custom Preview Snapshot

   

5. Use the check boxes to select the VM Configuration, Memory, and disk(s) you want to restore, then click OK. This allows you to create and restore from a customized snapshot using the configuration and disk(s) from multiple snapshots.

   The Custom Preview Snapshot Window

   The status of the snapshot changes to Preview Mode. The status of the virtual machine briefly changes to Image Locked before returning to Down.

6. Start the virtual machine; it runs using the disk image of the snapshot.
7. Click Commit to permanently restore the virtual machine to the condition of the snapshot. Any subsequent snapshots are erased.
8. Alternatively, click the Undo button to deactivate the snapshot and return the virtual machine to its previous state.

You have created a snapshot from a virtual machine. Now you can use that snapshot to create another virtual machine.

Creating a virtual machine from a snapshot

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Snapshots tab in the details pane to list the available snapshots.
3. Select a snapshot in the list displayed and click Clone.

4. Enter the Name and Description for the virtual machine.

   Clone a Virtual Machine from a Snapshot

   

5. Click OK.

After a short time, the cloned virtual machine appears in the Virtual Machines tab in the navigation pane with a status of Image Locked. The virtual machine will remain in this state until oVirt completes the creation of the virtual machine. A virtual machine with a preallocated 20 GB hard drive takes about fifteen minutes to create. Sparsely-allocated virtual disks take less time to create than do preallocated virtual disks.

When the virtual machine is ready to use, its status changes from Image Locked to Down in the Virtual Machines tab in the navigation pane.

You can delete a virtual machine snapshot and permanently remove it from your oVirt environment. This operation is supported on a running virtual machine and does not require the virtual machine to be in a down state.

Important: When you delete a snapshot from an image chain, one of three things happens:

• If the snapshot being deleted is contained in a RAW (preallocated) base image, a new volume is created that is the same size as the base image.
• If the snapshot being deleted is contained in a QCOW2 (thin provisioned) base image, the volume subsequent to the volume containing the snapshot being deleted is extended to the cumulative size of the successor volume and the base volume.
• If the snapshot being deleted is contained in a QCOW2 (thin provisioned), non-base image hosted on internal storage, the successor volume is extended to the cumulative size of the successor volume and the volume containing the snapshot being deleted.

The data from the two volumes is merged in the new or resized volume. The new or resized volume grows to accommodate the total size of the two merged images; the new volume size will be, at most, the sum of the two merged images. To delete a snapshot, you must have enough free space in the storage domain to temporarily accommodate both the original volume and the newly merged volume. Otherwise, snapshot deletion will fail and you will need to export and re-import the volume to remove snapshots.

Deleting a Snapshot

1. Click the Virtual Machines tab and select a virtual machine.

2. Click the Snapshots tab in the details pane to list the snapshots for that virtual machine.

   Snapshot List

   

3. Select the snapshot to delete.
4. Click Delete.
5. Click OK.

Virtual machines can be directly attached to the host devices for improved performance if a compatible host has been configured for direct device assignment.

Adding Host Devices to a Virtual Machine

1. Select a virtual machine and click the Host Devices tab in the details pane to list the host devices already attached to this virtual machine. A virtual machine can only have devices attached from the same host. If a virtual machine has attached devices from one host, and you attach a device from another host, the attached devices from the previous host will be automatically removed.

   Attaching host devices to a virtual machine requires the virtual machine to be in a Down state. If the virtual machine is running, the changes will not take effect until after the virtual machine has been shut down.

2. Click Add device to open the Add Host Devices window.
3. Use the Pinned Host dropdown menu to select a host.
4. Use the Capability dropdown menu to list the pci, scsi, or usb_device host devices.
5. Select the check boxes of the devices to attach to the virtual machine from the Available Host Devices pane and click the directional arrow button to transfer these devices to the Host Devices to be attached pane, creating a list of the devices to attach to the virtual machine.
6. When you have transferred all desired host devices to the Host Devices to be attached pane, click OK to attach these devices to the virtual machine and close the window.

These host devices will be attached to the virtual machine when the virtual machine is next powered on.

Remove a host device from a virtual machine to which it has been directly attached using the details pane of the virtual machine.

If you are removing all host devices directly attached to the virtual machine in order to add devices from a different host, you can instead add the devices from the desired host, which will automatically remove all of the devices already attached to the virtual machine.

Removing a Host Device from a Virtual Machine

1. Select the virtual machine and click the Host Devices tab in the details pane to list the host devices attached to the virtual machine.
2. Select the host device to detach from the virtual machine, or hold Ctrl to select multiple devices, and click Remove device to open the Remove Host Device(s) window.
3. Click OK to confirm and detach these devices from the virtual machine.

You can use the Host Devices tab in the details pane of a virtual machine to pin it to a specific host.

If the virtual machine has any host devices attached to it, pinning it to another host will automatically remove the host devices from the virtual machine.

Pinning a Virtual Machine to a Host

1. Select a virtual machine and click the Host Devices tab in the details pane.
2. Click Pin to another host to open the Pin VM to Host window.
3. Use the Host drop-down menu to select a host.
4. Click OK to pin the virtual machine to the selected host.

You can create new affinity groups in the Administration Portal.

Creating Affinity Groups

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Affinity Groups tab in the details pane.
3. Click New.
4. Enter a Name and Description for the affinity group.
5. Select the Positive check box to apply positive affinity, or ensure this check box is cleared to apply negative affinity.
6. Select the Enforcing check box to apply hard enforcement, or ensure this check box is cleared to apply soft enforcement.
7. Use the drop-down list to select the virtual machines to be added to the affinity group. Use the + and - buttons to add or remove additional virtual machines.
8. Click OK.

Editing Affinity Groups

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Affinity Groups tab in the details pane.
3. Click Edit.
4. Change the Positive and Enforcing check boxes to the preferred values and use the + and - buttons to add or remove virtual machines to or from the affinity group.
5. Click OK.

Removing Affinity Groups

1. Click the Virtual Machines tab and select a virtual machine.
2. Click the Affinity Groups tab in the details pane.
3. Click Remove.
4. Click OK.

The affinity policy that applied to the virtual machines that were members of that affinity group no longer applies.

Templates

This procedure provides a graphical overview of the steps required to export a virtual machine or template from one data center and import that virtual machine or template into another data center.

Exporting and Importing Virtual Machines and Templates

1. Attach the export domain to the source data center.

   Attach Export Domain

   

2. Export the virtual machine or template to the export domain.

   Export the Virtual Resource

   

3. Detach the export domain from the source data center.

   Detach Export Domain

   

4. Attach the export domain to the destination data center.

   Attach the Export Domain

   

5. Import the virtual machine or template into the destination data center.

   Import the virtual resource

   

6. Exporting individual virtual machines to the export domain

Export a virtual machine to the export domain so that it can be imported into a different data center. Before you begin, the export domain must be attached to the data center that contains the virtual machine to be exported.

Warning: The virtual machine must be shut down before being exported.

Exporting a Virtual Machine to the Export Domain

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Export.
3. Optionally select the following check boxes:
   • Force Override: overrides existing images of the virtual machine on the export domain.

   • Collapse Snapshots: creates a single export volume per disk. This option removes snapshot restore points and includes the template in a template-based virtual machine, and removes any dependencies a virtual machine has on a template. For a virtual machine that is dependent on a template, either select this option, export the template with the virtual machine, or make sure the template exists in the destination data center.

     Note: When you create a virtual machine from a template, two storage allocation options are available under New Virtual Machine > Resource Allocation > Storage Allocation.

     • If Clone was selected, the virtual machine is not dependent on the template. The template does not have to exist in the destination data center.
     • If Thin was selected, the virtual machine is dependent on the template, so the template must exist in the destination data center or be exported with the virtual machine. Alternatively, select the Collapse Snapshots check box to collapse the template disk and virtual machine disk into a single disk.

     To check which option was selected, select a virtual machine and click the General tab in the details pane.

4. Click OK.

The export of the virtual machine begins. The virtual machine displays in the Virtual Machines results list with an Image Locked status while it is exported. Depending on the size of your virtual machine hard disk images, and your storage hardware, this can take up to an hour. Use the Events tab to view the progress. When complete, the virtual machine has been exported to the export domain and displays on the VM Import tab of the export domain's details pane.

You have a virtual machine on an export domain. Before the virtual machine can be imported to a new data center, the export domain must be attached to the destination data center.

Importing a Virtual Machine into the Destination Data Center

1. Click the Storage tab, and select the export domain in the results list. The export domain must have a status of Active.
2. Select the VM Import tab in the details pane to list the available virtual machines to import.

3. Select one or more virtual machines to import and click Import.

   Import Virtual Machine

   

4. Select the Default Storage Domain and Cluster.
5. Select the Collapse Snapshots check box to remove snapshot restore points and include templates in template-based virtual machines.
6. Click the virtual machine to be imported and click on the Disks sub-tab. From this tab, you can use the Allocation Policy and Storage Domain drop-down lists to select whether the disk used by the virtual machine will be thinly provisioned or preallocated, and can also select the storage domain on which the disk will be stored. An icon is also displayed to indicate which of the disks to be imported acts as the boot disk for that virtual machine.
7. Click OK to import the virtual machines.

8. The Import Virtual Machine Conflict window opens if the virtual machine exists in the virtualized environment.

   Import Virtual Machine Conflict Window

   

9. Choose one of the following radio buttons:
   • Don't import
   • Import as cloned and enter a unique name for the virtual machine in the New Name field.
10. Optionally select the Apply to all check box to import all duplicated virtual machines with the same suffix, and then enter a suffix in the Suffix to add to the cloned VMs field.
11. Click OK.

Important: During a single import operation, you can only import virtual machines that share the same architecture. If any of the virtual machines to be imported have a different architecture to that of the other virtual machines to be imported, a warning will display and you will be prompted to change your selection so that only virtual machines with the same architecture will be imported.

Import virtual machines from a VMware vCenter provider to your oVirt environment. You can import from a VMware provider by entering its details in the Import Virtual Machine(s) window during each import operation, or you can add the VMware provider as an external provider, and select the preconfigured provider during import operations. To add an external provider,

oVirt uses V2V to convert VMware virtual machines to the correct format before they are imported. You must install the virt-v2v package on a least one Enterprise Linux 7 host before proceeding. This package is available in the base rhel-7-server-rpms repository.

Warning: The virtual machine must be shut down before being imported. Starting the virtual machine through VMware during the import process can result in data corruption.

Importing a Virtual Machine from VMware

1. In the Virtual Machines tab, click Import to open the Import Virtual Machine(s) window.

   The Import Virtual Machine(s) Window

   

2. Select VMware from the Source list.
3. If you have configured a VMware provider as an external provider, select it from the External Provider list. Verify that the provider credentials are correct. If you did not specify a destination data center or proxy host when configuring the external provider, select those options now.
4. If you have not configured a VMware provider, or want to import from a new VMware provider, provide the following details:
   1. Select from the list the Data Center in which the virtual machine will be available.
   2. Enter the IP address or fully qualified domain name of the VMware vCenter instance in the vCenter field.
   3. Enter the IP address or fully qualified domain name of the host from which the virtual machines will be imported in the ESXi field.
   4. Enter the name of the data center and the cluster in which the specified ESXi host resides in the Data Center field.
   5. If you have exchanged the SSL certificate between the ESXi host and the Engine, leave Verify server's SSL certificate checked to verify the ESXi host's certificate. If not, uncheck the option.
   6. Enter the Username and Password for the VMware vCenter instance. The user must have access to the VMware data center and ESXi host on which the virtual machines reside.
   7. Select a host in the chosen data center with virt-v2v installed to serve as the Proxy Host during virtual machine import operations. This host must also be able to connect to the network of the VMware vCenter external provider.
5. Click Load to generate a list of the virtual machines on the VMware provider.

6. Select one or more virtual machines from the Virtual Machines on Source list, and use the arrows to move them to the Virtual Machines to Import list. Click Next.

   Important: An import operation can only include virtual machines that share the same architecture. If any virtual machine to be imported has a different architecture, a warning will display and you will be prompted to change your selection to include only virtual machines with the same architecture.

   Note: If a virtual machine's network device uses the driver type e1000 or rtl8139, the virtual machine will use the same driver type after it has been imported to oVirt.

   If required, you can change the driver type to VirtIO manually after the import. To change the driver type after a virtual machine has been imported,

   If the network device uses driver types other than e1000 or rtl8139, the driver type is changed to VirtIO automatically during the import. The Attach VirtIO-drivers option allows the VirtIO drivers to be injected to the imported virtual machine files so that when the driver is changed to VirtIO, the device will be properly detected by the operating system.

   The Import Virtual Machine(s) Window

   

7. Select the Cluster in which the virtual machines will reside.
8. Select a CPU Profile for the virtual machines.
9. Select the Collapse Snapshots check box to remove snapshot restore points and include templates in template-based virtual machines.
10. Select the Clone check box to change the virtual machine name and MAC addresses, and clone all disks, removing all snapshots. If a virtual machine appears with a warning symbol beside its name or has a tick in the VM in System column, you must clone the virtual machine and change its name.

11. Click on each virtual machine to be imported and click on the Disks sub-tab. Use the Allocation Policy and Storage Domain lists to select whether the disk used by the virtual machine will be thinly provisioned or preallocated, and select the storage domain on which the disk will be stored. An icon is also displayed to indicate which of the disks to be imported acts as the boot disk for that virtual machine.

    Note: The target storage domain must be a filed-based domain. Due to current limitations, specifying a block-based domain causes the V2V operation to fail.

12. If you selected the Clone check box, change the name of the virtual machine in the General sub-tab.
13. Click OK to import the virtual machines.

Import virtual machines from Xen on Enterprise Linux 5 to your oVirt environment. oVirt uses V2V to convert Xen virtual machines to the correct format before they are imported. You must install the virt-v2v package on at least one Enterprise Linux 7 host in the destination data center before proceeding (this host is referred to in the following procedure as the V2V host). The virt-v2v package is available in the base rhel-7-server-rpms repository.

Warning: The virtual machine must be shut down before being imported. Starting the virtual machine through Xen during the import process can result in data corruption.

Importing a Virtual Machine from Xen

1. Enable passwordless SSH between the V2V host and the Xen host:

   1. Log in to the V2V host and generate SSH keys for the vdsm user.

                  # sudo -u vdsm ssh-keygen
      

   2. Copy the vdsm user's public key to the Xen host.

                  # sudo -u vdsm ssh-copy-id root@xenhost.example.com
      

   As a side-effect of this step the known_hosts file on the V2V host is updated with the host key of the Xen host. This is also required for the import process to work.

   1. To verify that everything is set-up properly you can try to ssh to the Xen host.

                  # sudo -u vdsm ssh root@xenhost.example.com
      

   2. Exit the Xen host.

                  # logout
      

   3. Another verification step that you can perform to make sure everything is OK is to list the VMs on the Xen host.

                  # sudo -u vdsm virsh -c 'qemu+ssh://root@xenhost.example.com/system' list
      

2. Log in to the Administration Portal. In the Virtual Machines tab, click Import to open the Import Virtual Machine(s) window.

   The Import Virtual Machine(s) Window

   

3. Select the Data Center that contains the V2V host.
4. Select XEN (via RHEL) from the Source drop-down list.
5. Enter the URI of the Xen host. The required format is pre-filled; you must replace <hostname> with the host name of the Xen host.
6. Select the V2V host from the Proxy Host drop-down list.
7. Click Load to generate a list of the virtual machines on the Xen hypervisor.

8. Select one or more virtual machines from the Virtual Machines on Source list, and use the arrows to move them to the Virtual Machines to Import list.

   Note: Due to current limitations, Xen virtual machines with block devices do not appear in the Virtual Machines on Source list, and cannot be imported to oVirt.

9. Click Next.

   Important: An import operation can only include virtual machines that share the same architecture. If any virtual machine to be imported has a different architecture, a warning will display and you will be prompted to change your selection to include only virtual machines with the same architecture.

   The Import Virtual Machine(s) Window

   

10. Select the Cluster in which the virtual machines will reside.
11. Select a CPU Profile for the virtual machines.
12. Select the Collapse Snapshots check box to remove snapshot restore points and include templates in template-based virtual machines.
13. Select the Clone check box to change the virtual machine name and MAC addresses, and clone all disks, removing all snapshots. If a virtual machine appears with a warning symbol beside its name or has a tick in the VM in System column, you must clone the virtual machine and change its name.

14. Click on each virtual machine to be imported and click on the Disks sub-tab. Use the Allocation Policy and Storage Domain lists to select whether the disk used by the virtual machine will be thinly provisioned or preallocated, and select the storage domain on which the disk will be stored. An icon is also displayed to indicate which of the disks to be imported acts as the boot disk for that virtual machine.

    Note: The target storage domain must be a filed-based domain. Due to current limitations, specifying a block-based domain causes the V2V operation to fail.

15. If you selected the Clone check box, change the name of the virtual machine in the General sub-tab.
16. Click OK to import the virtual machines.

Live migration is used to seamlessly move virtual machines to support a number of common maintenance tasks. Ensure that your oVirt environment is correctly configured to support live migration well in advance of using it.

At a minimum, for successful live migration of virtual machines to be possible:n

• The source and destination host should both be members of the same cluster, ensuring CPU compatibility between them.

  Note: Live migrating virtual machines between different clusters is generally not recommended.

• The source and destination host must have a status of Up.
• The source and destination host must have access to the same virtual networks and VLANs.
• The source and destination host must have access to the data storage domain on which the virtual machine resides.
• There must be enough CPU capacity on the destination host to support the virtual machine's requirements.
• There must be enough RAM on the destination host that is not in use to support the virtual machine's requirements.
• The migrating virtual machine must not have the cache!=none custom property set.

In addition, for best performance, the storage and management networks should be split to avoid network saturation. Virtual machine migration involves transferring large amounts of data between hosts.

Live migration is performed using the management network. Each live migration event is limited to a maximum transfer speed of 30 MBps, and the number of concurrent migrations supported is also limited by default. Despite these measures, concurrent migrations have the potential to saturate the management network. It is recommended that separate logical networks are created for storage, display, and virtual machine data to minimize the risk of network saturation.

Ybox Engine automatically initiates live migration of all virtual machines running on a host when the host is moved into maintenance mode. The destination host for each virtual machine is assessed as the virtual machine is migrated, in order to spread the load across the cluster.

The Engine automatically initiates live migration of virtual machines in order to maintain load balancing or power saving levels in line with scheduling policy. While no scheduling policy is defined by default, it is recommended that you specify the scheduling policy which best suits the needs of your environment. You can also disable automatic, or even manual, live migration of specific virtual machines where required.

Ybox Engine allows you to disable automatic migration of virtual machines. You can also disable manual migration of virtual machines by setting the virtual machine to run only on a specific host.

The ability to disable automatic migration and require a virtual machine to run on a particular host is useful when using application high availability products.

Preventing Automatic Migration of Virtual Machine

1. Click the Virtual Machines tab and select a virtual machine.

2. Click Edit.

   The Edit Virtual Machine Window

   

3. Click the Host tab.

4. Use the Start Running On radio buttons to designate the virtual machine to run on Any Host in Cluster or a Specific host. If applicable, select a specific host or group of hosts from the list.

   Warning: Explicitly assigning a virtual machine to one specific host and disabling migration is mutually exclusive with oVirt high availability. Virtual machines that are assigned to one specific host can only be made highly available using third-party high availability products. This restriction does not apply to virtual machines that are assigned to multiple specific hosts.

   Important: If the virtual machine has host devices directly attached to it, and a different host is specified, the host devices from the previous host will be automatically removed from the virtual machine.

5. Select Allow manual migration only or Do not allow migration from the Migration Options drop-down list.
6. Optionally, select the Use custom migration downtime check box and specify a value in milliseconds.
7. Click OK.

A running virtual machine can be live migrated to any host within its designated host cluster. Live migration of virtual machines does not cause any service interruption. Migrating virtual machines to a different host is especially useful if the load on a particular host is too high. For live migration prerequisites, see the Live migration prerequisites section.

Note: When you place a host into maintenance mode, the virtual machines running on that host are automatically migrated to other hosts in the same cluster. You do not need to manually migrate these virtual machines.

Note: Live migrating virtual machines between different clusters is generally not recommended.

Manually Migrating Virtual Machines

1. Click the Virtual Machines tab and select a running virtual machine.
2. Click Migrate.

3. Use the radio buttons to select whether to Select Host Automatically or to Select Destination Host, specifying the host using the drop-down list.

   Note: When the Select Host Automatically option is selected, the system determines the host to which the virtual machine is migrated according to the load balancing and power management rules set up in the scheduling policy.

4. Click OK.

During migration, progress is shown in the Migration progress bar. Once migration is complete the Host column will update to display the host the virtual machine has been migrated to.

Ybox Engine queues concurrent requests for migration of virtual machines off of a given host. The load balancing process runs every minute. Hosts already involved in a migration event are not included in the migration cycle until their migration event has completed. When there is a migration request in the queue and available hosts in the cluster to action it, a migration event is triggered in line with the load balancing policy for the cluster.

You can influence the ordering of the migration queue by setting the priority of each virtual machine; for example, setting mission critical virtual machines to migrate before others. Migrations will be ordered by priority; virtual machines with the highest priority will be migrated first.

Setting Migration Priority

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Edit.
3. Select the High Availability tab.
4. Select Low, Medium, or High from the Priority drop-down list.
5. Click OK.

A virtual machine migration is taking longer than you expected. You'd like to be sure where all virtual machines are running before you make any changes to your environment.

Canceling Ongoing Virtual Machine Migrations

1. Select the migrating virtual machine. It is displayed in the Virtual Machines resource tab with a status of Migrating from.
2. Click Cancel Migration.

The virtual machine status returns from Migrating from to Up.

Available Virtual Servers

When a virtual server is automatically migrated because of the high availability function, the details of an automatic migration are documented in the Events tab and in the engine log to aid in troubleshooting, as illustrated in the following examples:

Notification in the Events Tab of the Web Admin Portal

Highly Available Virtual_Machine_Name failed. It will be restarted automatically.

Virtual_Machine_Name was restarted on Host Host_Name

Notification in the Engine engine.log

This log can be found on the Ybox Engine at /var/log/ovirt-engine/engine.log:

Failed to start Highly Available VM. Attempting to restart. VM Name: Virtual_Machine_Name, VM =Virtual_Machine_ID_Number=

High availability means that a virtual machine will be automatically restarted if its process is interrupted. This happens if the virtual machine is terminated by methods other than powering off from within the guest or sending the shutdown command from the Engine. When these events occur, the highly available virtual machine is automatically restarted, either on its original host or another host in the cluster.

High availability is possible because the Ybox Engine constantly monitors the hosts and storage, and automatically detects hardware failure. If host failure is detected, any virtual machine configured to be highly available is automatically restarted on another host in the cluster.

With high availability, interruption to service is minimal because virtual machines are restarted within seconds with no user intervention required. High availability keeps your resources balanced by restarting guests on a host with low current resource utilization, or based on any workload balancing or power saving policies that you configure. This ensures that there is sufficient capacity to restart virtual machines at all times.

High availability is recommended for virtual machines running critical workloads.

High availability can ensure that virtual machines are restarted in the following scenarios:

• When a host becomes non-operational due to hardware failure.
• When a host is put into maintenance mode for scheduled downtime.
• When a host becomes unavailable because it has lost communication with an external storage resource.

A high availability virtual machine is automatically restarted, either on its original host or another host in the cluster.

A highly available host requires a power management device and its fencing parameters configured. In addition, for a virtual machine to be highly available when its host becomes non-operational, it needs to be started on another available host in the cluster. To enable the migration of highly available virtual machines:

• Power management must be configured for the hosts running the highly available virtual machines.
• The host running the highly available virtual machine must be part of a cluster which has other available hosts.
• The destination host must be running.
• The source and destination host must have access to the data domain on which the virtual machine resides.
• The source and destination host must have access to the same virtual networks and VLANs.
• There must be enough CPUs on the destination host that are not in use to support the virtual machine's requirements.
• There must be enough RAM on the destination host that is not in use to support the virtual machine's requirements.

High availability must be configured individually for each virtual machine.

Configuring a Highly Available Virtual Machine

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Edit.

3. Click the High Availability tab.

   The High Availability Tab

   

4. Select the Highly Available check box to enable high availability for the virtual machine.
5. Select Low, Medium, or High from the Priority drop-down list. When migration is triggered, a queue is created in which the high priority virtual machines are migrated first. If a cluster is running low on resources, only the high priority virtual machines are migrated.
6. Click OK.

Enable SAP monitoring on a virtual machine through the Administration Portal.

Enabling SAP Monitoring on Virtual Machines

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Edit.

3. Click the Custom Properties tab.

   Enable SAP

   

4. Select sap_agent from the drop-down list. Ensure the secondary drop-down menu is set to True.

   If previous properties have been set, select the plus sign to add a new property rule and select sap_agent.

5. Click OK.

SPICE

SPICE is a remote display protocol designed for virtual environments, which enables you to view a virtualized desktop or server. SPICE delivers a high quality user experience, keeps CPU consumption low, and supports high quality video streaming.

Using SPICE on a Linux machine significantly improves the movement of the mouse cursor on the console of the virtual machine. To use SPICE, the X Window system requires additional QXL drivers. The QXL drivers are provided with Enterprise Linux 5.4 and newer. Older versions are not supported. Installing SPICE on a virtual machine running Enterprise Linux significantly improves the performance of the graphical user interface.

Note: Typically, this is most useful for virtual machines where the user requires the use of the graphical user interface. System administrators who are creating virtual servers may prefer not to configure SPICE if their use of the graphical user interface is minimal.

Virtualization poses various challenges for virtual machine time keeping. Virtual machines which use the Time Stamp Counter (TSC) as a clock source may suffer timing issues as some CPUs do not have a constant Time Stamp Counter. Virtual machines running without accurate timekeeping can have serious affects on some networked applications as your virtual machine will run faster or slower than the actual time.

KVM works around this issue by providing virtual machines with a paravirtualized clock. The KVM pvclock provides a stable source of timing for KVM guests that support it.

Presently, only Enterprise Linux 5.4 and higher virtual machines fully support the paravirtualized clock.

Virtual machines can have several problems caused by inaccurate clocks and counters:

• Clocks can fall out of synchronization with the actual time which invalidates sessions and affects networks.
• Virtual machines with slower clocks may have issues migrating.

These problems exist on other virtualization platforms and timing should always be tested.

Important: The Network Time Protocol (NTP) daemon should be running on the host and the virtual machines. Enable the ntpd service and add it to the default startup sequence:

• For Enterprise Linux 6

  	 # service ntpd start
  	 # chkconfig ntpd on
  

• For Enterprise Linux 7

  	 # systemctl start ntpd.service
  	 # systemctl enable ntpd.service
  

Using the ntpd service should minimize the affects of clock skew in all cases.

The NTP servers you are trying to use must be operational and accessible to your hosts and virtual machines.

Determining if your CPU has the constant Time Stamp Counter

Your CPU has a constant Time Stamp Counter if the constant_tsc flag is present. To determine if your CPU has the constant_tsc flag run the following command:

      $ cat /proc/cpuinfo | grep constant_tsc

If any output is given your CPU has the constant_tsc bit. If no output is given follow the instructions below.

Configuring hosts without a constant Time Stamp Counter

Systems without constant time stamp counters require additional configuration. Power management features interfere with accurate time keeping and must be disabled for virtual machines to accurately keep time with KVM.

Important: These instructions are for AMD revision F CPUs only.

If the CPU lacks the constant_tsc bit, disable all power management features (BZ#513138). Each system has several timers it uses to keep time. The TSC is not stable on the host, which is sometimes caused by cpufreq changes, deep C state, or migration to a host with a faster TSC. Deep C sleep states can stop the TSC. To prevent the kernel using deep C states append "processor.max_cstate=1" to the kernel boot options in the grub.conf file on the host:

      term Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
       kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1

Disable cpufreq (only necessary on hosts without the constant_tsc) by editing the /etc/sysconfig/cpuspeed configuration file and change the MIN_SPEED and MAX_SPEED variables to the highest frequency available. Valid limits can be found in the /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies files.

Using the engine-config tool to receive alerts when hosts drift out of sync.

You can use the engine-config tool to configure alerts when your hosts drift out of sync.

There are 2 relevant parameters for time drift on hosts: EnableHostTimeDrift and HostTimeDriftInSec. EnableHostTimeDrift, with a default value of false, can be enabled to receive alert notifications of host time drift. The HostTimeDriftInSec parameter is used to set the maximum allowable drift before alerts start being sent.

Alerts are sent once per hour per host.

Using the paravirtualized clock with Enterprise Linux virtual machines

For certain Enterprise Linux virtual machines, additional kernel parameters are required. These parameters can be set by appending them to the end of the /kernel line in the /boot/grub/grub.conf file of the virtual machine.

Note: The process of configuring kernel parameters can be automated using the ktune package

The ktune package provides an interactive Bourne shell script, fix_clock_drift.sh. When run as the superuser, this script inspects various system parameters to determine if the virtual machine on which it is run is susceptible to clock drift under load. If so, it then creates a new grub.conf.kvm file in the /boot/grub/ directory. This file contains a kernel boot line with additional kernel parameters that allow the kernel to account for and prevent significant clock drift on the KVM virtual machine. After running fix_clock_drift.sh as the superuser, and once the script has created the grub.conf.kvm file, then the virtual machine's current grub.conf file should be backed up manually by the system administrator, the new grub.conf.kvm file should be manually inspected to ensure that it is identical to grub.conf with the exception of the additional boot line parameters, the grub.conf.kvm file should finally be renamed grub.conf, and the virtual machine should be rebooted.

The table below lists versions of Enterprise Linux and the parameters required for virtual machines on systems without a constant Time Stamp Counter.

There are two main methods for sealing a Linux virtual machine in preparation for using that virtual machine to create a template: manually, or using the sys-unconfig command. Sealing a Linux virtual machine manually requires you to create a file on the virtual machine that acts as a flag for initiating various configuration tasks the next time you start that virtual machine. The sys-unconfig command allows you to automate this process. However, both of these methods also require you to manually delete files on the virtual machine that are specific to that virtual machine or might cause conflicts amongst virtual machines created based on the template you will create based on that virtual machine. As such, both are valid methods for sealing a Linux virtual machine and will achieve the same result.

A template created for Windows virtual machines must be generalized (sealed) before being used to deploy virtual machines. This ensures that machine-specific settings are not reproduced in the template.

The Sysprep tool is used to seal Windows templates before use.

Important: Do not reboot the virtual machine during this process.

Before starting the Sysprep process, verify that the following settings are configured:

• The Windows Sysprep parameters have been correctly defined.
• If not, click Edit and enter the required information in the Operating System and Domain fields.

• The correct product key has been defined in an override file on the Engine.

  The override file needs to be created under /etc/ovirt-engine/osinfo.conf.d/, have a filename that puts it after /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties, and end in .properties. For example, /etc/ovirt-engine/osinfo.conf.d/10-productkeys.properties. The last file will have precedent and override any other previous file.

  If not, copy the default values for your Windows operating system from /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties into the override file, and input your values in the productKey.value and sysprepPath.value fields.

  Windows 7 Default Configuration Values

  	# Windows7(11, OsType.Windows, false),false
  	os.windows_7.id.value = 11
  	os.windows_7.name.value = Windows 7
  	os.windows_7.derivedFrom.value = windows_xp
  	os.windows_7.sysprepPath.value = ${ENGINE_USR}/conf/sysprep/sysprep.w7
  	os.windows_7.productKey.value =
  	os.windows_7.devices.audio.value = ich6
  	os.windows_7.devices.diskInterfaces.value.3.3 = IDE, VirtIO_SCSI, VirtIO
  	os.windows_7.devices.diskInterfaces.value.3.4 = IDE, VirtIO_SCSI, VirtIO
  	os.windows_7.devices.diskInterfaces.value.3.5 = IDE, VirtIO_SCSI, VirtIO
  	os.windows_7.isTimezoneTypeInteger.value = false
  

Note: The export storage domain is deprecated. Storage data domains can be unattached from a data center and imported to another data center in the same environment, or in a different environment. Virtual machines, floating virtual disk images, and templates can then be uploaded from the imported storage domain to the attached data center.

Export templates into the export domain to move them to another data domain, either in the same ovirt environment, or another one. This procedure requires access to the Administration Portal.

Exporting Individual Templates to the Export Domain

1. Click the Templates tab and select a template.
2. Click Export.
3. Select the Force Override check box to replace any earlier version of the template on the export domain.
4. Click OK to begin exporting the template; this may take up to an hour, depending on the virtual machine disk image size and your storage hardware.

Repeat these steps until the export domain contains all the templates to migrate before you start the import process.

Click the Storage tab, select the export domain, and click the Template Import tab in the details pane to view all exported templates in the export domain.

If you are moving a virtual machine that was created from a template with the thin provisioning storage allocation option selected, the template's disks must be copied to the same storage domain as that of the virtual machine disk. This procedure requires access to the Administration Portal.

Copying a Virtual Hard Disk

1. Click the Disks tab and select the template disk(s) to copy.
2. Click Copy.
3. Select the Target data domain from the drop-down list(s).
4. Click OK.

A copy of the template's virtual hard disk has been created, either on the same, or a different, storage domain. If you were copying a template disk in preparation for moving a virtual hard disk, you can now move the virtual hard disk.

Note: The export storage domain is deprecated. Storage data domains can be unattached from a data center and imported to another data center in the same environment, or in a different environment. Virtual machines, floating virtual disk images, and templates can then be uploaded from the imported storage domain to the attached data center.

Import templates from a newly attached export domain. This procedure requires access to the Administration Portal.

Importing a Template into a Data Center

1. Click the Storage tab and select the newly attached export domain.
2. Click the Template Import tab in the details pane and select a template.
3. Click Import.
4. Select the templates to import.

5. Use the drop-down lists to select the Destination Cluster and Storage domain. Alter the Suffix if applicable.

   Alternatively, clear the Clone All Templates check box.

6. Click OK to import templates and open a notification window. Click Close to close the notification window.

The template is imported into the destination data center. This can take up to an hour, depending on your storage hardware. You can view the import progress in the Events tab.

Once the importing process is complete, the templates will be visible in the Templates resource tab. The templates can create new virtual machines, or run existing imported virtual machines based on that template.

Template

Virtual disk images managed by an OpenStack Image Service can be imported into the Ybox Engine if that OpenStack Image Service has been added to the Engine as an external provider. This procedure requires access to the Administration Portal.

1. Click the Storage tab and select the OpenStack Image Service domain.
2. Click the Images tab in the details pane and select the image to import.
3. Click Import.
4. Select the Data Center into which the virtual disk image will be imported.
5. Select the storage domain in which the virtual disk image will be stored from the Domain Name drop-down list.
6. Optionally, select a Quota to apply to the virtual disk image.
7. Select the Import as Template check box.
8. Select the Cluster in which the virtual disk image will be made available as a template.
9. Click OK.

The image is imported as a template and is displayed in the Templates tab. You can now create virtual machines based on the template.

As the SuperUser, the system administrator manages all aspects of the Administration Portal. More specific administrative roles can be assigned to other users. These restricted administrator roles are useful for granting a user administrative privileges that limit them to a specific resource. For example, a DataCenterAdmin role has administrator privileges only for the assigned data center with the exception of the storage for that data center, and a ClusterAdmin has administrator privileges only for the assigned cluster.

A template administrator is a system administration role for templates in a data center. This role can be applied to specific virtual machines, to a data center, or to the whole virtualized environment; this is useful to allow different users to manage certain virtual resources.

The template administrator role permits the following actions:

• Create, edit, export, and remove associated templates.
• Import and export templates.

Note: You can only assign roles and permissions to existing users.

The table below describes the administrator roles and privileges applicable to template administration.

ovirt System Administrator Roles

The table below describes the user roles and privileges applicable to using and administrating templates in the User Portal.

Assign administrator or user roles to resources to allow users to access or manage that resource.

Assigning a Role to a Resource

1. Use the resource tabs, tree mode, or the search function to find and select the resource in the results list.
2. Click the Permissions tab in the details pane to list the assigned users, the user's role, and the inherited permissions for the selected resource.
3. Click Add.
4. Enter the name or user name of an existing user into the Search text box and click Go. Select a user from the resulting list of possible matches.
5. Select a role from the Role to Assign: drop-down list.
6. Click OK.

You have assigned a role to a user; the user now has the inherited permissions of that role enabled for that resource.

Remove an administrator or user role from a resource; the user loses the inherited permissions associated with the role for that resource.

Removing a Role from a Resource

1. Use the resource tabs, tree mode, or the search function to find and select the resource in the results list.
2. Click the Permissions tab in the details pane to list the assigned users, the user's role, and the inherited permissions for the selected resource.
3. Select the user to remove from the resource.
4. Click Remove. The Remove Permission window opens to confirm permissions removal.
5. Click OK.

You have removed the user's role, and the associated permissions, from the resource.

This procedure describes how to install Cloud-Init on a virtual machine. Once Cloud-Init is installed, you can create a template based on this virtual machine. Virtual machines created based on this template can leverage Cloud-Init functions, such as configuring the host name, time zone, root password, authorized keys, network interfaces, DNS service, etc on boot.

Installing Cloud-Init

1. Log on to the virtual machine.
2. Enable the required repositories.

3. Install the cloud-init package and dependencies:

   	# yum install cloud-init
   

As long as the cloud-init package is installed on a Linux virtual machine, you can use the virtual machine to make a cloud-init enabled template. Specify a set of standard settings to be included in a template as described in the following procedure or, alternatively, skip the Cloud-Init settings steps and configure them when creating a virtual machine based on this template.

Note: While the following procedure outlines how to use Cloud-Init when preparing a template, the same settings are also available in the New Virtual Machine, Edit Template, and Run Once windows.

Using Cloud-Init to Prepare a Template

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Edit.
3. Click the Initial Run tab and select the Use Cloud-Init/Sysprep check box.
4. Enter a host name in the VM Hostname text field.
5. Select the Configure Time Zone check box and select a time zone from the Time Zone drop-down list.
6. Expand the Authentication section and select the Use already configured password check box to user the existing credentials, or clear that check box and enter a root password in the Password and Verify Password text fields to specify a new root password.
7. Enter any SSH keys to be added to the authorized hosts file on the virtual machine in the SSH Authorized Keys text area.
8. Select the Regenerate SSH Keys check box to regenerate SSH keys for the virtual machine.
9. Expand the Networks section and enter any DNS servers in the DNS Servers text field.
10. Enter any DNS search domains in the DNS Search Domains text field.
11. Select the Network check box and use the + and - buttons to add or remove network interfaces to or from the virtual machine.
12. Expand the Custom Script section and enter any custom scripts in the Custom Script text area.
13. Click Ok.
14. Click Make Template and enter the fields as necessary.
15. Click Ok.

You can now provision new virtual machines using this template.

Use Cloud-Init to automate the initial configuration of a Linux virtual machine. You can use the Cloud-Init fields to configure a virtual machine's host name, time zone, root password, authorized keys, network interfaces, and DNS service. You can also specify a custom script, a script in YAML format, to run on boot. The custom script allows for additional Cloud-Init configuration that is supported by Cloud-Init but not available in the Cloud-Init fields. For more information on custom script examples,

Using Cloud-Init to Initialize a Virtual Machine

This procedure starts a virtual machine with a set of Cloud-Init settings. If the relevant settings are included in the template the virtual machine is based on, review the settings, make changes where appropriate, and click OK to start the virtual machine.

1. Click the Virtual Machines tab and select a virtual machine.
2. Click Run Once.
3. Expand the Initial Run section and select the Cloud-Init check box.
4. Enter a host name in the VM Hostname text field.
5. Select the Configure Time Zone check box and select a time zone from the Time Zone drop-down menu.
6. Select the Use already configured password check box to use the existing credentials, or clear that check box and enter a root password in the Password and Verify Password text fields to specify a new root password.
7. Enter any SSH keys to be added to the authorized hosts file on the virtual machine in the SSH Authorized Keys text area.
8. Select the Regenerate SSH Keys check box to regenerate SSH keys for the virtual machine.
9. Enter any DNS servers in the DNS Servers text field.
10. Enter any DNS search domains in the DNS Search Domains text field.
11. Select the Network check box and use the + and - buttons to add or remove network interfaces to or from the virtual machine.
12. Enter a custom script in the Custom Script text area. Make sure the values specified in the script are appropriate. Otherwise, the action will fail.
13. Click OK.

Note: To check if a virtual machine has Cloud-Init installed, select a virtual machine and click the Applications sub-tab. Only shown if the guest agent is installed.

The following table details the options available on the General tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: General Settings

The following table details the options available on the System tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: System Settings

The following table details the options available on the Initial Run tab of the New Virtual Machine and Edit Virtual Machine windows. The settings in this table are only visible if the Use Cloud-Init/Sysprep check box is selected, and certain options are only visible when either a Linux-based or Windows-based option has been selected in the Operating System list in the General tab, as outlined below.

Virtual Machine: Initial Run Settings

The following table details the options available on the Console tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Console Settings

The following table details the options available on the Host tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Host Settings

The following table details the options available on the High Availability tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: High Availability Settings

The following table details the options available on the Resource Allocation tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Resource Allocation Settings

The following table details the options available on the Boot Options tab of the New Virtual Machine and Edit Virtual Machine windows

Virtual Machine: Boot Options Settings

The following table details the options available on the Random Generator tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Random Generator Settings

Important: This feature is only supported with a host running Enterprise Linux 6.6 and later or Enterprise Linux 7.0 and later.

The following table details the options available on the Custom Properties tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Custom Properties Settings

LogicalNetworkName: false

Warning: Increasing the value of the sndbuf custom property results in increased occurrences of communication failure between hosts and unresponsive virtual machines.

You can add custom icons to virtual machines and templates. Custom icons can help to differentiate virtual machines in the User Portal. The following table details the options available on the Icon tab of the New Virtual Machine and Edit Virtual Machine windows.

Virtual Machine: Icon Settings