• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

"Vollwertige" V-Server Angebote mit Appliance Import Möglichkeit

consuli

Member
Hallo!

Ich suche einen "vollwertigen" V-Server, bei dem ich eine Standard Appliance (ein Standard Virtual Machine Image), z.B. von
  • bitnami.com
  • turnkeylinux.org
  • market.vmware.com/vsx (z.T. kostenpflichtig)
  • osboxes.org/virtualbox-images (nur Betriebsystem ohne Anwendungen)

direkt importieren kann und lediglich mit Änderungen an der Netzwerkkonfiguration sofort lauffähig habe.

Vielen Massenhoster, z.B. 1und1, beschneiden ihre Hypervisoren und die Basisimages (aus betrieblichen Gründen) derart, dass ein "Orignal-Image" aus einer lokalen VMWare-Workstation Installation oder einer lokalen Virtualbox Installation auf deren Virtual Server nicht mehr nativ läuft.

Fragen:
  1. Welche Kompatibilitätskriterien gibt es bei V-Server Angeboten?
  2. Wie heißt der Suchbegriff für "vollwertige" V-Server, bei denen man eine Appliance direkt importieren kann und die Applaince bis auf Netzwerkkonfiguration sofort nativ lauffähig ist?
  3. Was muss ich sonst noch beachten?
 
Last edited:
Z.B. hat 1und1 zwar Vmware aber nicht Vmware ESXI. Mir hat jemand erzählt, dass nur ein Typ-I Bare-Metal-Hypervisor wie Vmware ESXI vollständig maschinen-unabhängige Images produziert. Stimmt das?
 
Last edited:
Guten Abend,

unsere vollvirtualisierten NVMe-Server (https://php-friends.de/vserver-ssd) werden mit KVM bereitgestellt und ermöglichen dies. Die ISO müsste zwar über unseren Support bereitgestellt werden, wir sind allerdings bekanntermaßen sehr flott im Support :)

Viele Grüße
Tim Schneider
 
Vielleicht frage ich besser anders herum.

Welche Konfigurationsarbeiten - außer Netzwerkkonfiguration - bleiben noch übrig, wenn man eine

  1. eine Vmware Appliance in einen Vmware V-Server beim Hoster importiert
  2. eine Virtualbox Appliance in einen Virtualbox V-Server beim Hoster importiert
  3. eine Qemu/KVM Appliance in einen Qemu/KVM V-Server beim Hoster importiert
?

Fallen bei jedem V-Server Angebot die gleichen (Rest-)Konfigurationsarbeiten an?
 
Eigentlich sollte da außer der Netzwerkkonfiguration (und ggf. damit einhergehend udev / MAC-Adresse) nichts übrig bleiben. Wenn ein komplettes Image eingespielt wird, sollte nicht einmal der Bootloader neuinstalliert werden müssen.
 
Bitnami bietet ja OVAs an. Die kann man ohne Probleme in VMware importieren. Die holen sich auch die IP via DHCP.

Normalerweise muss man VMs von/auf VMware-Fusion / VMware-Workstation gar nicht exportieren und in ESXi importieren. Sofern Zugriff auf das vCenter besteht, kann Fusion/Workstation direkt auf vCenter zugreifen und die VMs dorthin verschoben/kopiert werden. Bei Massenhostern ist aber vermutlich der direkte Zugrif auf vCenter (-API) nicht möglich.
 
Eigentlich sollte da außer der Netzwerkkonfiguration (und ggf. damit einhergehend udev / MAC-Adresse) nichts übrig bleiben. Wenn ein komplettes Image eingespielt wird, sollte nicht einmal der Bootloader neuinstalliert werden müssen.
Gängige Typ-II Hypervisoren (wie Vmware Workstation, Virtualbox und Qemu/KVM) machen ja Paravirtualisierung mit Hardwareunterstützung. Dazu nutzen sie die Virtualisierungserweiterungen der CPUs, also Intel-VM und AMD-V.

Läuft ein Virtual Machine Image, das auf einer AMD-Prozessor Maschine erstellt wurde, denn problemlos auf einer Intel-Prozessor Maschine und umgekehrt?

Zur Not auch mit im Bios ausgeschalteter Virtualisierungserweiterung (wenn auch langsamer)?
 
Läuft ein Virtual Machine Image, das auf einer AMD-Prozessor Maschine erstellt wurde, denn problemlos auf einer Intel-Prozessor Maschine und umgekehrt?

Bei Standard-Kernel von Debian, Centos usw. ist Intel % AMD kein Problem.
 
Läuft ein Virtual Machine Image, das auf einer AMD-Prozessor Maschine erstellt wurde, denn problemlos auf einer Intel-Prozessor Maschine und umgekehrt?

In den meisten Fällen ist das kein Problem. Das Problem von Prozessoren unterschiedlicher Hersteller oder Generationen muss primär berücksichtigt werden, wenn man Lifemigrationen in gemischten Virtualisierungs-Clustern durchführen will - hier muss man auf Hypervisor-Seite ggfl. CPU-Features maskieren und so den kleinsten gemeinsamen Nenner finden.
Die Überprüfung, welches Features eine CPU unterstützt, findet vom Betriebssystem-Kernel i.d.R. nur beim Systemstart statt. Hast du also ein Image, wird dessen Betriebssystemkern diese Überprüfung beim Starten durchführen. Es kann natürlich Systeme geben, sie sehr auf eine CPU optimiert sind. Dort solltest du aber entsprechende Angaben bei dem Image finden.
 
Die Livemigration ist aber Sache des Hosters. Dieser wird keine Livemigration auf einen Host durchführen, der aus der Sicht inkompatibel ist. Zumindest KVM lässt dies auch gar nicht erst zu. Bei einer 1:1 durchgereichten CPU muss das Zielsystem dieselbe CPU bzw. dieselben Befehlssätze / Flags besitzen bzw. verstehen. Beim durchreichen des CPU-Modells kommen als Ziel noch "ähnliche" CPUs in Frage und mit einer virtuellen CPU kann man überall hin migrieren.
 
Ja, ich wollte mit dem Hinweis auf die Lifemigration auch nur darauf hinweisen, an welcher Stelle die Frage nach Intel oder AMD eine Rolle spielt.
Natürlich gibt es auch Systeme, die tatsächlich eine CPU eines bestimmten Herstellers erfordern - MacOS bespielsweise, wobei man das lizenztechnisch ohnehin nur virtuell auf einem Mac betreiben darf, und somit immer einen Intel-Prozessort vorfindet.
 
Back
Top