Virtueller Rechner mit Grafik

  • bzw. gestartet?


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Irgendwie scheine ich mit XEN kein Glück zu haben.
    Ich habe jetzt opeenSUSE 42.3 und das XEN-Paket installiert. Im Boot-Menü kann ich wählen zwischen dem normalen und dem XEN-Kernel. Allerdings melden beide bei 'uname -a' das Gleiche:


    Linux linux-7117 4.4.76-1-default #1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 x86_64 GNU/Linux


    Was gibt 'zgrep XEN /proc/config.gz' denn aus?


    Christian

  • Der Weg zu XEN scheint ein Steiniger zu sein...


    Wenn ich den normalen Kernel boote, dann wird die CPU-Frequenz dynamisch geregelt:


    grep MHz /proc/cpuinfo:


    cpu MHz : 1019.974
    cpu MHz : 1000.092
    cpu MHz : 1237.151
    cpu MHz : 2155.583
    cpu MHz : 2653.104
    cpu MHz : 2006.667
    cpu MHz : 1003.861
    cpu MHz : 1000.103


    Beim XEN-Kernel sieht das so aus:


    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174
    cpu MHz : 2904.174


    Das heißt, dort laufen alle Kerne immer mit maximaler Frequenz, was sich natürlich auch in entsprechender Wärmeentwicklung äussert.
    Ist das bei XEN grundsätzlich so, oder kann man das irgendwo einstellen?


    Klaus

  • Yes. Guggst du hier.


    Gruß
    iNOB

  • Danke. Ich wollte jetzt mal, wie auf dieser Seite angegeben, "cpufreq=dom0-kernel" beim Booten angeben, aber das ist ja auch alles nicht mehr so klar und übersichtlich, wie es mal war :-(. Die Datei /boot/grub2/grub.cfg wird aus verschiedensten Quellen generiert, und ich weiß echt nicht, wo ich da "cpufreq=dom0-kernel" einfügen sollte. Also hab ich es einfach mal direkt in /boot/grub2/grub.cfg reingeschrieben (auch wenn man das eigentlich nicht soll ;-):


    Ob das aber wirklich die richtige Stelle ist, ist fraglich, denn nach einem Reboot liefen immer noch alle CPUs mit maximaler Frequenz. Wobei ich das in der dom0 auflisten lasse, falls das wichtig sein sollte. Erstmal muß die dom0 vernünftig laufen, bevor es überhaupt Sinn macht, weiterzumachen...


    Klaus

  • So weit mir bekannt, trägt man bei openSUSE den Parameter in der /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT="... ein und führt dann grub2-mkconfig aus. Das überlebt dann auch das nächste Suse-Update. :).

    Dr. Brömme grübelt:
    Acht Wochen, nachdem man ihm beim Kölner Straßenkarneval einen Gratiskorn angeboten hatte,
    dämmert ihm langsam, dass er einem hinterlistigen Alaafisten aufgesessen ist.

  • Der Weg zu XEN scheint ein Steiniger zu sein...


    Das Durchreichen der einzigen GraKa ging bei mir mit dem XenCenter besser als erwartet. Anbei ein inxi vom KUbuntu-ISO


    Werde es auch mit der Linuxvariante vom XenCenter versuchen.

    HD-VDR 1&2 : Asrock N68C-S UCC, ASUS EN210 Silent, Boot IDE CF-Card, /srv auf SATA Samsung 3TB
    HD-VDR 1 : Sempron145, yavdr 0.4, TeVii S480 V2.1 DVBs2 Dual
    HD-VDR 2 : Sempron140, yavdr 0.5, DD Cine S2 V6.5 + DuoFlex S2
    Server (im Aufbau): Asrock B75M R2.0 mit i5-3470T sowie Zotac GT970 & DD Cine S2 V6.5 für Gastsysteme
    - Host: Manjaro-XFCE mit 4.4er Kernel mit qemu und virt-manager

  • Das heißt, dort laufen alle Kerne immer mit maximaler Frequenz, was sich natürlich auch in entsprechender Wärmeentwicklung äussert.
    Ist das bei XEN grundsätzlich so, oder kann man das irgendwo einstellen?


    Wenn ich mich nicht irre, siehst Du in dom0 genauso wie in domU nur virtuelle CPUs, vcpus. dom0 ist da letztendlich nur eine privillegierte domU, unter all dem ist der hypervisor. dom0 also neben den domU, nicht unter diesen.


    Bei mir macht der hypervisor das power-management, den Unterschied der Frequenzen sieht man in der dom0:


    governor ist bei mir auf ondemand:



    Christian

  • hopsi : stimmt, das sehe ich mit den (inzwischen wieder hergestellten) Standardeinstellungen hier auch. Dann muß die Wärmeentwicklung wohl von was Anderem gekommen sein (es war gestern sehr heiß hier ;-).


    Allerdings verstehe ich nicht, warum in /proc/cpuinfo nicht gleich die richtigen Werte ausgegeben werden. Sowas führt doch nur zu Verwirrung. Gleiches sollte sich immer gleich verhalten...


    Klaus

  • ich frage mich gerade warum so kompliziert ...


    Die Zeit, die in die Xen und co Virtualisierung gesteckt wurde, und eine Lösung scheint immer noch nicht in Sicht ... da ist es doch viel effektiver sich ein NAS ( HP Microserver ) in den Keller zu stellen, Datenbanken und OS etc. auf die SSD zu speichern und als Storage HDDs rein - fertig. 215 mb/s sind mit LAN Aggregation kein Thema und viel mehr schaffen die Billig SSDs auch nicht. Ich hatte vor der o.g. Lösung auch an Paravirtualisung gedacht aber aus genau den im Thread genannten Gründen mich dann für eine dedizierte Server Client/Desktop Lösung entschieden. Mein HP Microserver ist mit einer 2x DVB-S2 Karte an der Schüssel angebunden, die vdr Installation mit vnsi streaming für die clients verwaltet und streamt alles im netzwerk, NAS Daten werden via autofs/sshfs eingebunden. OMV gabs beim Aufsetzen des o.g. Systems nur auf Debian 7 Basis, Debian 8 war schon draußen und so hab ich auch OMV weggelassen.


    Die ganzen Software Lösungen wie Virtualisierung OMV und co sind alle schön und gut aber je komplizierter ein System, je fehleranfälliger ist es auch. Virtualisierung nutze ich auf meinem Desktopsystem zwar auch, aber die Speicherpfade bzw. Virtualboximages liegen direkt auf dem NAS. So habe ich de facto einmal ~200mb/s für die VMS und nochmal 400 mb/s fürs native System auf der verbauten SSD. Virtualbox und das Virtualbox Webinterface sind auf dem NAS als Backup installiert, sodass ich bei einem Desktopausfall die VMs auch über das NAS starten oder Routing VMs im Headlessmodus permanent laufen lassen kann.
    Video Konvertierung z.b. läuft dann je nach Zeitvorgabe auf dem Dekstop in der VM oder auf dem NAS in der VM. Wie jetzt im Urlaub ist der Desktop Rechner aus und das NAS konvertiert Videos, Strombilanztechnisch sicher auch etwas günstiger als den Desktop laufen zu lassen.


    PS : ne uptime von 560 Tagen ... gabs da keine kernelupdates ? 1,5 Jahre ohne Kernelupdate kann ein Sicherheitsrisiko sein ?(


    PSS : wenns natürlich um das herumspielen mit ParaVMs geht und der Erfolg das Ziel ist o.g. Lösung nicht das Gelbe vom Ei :rolleyes:


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO 860 Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de

  • Wenn man es einmal verstanden hat, ist das mit XEN gar nicht so schwer. Ubuntu Server 16.04 LTS als Basis für die Dom0 genommen, entsprechende Config für die Domus erstellt und schon kann man sich auslassen. Liegt halt immer am eigenen Ermessen, ob man seine Zeit für so etwas opfern möchte. By the way... mein erster XEN-Server hatte knapp 2 Jahre Uptime ;)

  • Allerdings verstehe ich nicht, warum in /proc/cpuinfo nicht gleich die richtigen Werte ausgegeben werden. Sowas führt doch nur zu Verwirrung. Gleiches sollte sich immer gleich verhalten...


    Du sitzt einem Missverständnis auf.
    Bei Xen hast Du es mit einem Klasse 1 Hypervisor zu tun. D.h. die Dom0, in die das System bootet, ist selbst nur eine VM. Diese ist zwar zur Verwaltung des Hypervisors privilegiert, aber dennoch nur eine VM.
    Auf /proc/cpuinfo siehst Du also letztlich auch nur eine virtuelle CPU, nicht den direkten Durchgriff auf die physische.
    Der Kernel der Dom0 läuft selbst nur unter Kontrolle des Hypervisors.
    Willst Du wissen, was das Powermangement der physischen Maschine macht, dann musst Du den Hypervisor fragen und nicht den Kernel der virtuellen Maschine (in dem Fall Dom0).
    Das geht dann mit xenpm.
    Wenn Du Powermanagement für die Dom0 einrichtest, dann machst Du Powermanagement für eine virtuelle Maschine (was eher sinnfrei ist).


    Gleiches passiert, wenn Du z.B. mit Top schauen willst, was auf der Maschine so los ist. Du siehst nur Prozesse Deiner VM. In dem Falle also Prozesse der Dom0.
    Willst Du wissen, was insgesamt auf der Maschine los ist, dann musst Du xentop verwenden. Das greift auf die Daten des Hypervisors zurück und liefert damit echte Werte.


    Dieser Umstand ist bei Xen erstmal etwas verwirrend. Daran muss man sich gewöhnen.
    Diese vermeintliche Unsinnigkeit kommt daher, das die Verwaltungsinstanz für den Xen Hypervisor eben eine Linux-Instanz ist (eben die Dom0), aber eben selbst nur eine VM.



    Um es noch mehr zu verdeutlichen:
    Man kann und sollte der Dom0 auch nicht alle CPUs zugestehen. Sie braucht die normalerweise gar nicht. Meistens reicht für die Dom0 eine vCPU. Dann siehst Du dort und /proc/cpuinfo auch nur eine CPU.
    Noch deutlicher beim Arbeitspeicher:
    Die Dom0 sollte im Arbeitspeicher beschränkt werden (je nach Aufgaben reicht 1 GB). Damit sieht man in der Dom0 auch wieder nur den zugewiesenen Speicher.
    Lässt man der Dom0 den vollen Arbeitspeicher, dann hat das folgenden Effekt:
    Immer, wenn ein Gast gestartet wird, muss der Arbeitsspeicher der Dom0 erst reduziert werden. Damit welcher für den Gast frei ist.
    Der Gast läuft ja nicht als Prozess auf der Dom0, sondern als eigentständige VM neben der Dom0. Also muss der Dom0 Speicher erst weggenommen werden, um ihn dem neuen Gast zuzuweisen.


    Mehr dazu hier: https://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance

  • Danke, das war mir so in der Tiefe nicht klar. Ich dachte die "dom0" sei "die physikalische Maschine".


    Das dürfte dann wohl auch der Grund sein, warum "sensors" immer die gleichen Werte liefert, obwohl sich die Belastung der CPU ändert:


    acpitz-virtual-0
    Adapter: Virtual device
    temp1: +27.8°C (crit = +119.0°C)
    temp2: +29.8°C (crit = +119.0°C)


    asus-isa-0000
    Adapter: ISA adapter
    cpu_fan: 0 RPM


    Gibt es für die CPU-Temperatur auch einen "Durchgriff" auf die Hardware? Hab leider nichts dazu gefunden.


    Klaus

  • Klaus, die sensoren sollte korrekte Werte liefern, wenn die passenden Sensoren abgefragt werden. acpitz-virtual-0 klingt da erst mal verdächtig falsch.


    Die Werte bei Abfrage in der dom0 ändern sich bei mir auch, wenn ich etwas Last in einer domU erzeuge.



    Christian

  • Ja, sensors-detect hab ich gemacht. Hat aber nichts gefunden:


    Klaus

  • Vermutung: Kernel: 4.4 ist etwas alt für Kaby Lake. 4.4 ist aus Januar 2016, Kaby Lake wurde erst 2017 vorgestellt.


    Da fehlen dann wohl die Treiber für Sensoren auf Board und Prozessor. Würde auf 4.10 oder gleich 4.11 wechseln.


    Christian