Features/VirtRemoteInstall

From FedoraProject

Jump to: navigation, search

Contents

Remote Virtual Machine Installation

Summary

Enable creating virtual machines on properly configured remote hosts.

Owner

Current status

Detailed Description

Fully support remote guest creation in virt-install and virt-manager. This entails allowing a way to specify existing managed storage on the remote connection, or provisioning new storage on an existing pool at install time. Install methods are either PXE or a managed cdrom.

Ideally coupled with this will be better remote connection support: use libvirt's avahi advertising to search for potential remote connections when adding a connection in virt-manager.

Benefit to Fedora

Remote VM installation isn't for everyone but it's pretty compelling for folks managing more than one physical machine for virtualization. A central box can be used to do all provisioning, where previously an admin would have to interact directly with the host. This will also encourage interested users to manage their storage and installation media using libvirt's storage capabilities, whose benefits are outlined at the VirtStorage feature page.

Scope

Changes are largely limited to python-virtinst (virt-install) and virt-manager. Infrastructure is already present in libvirt, excluding necessary bug fixes. This will augment existing local guest creation by adding the option to choose managed storage rather than specifying a path manually, but the remote case is an entirely new feature.

Test Plan

User Experience

Users will no longer need to log into individual machines to provision VMs. Adding remote connections to virt-manager will be largely automated through polling for connections on the local network.

Use Case "Local": User needs to Remote Install on a local network that does not traverse firewalls. This is the most likely Use Case and provides significant convenience for users.

Objective: 

Allow a user to install virtual machines when the user does not have direct physical access.

Assumptions:

  1. User has full privileges to act on target machine.
  2. User has uninterrupted network access.
  3. SSH or other secure connection can be used or tunneled through.

Requirements:

  1. Remote install software should not require specific version matching of libvirt, Python, Virtual Machine Manager, Desktop manager, or other tools on either user's workstation or remote virtual host.
  2. Remote install software should provide information on what commands will be run.
  3. Remote install software will test for reasonable failure conditions before executing tasks that take more than 90 seconds.

Outcome:

  1. A user will be able to manage larger numbers of virtual machines from a centralized location. The user will not have to require all virtual hosts to upgrade to specific software levels and will be able to manage guest Operating Systems environments in the process of upgrading.


Use Case "Corporate": User needs to Remote Install across organizational boundries, or between networks with different security constraints, or over a network that requires documented processes, ports, procedures, or accountabilities.

The Assumptions, Requirements, and Outcomes of this Use Case are cumulative with "Use Case Local".

Assumptions:

  1. The authority for the user to access servers in this use case is not a part of the software provided.
  2. Secure connection should not require specific software versions less than 18 months GA.
  3. Remote Install should use explicitly defined and configurable network ports if the transport protocol is not SSH or other industry standard.

Requirements:

  1. Remote install tools will be available with the Operating System media and will not require packages or modules not included in the base OS distro.
  2. Installation will allow for guest OS media to be stored locally to the host server. For example, the host server may have ISO images for the guest OS version to be installed.
  3. Installation will not require any physical access to the host server, to include inserting a Cd or DVD into a local drive.
  4. Remote install will be tolerent of some network latency and will be able to function if the user's workstation is connected via VPN.
  5. Remote install will not require significant data pushed downstream to the user's workstation, as this would overload many remote workers connected via DSL or Cable.
  6. Remote install will be able to locate and utilize standard Kickstart installation procedures, i.e. NFS, virtual CD, URL, and filesystem.

Outcome:

  1. A corporate user will be able to function while working from home or working in a large organization with multiple lines of business or a complex organizational structure. User will be able to install in a lab that is on a restricted or isolated network, and to machines in a remote datacenter.


Use Case "Global": User will be able to install virtual machines across the Internet.

The Assumptions, Requirements, and Outcome of this Use Case is cumulative with "Use Case Local". While not required to be so, many of the concepts in this Use Case conflict with Use Case "Corporate".

Assumptions:

  1. Permissions to access the target machine may be transient. All required permissions and software packages with version information should be explicitly documented.
  2. User workstation and host server may not be in the same timezone, may not have similar UTC settings, may not have the same human languages installed, and may not be running the same OS major or minor versions.

Requirements:

  1. All actions that change the host or guest state should be logged on the host, and the log should be configurable via Syslog or equivalent for remote logserver data capture.
  2. Remote install should allow for network disconnect after a command has been issued but before return codes are captured. Return codes should be logged.
  3. Remote install should be able to send "In Progress" messages to the logs if a Debug level of logging is configured.

Outcome:

  1. A skilled user can act as a mentor/senior for a remote user and help configure multiple servers globally. Also, a remote datacenter that does not have VPN type access can use remote install to increase server count in case of a disaster recovery or business continuity needs.

Dependencies

Contingency Plan

Ordered priorities for incomplete items:

As needed, chop off pieces from the bottom on up. The first two parts are required for this feature, the others will make the experience much cleaner. (FYI, feature is complete, but the last option here was too much work in the short term so will not be included).

Documentation

virt-install remote support patches and discussion Wiki pages to be written once interfaces land.

Release Notes

Hmm, this shouldn't break any current functionality. Instructions on how to use the feature can be written after the interfaces are worked out.

Comments and Discussion

Retrieved from "https://fedoraproject.org/wiki/Features/VirtRemoteInstall"