Making it easier to install VMs on XCP: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
m (Superseded by supporting packer and vagrant)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
Note: this has been superseded by adding support to [https://github.com/rdobson/packer-builder-xenserver packer] and [https://github.com/jonludlam/vagrant-xenserver vagrant]

Installing a linux VM on XCP requires the following steps:
Installing a linux VM on XCP requires the following steps:
# Clone a template
# Clone a template
Line 11: Line 13:


Here's an example showing how to install CentOS6:
Here's an example showing how to install CentOS6:
* [[CentOS 6 Virtual Machine installation on Xen]]
* http://grantmcwilliams.com/tech/virtualization/xcp-howtos/560-centos-6-virtual-machine-64-bit-installation-on-xcp


= Ideas for improvement =
= Ideas for improvement =
Line 43: Line 45:





[[Category:XCP]]
[[Category:XAPI Devel]]

Latest revision as of 17:04, 20 January 2015

Note: this has been superseded by adding support to packer and vagrant

Installing a linux VM on XCP requires the following steps:

  1. Clone a template
  2. Add a CDROM or a VIF
  3. Tweak some VM.other_config:parameters (e.g. to include the exact URL of an install repo)
  4. Manipulate the VBD.bootable flags
  5. Answer the VM installer's questions

Ideally we would have

  • Fewer steps (more sensible defaults)
  • More tolerance to user error (e.g. if the network URL isn't perfect, use a heuristic to find the install files)

Here's an example showing how to install CentOS6:

Ideas for improvement

  1. Add a VIF to our default templates to the main management network. This would make network installation easier.
  2. If no network install URL is provided, fall back to a known good one
    1. Even better would be to use a tool like Debian netselect to choose a good one
  3. If a network install URL is provided but it slightly wrong (typical failure would be to point at a subdirectory by mistake), attempt to auto-correct it
  4. If a CDROM is attached, attempt to detect the install files and work out what kind of system it is (debianlike or rhlike)
  5. Allow the user to request an auto-install via an answerfile or preseed file
    1. Even better would be to serve-up default answerfiles from the system
Getting away from eliloader

Some operating systems (Debian Lenny/Squeeze/Wheezy, Ubuntu ~L,M,N,O, OpenSuse) can be easily installed via pre-shipped initrd (netinst) and kernel. This will:

  1. Reduce all operations with other-config:install-repository
  2. Allow to install operating systems without internet connectivity between dom0 and internet (note: guests can have it, but dom0 no more), this will make isolation of management network more reliable (Someone ether though about attack on dom0 via bad initrd, f.e. very big to eat all dom0 disk space?).
  3. Simplify steps to start VM
  4. elilo can be used for other templates (like older rhel with initrd patching).
Allow local console for PV-guests.

When user make xe vm-start for initially created vm from special template, we can do following:

  1. disable vnc console for initial startup (one time)
  2. run VM on host where command was entered (will not work with remote xe)
  3. do xl console for VM domain.

User expirience will be very nice: xe vm-install template=BoBoBo, xe vm-start, and user got console of installing virtial machine.


Measuring the improvements

  1. Count the number of characters you need to type to install a particular guest type (eg Debian 6.0). Lower is better.