mubuntuHH
Projektleitung
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
Hallo Gemeinde, ich muss zum ersten mal eine VM headless auf einen Ubuntu-Server laufen lassen. Eine PHP-App die unter PHP 7.0 läuft, aber noch nicht unter PHP 7.1+ soll bis zur Portierung auf das neuste PHP auf einer VM laufen. Habe sowas bisher immer mit VirtualBox gemacht, was aber jetzt nicht geht, da die ja eine GUI braucht. Anforderungen:
die Guest-Machine soll mit Ubuntu 16.04 laufen (ja, obwohl die bald EOl hat...) sie muss vom Intranet/Internet erreichbar sein sie muss per SSH vom Host aus erreichbar sein
Gegeben ist:
Bisheriger Ansatz:
Habe mit kvm und qemu (alles Neuland für mich) eine VM erstellt. Das hat geklappt. Sie mit den o.g. Anforderungen laufen zu lassen, hat ebenfalls geklappt, und zwar so:
| qemu-system-x86_64 -enable-kvm -hda qemu/ubuntu-server-16.04.img -m 384 -nographic -curses -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80
|
Da klappt wunderbar, die VM ist wie gewünscht erreichbar. Jetzt kommt das Aber: Ich krieg's irgendwie nicht hin, die qemu-VM im Hintergrund laufen zu lassen. D.h. die Host-Mashine soll "ganz normal" wie immer laufen und die VM quasi im Hintergrund. Mit meiner Lösung muss ich ja immer die Konsole, auf der ich den o.g. Befehl eingegeben habe, laufen lassen, sonst wird die VM beendet. Wie kriege ich das hin? Ich konnte partout nichts eindeutiges dazu finden, was mich wundert, denn ist das nicht einer der Hauptanforderungen an VMs dass sie einfach im Hintergrund laufen? Das Sahnehäubchen wäre dann natürlich noch, dass die VM bei jeden Neustart des Host mit gestartet wird... 😇 Danke schon mal!
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Alles ohne Weiteres möglich. Für den Anfang könntest du dir den virt-manager dazuholen, da kann man das per GUI einstellen, inkl. automatischem Start. Damit umgehst du auch das Problem mit dem ssh-terminal-login und Start (da wäre eine virsh , systemd/unit, tmux oder screen eine manuelle Alternative). Wenn du den XML-Kram da aktivierst, kannst du auch die Einstellungen parallel im internen Editor anpassen. QEMU bietet auch noch Infos/Links.
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
ChickenLipsRfun2eat schrieb: Alles ohne Weiteres möglich.
Das macht ja schon mal Hoffnung ☺ ... Allerdings suche ich eine Lösung, die ohne GUI auskommt. Denn die VM soll ja auf einen Ubuntu Server (also CLI only) laufen. Ich fürchte, ich muss das von Dir genannte virsh nutzen. Schade, denn ich habe mir in studenlanger Recherche im Netzt so schön den (o.g.) Befehl für qemu zusammengebastelt:
qemu-system-x86_64 -enable-kvm -hda qemu/ubuntu-server-16.04.img -m 384 -nographic -curses -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80
☹ Wie kann ich den in virsh implementieren/übersetzen?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Du kannst den virt-manager auch in deinem GUI-buntu installieren und per ssh auf den Server zugreifen. Falls du mehrere Ports oder exotischere Konfigurationen hast, kannst du das einmalig mit virt-manager -c 'qemu+ssh://user@host:/system?socket=/var/run/libvirt/libvirt-sock' aufrufen und von dort die VMs bedienen. Ich habe mir allerdings die ~/.ssh/config angepasst, wegen der PublicKeys und kürzeren Schreibweise. Und ja, ich habe damals auch mit dem zusammenbasteln angefangen und mich im nachhinein geärgert. Beispiel für eine Bionic-Webinstallation: 1
2
3
4
5
6
7
8
9
10
11
12
13 | virt-install \
--name ubusrv \
--ram 4096 \
--disk pool=default,size=20,bus=virtio,format=qcow2 \
--vcpus 2 \
--os-type linux \
--os-variant ubuntu18.04 \
--network network:default \
--graphics none \
--console pty,target_type=serial \
--location 'http://gb.archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/' \
--extra-args 'console=ttyS0,115200n8 serial' \
--force --debug
|
Damit legst du eine neue VM mit Ubuntu Bionic an. Netzwerk ggf. anpassen, ich nutze bei mir systemd-Bridges.
Wie kann ich den in virsh implementieren/übersetzen?
Was meinst du? Dürfte vorinstalliert sein: für die oberste Hierarchie. Ist ein Monster-Werkzeug, daher bin ich in dem Fall für die GUI-Lösung. Ansonsten kannst du dich natürlich gerne mit https://www.libvirt.org/manpages/virsh.html auseinandersetzen. Falls du deine bestehende VM meinst: spuckt dir die XML-Version aus, die du z.B. mit virsh create nutzen kannst. Dein nächster Freund wäre dann virsh autostart NAME 😉
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
Danke - auch für die Bsp.-Konfiguration. Bevor ich die ausprobiere: Ich habe ja schon ein fertiges, laufendes img für eine VB (erstellt mit qemu). Ich möchte die eigentlich lediglich auf meinen ubuntu 20.04-Server 24/7 im Hintergrund laufen lassen (eine Art Daemon? Es gibt ja auch die Option "-daemonize"). Also: ich logge mich per SSH auf meinen VM-Host (namentlich Ubuntu Server 20.04) ein, und bediene (starten, stoppen, etc) die VM. fertig. Ich bin wirklich überrascht, dass das ein Sonderwunsch zu sein scheint. Beim Suchen fand ich viele verschiedene Lösungen, die bei mir alle nicht funktionierten. Ich mein, tausende Webhoster machen das doch auch, wenn sie Virtuelle Server anbieten. Wie kann ich den in virsh implementieren/übersetzen?
Was meinst du? Dürfte vorinstalliert sein
Also, ich meinte, kann ich, und wenn ja wie, die qemu-Befehlszeile (s.o.) von mir mit virsh umsetzen.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ja, das geht auch. Das einfachste wäre deine Befehlszeile in eine systemd-unit zu setzen und diese zu aktivieren. Besser noch ein systemd-timer, damit zunächst alles andere geladen werden kann. Also Neustart +2 Minuten oder sowas. Längerfristig wäre natürlich virsh oder der virt-manager die bessere Option, da die auch für Ubuntu angepasste Hardware-sets mitbringen. Ab 20.04 ändert sich aber der Installer, da habe ich mich noch nicht drum gekümmert, daher auch die 18.04-Installation als Beispiel. Vom ISO geht natürlich auch immer. Deine bestehende VM kannst du theoretisch übernehmen. Siehe RedHat:Converting QEMU arguments to domain.xml. Der erstellt dir dann aus der qemu-Konfiguration eine XML, nicht aber aus der qemu-Befehlszeile. Wenn der Server so wie er ist einwandfrei und flott läuft, kannst du das machen. Andernfalls böte sich eine Ubuntu-Server-Vorkonfiguration an, in der du dann die entsprechenden Daten abändern könntest.
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
So: Die Guest Machine im Hintergrund laufen zu lassen, funktioniert jetzt. Und zwar so:
qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize
-display none und -daemonize sind die Geheimzutaten. Aber Deinen Tipp mit systemd-unit umzusetzen, habe ich nicht hingekriegt. qemu_ubuntu_server_16.04.service-Datei:
| [Unit]
Description=qemu VS Ubuntu-Server 16.04
[Service]
Type=simple
ExecStart=qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize
[Install]
WantedBy=multi-user.target
|
sudo service qemu_ubuntu_server_16.04 status:
| ● qemu_ubuntu_server_16.04.service - qemu VS Ubuntu-Server 16.04
Loaded: loaded (/etc/systemd/system/qemu_ubuntu_server_16.04.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2021-03-26 15:52:50 CET; 14min ago
Process: 4192 ExecStart=/usr/bin/qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize (code=exited, status=0/SU>
Main PID: 4192 (code=exited, status=0/SUCCESS)
Mär 26 15:52:50 lenovo systemd[1]: Started qemu VS Ubuntu-Server 16.04.
Mär 26 15:52:50 lenovo qemu-system-x86_64[4218]: qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
Mär 26 15:52:50 lenovo systemd[1]: qemu_ubuntu_server_16.04.service: Succeeded.
lines 1-9/9 (END)
|
[EDIT]
Der Dienst scheint laut systemctl zwar zu laufen, aber die VM ist nicht per SSH erreichbar. Der Webserver läuft auch nicht.
[/EDIT] Any ideas? An Zeile Nr. 8 kann's nicht liegen, denn beim manuellen Start der VM gab's diesbezüglich keine Probleme.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ideen schon, aber keine Ahnung 😉 Was sagt journalctl -b -xep err auf dem Host? Deine Unit wird als root ausgeführt. Bevor ich es verbastelt habe, lief das bei mir unter nobody:kvm, habe meinen VMs allerdings einen eigenen Nutzer spendiert, weswegen es auch libvirt gewesen sein könnte. Hab gerade nichts unverbasteltes zum nachgucken da. Falls also die VM läuft, aber nicht erreichbar ist, könnte das daran liegen. AppArmor kann auch eine Rolle spielen, da weiß ich nicht, inwiefern das libvirt beeinflusst. Andere Möglichkeit: 16.04 hatte afair noch nicht alles auf systemd umgestellt. Vielleicht hakt es auch deswegen. War keine so glückliche Version aus der Sicht. Was sagt denn der libvirt- und qemu-Krempel? systemctl status libvirtd.service libvirt-guests.service
ps aux | grep -E 'virt|qemu'
systemctl status libvirt*.socket
Da müssten beide services loaded, dead sein, aber mit SUCCESS-Meldung und mindestens ein libvirtd-Prozess mit timeout (Standard 120) aktiv sein. Plus deine gestartete VM. Wenn du den Status der sockets abruft, müssten diese aktiv sein. Falls der Prozess aktiv ist und die VM „nur“ nicht erreichbar: Exec=/usr/bin/bash --verbose -c 'qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize'
Dann wird das Kommando in einer bash ausgeführt, die gesprächiger ist. Könnte sich im journalctl zeigen. Daneben gäbe es noch die Option des monitoring, die müsste ich aber auch nachlesen. Anstatt bash könntest du natürlich auch das display wieder aktivieren und tmux nutzen. Reichen 256MB RAM denn für alles? Was die Netzwerkgeschichte angeht: -nic user ist zwar Standard, aber ich habe das ehrlich gesagt noch nie verwendet. Ich arbeite mittlerweile ausschließlich mit Bridges (eine mit Inet-Zugang, eine ohne) und habe davor sockets verwendet, damit die VMs untereinander quatschen konnten. Aber ich bin ja auch nur Heimnutzer 😉 Wie sieht denn die Host-Konfiguration aus? Theoretisch müsste es (mindestens) ein virtuelles Netzwerkdevice geben.
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
ChickenLipsRfun2eat schrieb: Was sagt journalctl -b -xep err auf dem Host?
Keine Fehlermeldungen zu kvm, qemu oder meinen qemu_ubuntu_server_16.04.service Andere Möglichkeit: 16.04 hatte afair noch nicht alles auf systemd umgestellt. Vielleicht hakt es auch deswegen. War keine so glückliche Version aus der Sicht.
Der Host ist aber 20.04. ☺ Was sagt denn der libvirt- und qemu-Krempel?
systemctl status libvirtd.service libvirt-guests.service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 |
● libvirtd-admin.socket - Libvirt admin socket
Loaded: loaded (/lib/systemd/system/libvirtd-admin.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 39min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-admin-sock (Stream)
Tasks: 0 (limit: 4402)
Memory: 0B
CGroup: /system.slice/libvirtd-admin.socket
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt admin socket.
● libvirtd.socket - Libvirt local socket
Loaded: loaded (/lib/systemd/system/libvirtd.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 39min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-sock (Stream)
Tasks: 0 (limit: 4402)
Memory: 68.0K
CGroup: /system.slice/libvirtd.socket
Apr 03 21:25:23 home-server systemd[1]: Starting Libvirt local socket.
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt local socket.
● libvirtd-ro.socket - Libvirt local read-only socket
Loaded: loaded (/lib/systemd/system/libvirtd-ro.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 39min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-sock-ro (Stream)
Tasks: 0 (limit: 4402)
Memory: 0B
CGroup: /system.slice/libvirtd-ro.socket
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt local read-only socket.
|
ps aux | grep -E 'virt|qemu'
| root 912 0.0 1.0 1363452 38768 ? Ssl 21:25 0:00 /usr/sbin/libvirtd
libvirt+ 1190 0.0 0.0 9244 2240 ? S 21:25 0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
root 1191 0.0 0.0 9216 336 ? S 21:25 0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
foo 6717 0.0 0.0 6900 664 pts/0 S+ 22:13 0:00 grep --color=auto -E virt|qemu
|
(Usernamen mit "foo" anonymisiert.)
systemctl status libvirt*.socket
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 | ● libvirtd-admin.socket - Libvirt admin socket
Loaded: loaded (/lib/systemd/system/libvirtd-admin.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 50min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-admin-sock (Stream)
Tasks: 0 (limit: 4402)
Memory: 0B
CGroup: /system.slice/libvirtd-admin.socket
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt admin socket.
● libvirtd.socket - Libvirt local socket
Loaded: loaded (/lib/systemd/system/libvirtd.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 50min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-sock (Stream)
Tasks: 0 (limit: 4402)
Memory: 68.0K
CGroup: /system.slice/libvirtd.socket
Apr 03 21:25:23 home-server systemd[1]: Starting Libvirt local socket.
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt local socket.
● libvirtd-ro.socket - Libvirt local read-only socket
Loaded: loaded (/lib/systemd/system/libvirtd-ro.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-03 21:25:23 CEST; 50min ago
Triggers: ● libvirtd.service
Listen: /run/libvirt/libvirt-sock-ro (Stream)
Tasks: 0 (limit: 4402)
Memory: 0B
CGroup: /system.slice/libvirtd-ro.socket
Apr 03 21:25:23 home-server systemd[1]: Listening on Libvirt local read-only socket.
|
Da müssten beide services loaded, dead sein, aber mit SUCCESS-Meldung und mindestens ein libvirtd-Prozess mit timeout (Standard 120) aktiv sein.Plus deine gestartete VM.
Die VM ist, soweit ich die Ausgaben deuten kann, nicht gestartet. Auch htop zeigt keinen qemu-Prozess. Sehe ich das richtig? Und woran könnte das liegen?
Falls der Prozess aktiv ist und die VM „nur“ nicht erreichbar: Exec=/usr/bin/bash --verbose -c 'qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize'
Dann wird das Kommando in einer bash ausgeführt, die gesprächiger ist. Könnte sich im journalctl zeigen.
Dein Tipp funzt nur mit ExecStart (statt nur Exec). Alle obigen Ausgaben sind mit der Option verbose geschehen.
Reichen 256MB RAM denn für alles?
Erstaunlicherweise ja. Die LAMP-Anwendung läuft flott und auch SSH ist flüssig.
Aber ich bin ja auch nur Heimnutzer 😉
Ich im Prinzip auch. Die Anwendung wir derzeit nur von einem Kunden mit nur 1 User aufgerufen. ☺
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Die VM ist, soweit ich die Ausgaben deuten kann, nicht gestartet. Auch htop zeigt keinen qemu-Prozess. Sehe ich das richtig? Und woran könnte das liegen?
Sehe ich genauso. ExecStart ist natürlich richtig, da war ich geistig wohl beim Desktop-File. Anderer Versuch. Pack die Zeile mal in ein bash-Script, bspw. nach /usr/local/bin/: | #!/bin/bash
heute=$(date +'%Y_%m_%d')
exec 2> /var/log/qubuntu_error_$heute.log > /var/log/qubuntu_$heute.log
qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize
|
ExecStart dann auf /usr/local/bin/script.bash umstellen. Dann gibt es Logfiles für Fehler und den Rest. Vielleicht haben wir da mehr Informationen. Ansonsten baue ich mir das anhand deiner Zeile die Tage mal nach. Es gibt immer so ein paar Fallstricke, wie bspw. bis vor kurzem parallel docker betreiben → 865975. Nicht immer leicht einzugrenzen. Da der qemu-Kram in /usr/bin liegt, können wir zumindest die PATH-Variable außen vor lassen 😉
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
Anderer Versuch. Pack die Zeile mal in ein bash-Script, [...] Dann gibt es Logfiles für Fehler und den Rest. Vielleicht haben wir da mehr Informationen.
Gute Idee! Aber irgendwie bleibt es still. ☹ Einzig und allein die bekannte Warnung:
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
erscheint, was ja eigentlich bedeuten sollte, dass die VM gestartet wurde. Komisch das. Hatte noch gar nicht erwähnt, dass es ein Rechteproblem gibt. ☺
Händisch muss der Befehl:
qemu-system-x86_64 -enable-kvm -hda /home/foo/qemu/ubuntu-server-16.04.img -m 256 -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -daemonize
mit sudo ausgeführt werden, sonst kommt:
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
So musste ich also Dein Script nach /sbin verschieben, sonst lies sich der Service nicht starten ("Permission denied"). Diese Meldung kam schon, als das Script auf /var/log schreiben wollte, was alles komisch ist, denn ich dachte /systemd/system-Dateien, werden standardmäßig als root ausgeführt.
Ansonsten baue ich mir das anhand deiner Zeile die Tage mal nach.
Wow, was ein Service! Ich hoffe, wir können Dir das noch ersparen, irgendwie habe ich trotz allen das Gefühl, dass wir nah dran sind! 😀
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Okay. Ich versuche hier gerade die Userversion. Problematisch ist vermutlich nur, dass ich eine bestehende ubuntu-Platte verwende. Da dürften sich die Netzwerkconfigs in die Wolle kriegen. Aber es geht ja nur ums automatische starten 😉 Mein Script meldet folgende Fehler:
Anschliessend gibt ps aux : virty 30075 70.5 2.6 860032 437424 ? Sl 14:25 0:18 qemu-system-x86_64 -enable-kvm -hda /var/lib/libvirt/images/ausgelagert/xubuntu.qcow2 -m 384 -curses -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -nographic
Läuft also mit systemctl start qscript
Das funktioniert auch direkt in der Unit :
systemctl edit --full --force qscript 1
2
3
4
5
6
7
8
9
10
11
12 | [Unit]
Description=qemu script starter
[Service]
Type=simple
User=virty
Group=kvm
WorkingDirectory=~
#ExecStart=/usr/bin/bash -c '/home/virty/.local/bin/qscript.bash'
ExecStart=qemu-system-x86_64 -enable-kvm -hda /var/lib/libvirt/images/ausgelagert/xubuntu.qcow2 -m 384 -curses -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80 -display none -nographic
[Install]
WantedBy=multi-user.target
|
Als nächstes wäre dann ein echtes Serverimage mit Erreichbarkeit gefragt, falls es nicht klappt. Wie hast du deine Installation denn erstellt?
…erscheint, was ja eigentlich bedeuten sollte, dass die VM gestartet wurde. Komisch das.
Vielleicht wird sie das, aber es gibt andere Probleme. Der Nutzer, der die VM startet muss in der Gruppe kvm sein, was auch dein Berechtigungsproblem erklärt. Wenn du einen Nutzer angibst, braucht dieser entweder eine dbus-Umgebung oder du musst die Pfade für alles mögliche selbst angeben. In dem Fall reichte mir die WorkingDir. Ansonsten wirft die Unit nach ner Weile einen timeout und schießt den Prozess wieder ab. Mit dem Script klappt es allerdings nicht „einfach so“, weil man für die shell builtins die Umgebung laden muss (s.o.). Hab ich auch neu gelernt.
|
rleofield
Anmeldungsdatum: 14. September 2008
Beiträge: 779
Wohnort: Görlitz
|
mubuntuHH schrieb: Hallo Gemeinde, ich muss zum ersten mal eine VM headless auf einen Ubuntu-Server laufen lassen. Eine PHP-App die unter PHP 7.0 läuft, aber noch nicht unter PHP 7.1+ soll bis zur Portierung auf das neuste PHP auf einer VM laufen. Habe sowas bisher immer mit VirtualBox gemacht, was aber jetzt nicht geht, da die ja eine GUI braucht. Anforderungen:
Eine Bridge bauen und die VM damit verbinden. Dann ist das wie ein PC im lokalen Netz. https://lug-ottobrunn.de/wiki/Virtualisierung_mit_KVM#VM_im_User-Space https://www.lug-ottobrunn.de/wiki/Virtualisierung_mit_KVM#VM_im_lokalen_Netz.2C_.28in_192.168..2A..2A.29 https://www.lug-ottobrunn.de/wiki/Virtualisierung_mit_KVM#Beispiel Die Texte sind schon einige Jahre alt, funktionieren aber noch ganz gut. Kann sein, dass man die eine oder andere Option 'modernisieren' muss, weil 'deprecated' kommt. Ich betreibe damit seit Jahren eine Horde von VMs im Userspace, die als PC im lokalen Netz sind. Alles was man da braucht, wie SSH, SAMBA, rdesktop usw, ist damit ok. Alternativ kann man 'libvirt' verwenden. Einfach nach der Anleitung hier im Wiki installieren und eine neue VM an die Brigde binden. Libvirt verwendet intern auch den Schalter '-vnc' (s.u.) und bringt einen VNC-Viewer gleich mit.
Gegeben ist:
Bisheriger Ansatz:
Habe mit kvm und qemu (alles Neuland für mich) eine VM erstellt. Das hat geklappt. Sie mit den o.g. Anforderungen laufen zu lassen, hat ebenfalls geklappt, und zwar so:
| qemu-system-x86_64 -enable-kvm -hda qemu/ubuntu-server-16.04.img -m 384 -nographic -curses -nic user,hostfwd=tcp::2222-:22,hostfwd=tcp::8089-:80
|
Da klappt wunderbar, die VM ist wie gewünscht erreichbar. Jetzt kommt das Aber: Ich krieg's irgendwie nicht hin, die qemu-VM im Hintergrund laufen zu lassen. D.h. die Host-Mashine soll "ganz normal" wie immer laufen und die VM quasi im Hintergrund. Mit meiner Lösung muss ich ja immer die Konsole, auf der ich den o.g. Befehl eingegeben habe, laufen lassen, sonst wird die VM beendet. Wie kriege ich das hin?
'-vnc :n' verwenden. Dann kann man mit 'vncviewer server:n' den Desktop anschauen oder auch nicht. Die VGA Ausgabe ist dann weg. In den man-pages zu qemu nachschauen. Der Port ist 5900+n. Und für die VMs verwende ich Overlays, das spart Zeit beim Backup. I hope this helps. rleofield
|
mubuntuHH
Projektleitung
(Themenstarter)
Anmeldungsdatum: 28. November 2010
Beiträge: 864
Wohnort: Hamburg, Germany
|
ChickenLipsRfun2eat schrieb: -daemonize entfernt
Das hat mich auf eine Idee gebracht! Vielleicht vertragen sich die "beiden Dämonen" ja nicht: Also der qemu Daemon (mit option -daemonize gestartet) und der systemd-Service. Habe jetzt auch einfach mal die Option -daemonize innerhalb der qemu_ubuntu_server_16.04.service-Datei weggelassen. Et voilà: Es funktioniert! Genau wie gewünscht! Juhu! Auch der systemd Timer funktioniert einwandfrei! Vielen Dank, ChickenLipsRfun2eat für Deine vielen Tipps! Wenn der Host heruntergafahren wird, stoppt systemd dann eigentlich die VM "gracefully" oder killt sie einfach nur den Prozess? Letzeters wäre auf Dauer ja nicht so gut für das Ubuntu, das auf der VM läuft, oder? @rleofield: Vielen Dank für Deine ausführliche Antwort! Scheinbar gibt's ne Menge Möglichkeiten, eine VM headless im Hintergrund laufen und im Netzwerk erreichbar zu machen, wie Deine Antwort zeigt. Ich versuch's jetzt erst mal mit der von ChickenLipsRfun2eat und mir ausgetüftelten Lösung, es sei denn Du siehst da einen gefährlichen Schnitzer darin?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
mubuntuHH schrieb: Wenn der Host heruntergafahren wird, stoppt systemd dann eigentlich die VM "gracefully" oder killt sie einfach nur den Prozess? Letzeters wäre auf Dauer ja nicht so gut für das Ubuntu, das auf der VM läuft, oder?
Nee, die wird einfach gekillt. Deswegen sagte ich ja anfangs schon, dass eine über virsh oder virt-manager aufgesetzte VM einfacher zu handhaben ist. Du kannst aber ein systemd-inhibit setzen, wenn ein shutdown/reboot verlangt wird deine VM herunterfahren (kann man die auch speichern, wenn sie so gestartet wird?) und dann den inhibit wieder lösen.
…Scheinbar gibt's ne Menge Möglichkeiten…
Bedingt alles die Steuerung per XML, die wir ja in diesem Experiment absichtlich weggelassen haben. Aber ja, es gibt unzählige Möglichkeiten. Bridges nutze ich wie anfangs beschrieben auch. Ist auch für mich das bequemste, da muss ich dem rleofield recht geben.
Ich versuch's jetzt erst mal mit der von ChickenLipsRfun2eat und mir ausgetüftelten Lösung, es sei denn Du siehst da einen gefährlichen Schnitzer darin?
Ich sehe da mehrere „Probleme“. Du müsstest dir noch Methoden zum Status abrufen/speichern/beenden/snapshotten der VM basteln, die Netzwerkanbindung läuft auf dem Host, etc. Aber zum Absichern mögen andere mehr beitragen können. Bei mir ist nichts von außen erreichbar, weswegen ich das dann zwar nach besten Ge-/Wissen mache, aber keine praktischen Erfahrungen damit habe.
|