Features/VirtRemoteInstall

Remote Virtual Machine Installation

Summary

Enable creating virtual machines on properly configured remote hosts.

Owner

• Name: ColeRobinson

Current status

• Targeted release: Fedora 10
• Last updated: September 11, 2008
• Percentage of completion: 100%

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

• Follow steps in test plan for VirtStorage to create storage on a remote host
• Use virt-manager and virt-install for each of the following on the remote host:
  • Test install methods --pxe and --cdrom with managed storage
  • Test with vm storage as a an existing volume
  • Test with vm storage allocated on an existing pool

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

• libvirt: storage support (Done)
• python-virtinst
  • cli interface in virt-install for specifying managed storage (Done)
  • virtinst api extensions to support managed storage (Done)
• virt-manager:
  • Use extended virtinst apis for remote storage management during install (Done)
  • Poll avahi for remote libvirt instances when adding a connection (Done)

Contingency Plan

Ordered priorities for incomplete items:

• virt-install managed storage interface
• basic virt-manager managed storage support (use existing interface, check to see if specified path is managed on host)
• avahi libvirt polling
• thorough virt-manager storage integration (basically replace all File Chooser dialogs with a pool + volume listing, with option for local file chooser and allocating storage on existing pools)

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.

• Perhaps worth listing the things that don't work over a remote connection?
  • the remote device discovery
  • enumeration of bridges not possible over remote connection
  • storage volumes not available during wizard guest creation

Comments and Discussion

• See Talk:Features/VirtRemoteInstall

---