2009-07-09 12 views
0

Derzeit haben wir verschiedene Build/Test-Boxen für die Entwicklung. Die Zielanwendung wird hauptsächlich in Python/gcc geschrieben, verwendet Postgres und hat zwei identische USB-Geräte angeschlossen.Gesucht: ein Beispiel für Application Built/Test Server Visualisierung

Die wichtigsten Build-Betriebssysteme sind RHEL, FreeBSD & XP auf i686. Die App muss regelmäßig auf einigen Releases jedes Betriebssystems gebaut und getestet werden.

(Vielleicht der nächste Schritt wäre auf Bonus OSes zu testen/release/CPUs zB Fedora, SuSE, Debian, Solaris und Vista, sowohl für 32-Bit- und x86-64-Hardware, vielleicht sogar PPC.)

Ich hatte gehofft, dass ich einfach die vorhandenen Dateisysteme direkt auf ihr eigenes Logical Volume eines Visualisierungsservers (Xen oder VMWare) kopieren, die VMs booten und die vorhandenen Testanzüge verwenden könnte.

Dann könnten wir jeden Tag das Ziel OSes Logical Volume in den Originalzustand zurückversetzen und dann die Build- und Testskripts ausführen.

Ein VM/LV pro Testserver, der auf einer Visualisierungsbox läuft, scheint eine gute Idee zu sein, aber ich habe einige Probleme festgestellt.

Probleme bisher begegnet sind:

VMWARE

Griffe BIOS/Hardware besser, nicht wie eine VM auf VLM

  1. Wont Boot eine virtuelle Maschine aus einem logischen Volumen.
  2. FileSystems muss für VMWare-Snapshots in VMFS konvertiert werden.

XEN

Logical Volume Schnappschüsse perfekt funktionieren und LVs erweitert werden kann.

  1. Probleme Umgang XP & FreeBSD
  2. Probleme mit rohen USB-Geräten sichtbar zu machen.
  3. Es gibt auch Probleme mit X11 hängen.

Ich habe keine anderen Visualisierungslösungen ausprobiert. {Wikipedia virtualization software}

Gibt es noch andere Möglichkeiten oder Pfade, die ich berücksichtigen sollte?

Anregungen, Arbeitsbeispiele, Whitepaper und/oder FAQ zu solchen Testsystemen sind willkommen.

Ben

Antwort

0

ich VirtualBox einen Versuch geben werde, um zu sehen, ob es VMs auf ihre auf Logical Volumes vgl umgehen kann VMWare equivalent