English
资源说明：Control a cluster of virtualized servers via Rails
= LabVirt
LabVirt aims to be a virtualized machine controlling and reporting
tool.
== Design criteria
LabVirt aims to provide the controlling tool for a group of
laboratories. Each laboratory can use different profiles - This
means, the computers in this laboratory can be served by different
virtual machine images.
(the above description should be further completed)
=== Virtualization infrastructure
The virtualization scheme to be supported is Linux's KVM. Maybe we
will be able to provide for different schemes (i.e. qemu, xen, etc.)?
It is desirable to be able to run each virtualized machine under a
non-root user - But as the most adequate networking scheme is the
tun/tap interface, I still don't know whether this is possible.
=== Monitoring/administration facilities
The following aspects should be available via the Web monitoring facility:
- Defined machine classes or laboratories
- Active virtual machines
- Available profiles
- Manage different profiles for each real machine. Each profile is a
different virtual disk image
- Profiles should be clonable by an administrator to derive from
them
- The profiles will often be used snapshotted, this means, the
clients' writes to the disk image should be discarded in order to
keep the profiles clean (i.e. re: viruses, registry degradation,
installed programs, etc). Many hosts will share a single disk
image in a typical lab setting.
- An administrative profile will exist for each lab
profile. The only difference is that the disk image will not be
launched in snapshot mode, but in a regular/updatable
way. Launching the administrative profile should shutdown all of
the machines of said profile (or should not be allowed as long as
there are clients running with it).
- Affinity/availability of each profile for each laboratory
- Resource consumption for each host (probably better served as a
hook/link to a separate Munin[http://munin.projects.linpro.no/]
instance?
- Which virtual machines are currently serving an established
connection? (that means, which virtual machines have a connected
terminal?) (How can this be known without invasively adding a
queriable daemon to each virtualized host? Pinging each terminal to
check for its assigned virtual host is too artesanal)
- The whole application is to be internationalizable, via Gettext
=== Terminals
This project is based on the idea of having several user profiles,
which we will temporarily group under the "lab" term (although it
might not be the best term... bear with it for now. A "lab" can be
spread out over several offices, for what is worth)
The computers that make up a lab will, for our purposes, be treated as
mere terminals. After booting, they will be only configured to connect
to us via HTTP and fetch a very basic configuration, which will be
used to initialize the +rdesktop+ client.
Said machines will have basically zero self-knowledge. The server
dictates what IP address they should connect to. We have full control
of the user experience. BWAHAHAHA.
=== Assumptions
I decided to assume several things about this project's deployment -
It is better to document them upfront and in a single place than to
forget about them.
- Virtualization is made through kvm (or qemu, which is
command-line-options compatible). Xen is out of the question for
now. And using libvirt gives some nice abstractions, but does not
provide some needed facilities (i.e. disks based on snapshots).
- Virtual hard drives are sequentially filled. That means, if you are
emulating IDE drives, the first one will be primary-master, the
second primary-slave, the third secondary-master, the fourth
secondary-slave. What implications does this have? That it is very
preferrable for CD-ROMs to be secondary-masters (i.e. their
performance will be much better than if they are primary- or
secondary-slaves). Insert a dummy disk at primary slave and hide it
at the operating system level if this becomes an issue for you.
- Virtual hosts will boot from the first HD. This means that if you
need to boot from a CD-ROM, you will have to launch the host
manually. Don't panic - We will provide a command line so you don't
have to panic.
- VNC for virtual hosts will only be available through Unix-domain
sockets, not exposed to the network. That means, you need to at
least have SSH access to the server in order to connect to the VNC
sessions.
- Ironically, please note I still don't know _how_ to connect to VNC
via Unix-domain sockets :-/ Anyway, there are... more things to
solve before hitting this.
- Using the +virtio+ network interface is strongly advised - Of
course, this is no good when installing an operating system, as
they do not include the drivers. Install your host using a
well-known interface card emulation (i.e. RTL8139), and switch it
over to virtio
- Networking is done using the +TAP+ kernel interface. In order for
an unprivileged user to be able to start the hosts, you will have to
give him +sudo+ rights for the needed commands - namely, +ifconfig+,
+brctl+ and +tunctl+.
- You have and control a DHCP server, that will give each virtual host
a predictable IP address based on its MAC address. This is
fundamental if you want to be able to connect to them!
== Current status
As of today, this project... Does not do anything useful, and is quite
far from being advertisable.
== Authors
Gunnar Wolf , Instituto de Investigaciones
Económicas, UNAM
Many details on interfacing with KVM (i.e. building the invocation
command and querying for the guest hosts' status) were taken from
Freddie Cash's fine "kvmctl" scripts, which can be found at:
http://kvm.qumranet.com/kvmwiki/HowToConfigScript
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18368
http://www.sd73.bc.ca/downloads/kvmctl-2.0.0.tbz
== Licensing
This project is developed and distributed under an MIT-style license.
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
