Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Difference between revisions of "VM storage plan"

From Livedoc - The Documentation Repository
Jump to: navigation, search
(New page: This is a proposal for a new VM system, discuss here. Sign with four ~ . Here's how the plan goes: ==== Storage ==== * Some sort of JBOD hooked up to a Sun server, like betelgeuse * ex...)
 
Line 11: Line 11:
 
==== Scripting ====
 
==== Scripting ====
 
There are a lot of ways you could create a central management system for this sort of VM setup. You could have a script that brings down VM's on one server and brings them up another, periodically pings hosts, etc. If a host goes down, you could tell iSCSI to stop sharing with that server until further notice and switch to another server. This is just one of several possibilities. There's also always the option of manual management.
 
There are a lot of ways you could create a central management system for this sort of VM setup. You could have a script that brings down VM's on one server and brings them up another, periodically pings hosts, etc. If a host goes down, you could tell iSCSI to stop sharing with that server until further notice and switch to another server. This is just one of several possibilities. There's also always the option of manual management.
 +
 +
==== Locking ====
 +
All vm servers will have access to a shared nfs filesystem which will contain all the xen vm configurations and lockfiles for the vms preventing simultaneous starting (ask Thomas to elaborate on locking).

Revision as of 14:15, 16 June 2009

This is a proposal for a new VM system, discuss here. Sign with four ~ . Here's how the plan goes:

Storage

  • Some sort of JBOD hooked up to a Sun server, like betelgeuse
  • ext3-formatted zvols exported as iSCSI devices offer rollback and snapshots, as well as compression
  • Live-migration is as simple as taking the vm down on one server and bringing it up on the other, since it's a block device on every server it's exported to.

System

  • Dom0's are Gentoo VM server images. We have a separate image for VM servers like we do with the cluster and with the workstations. However they don't use systemimager. Instead they install binary packages. The packages install on the cluster, or shodan, or some other available system.
  • DomU's are Debian except for ltsp. Debian is simpler and we can't keep an image for every VM -- the software varies too much. Compiling on the VM to update is definitely not ideal. Thus, Debian is a better option, and it's arguably more stable.

Scripting

There are a lot of ways you could create a central management system for this sort of VM setup. You could have a script that brings down VM's on one server and brings them up another, periodically pings hosts, etc. If a host goes down, you could tell iSCSI to stop sharing with that server until further notice and switch to another server. This is just one of several possibilities. There's also always the option of manual management.

Locking

All vm servers will have access to a shared nfs filesystem which will contain all the xen vm configurations and lockfiles for the vms preventing simultaneous starting (ask Thomas to elaborate on locking).