Okay, sieht so aus als hätte keiner eine Lösung mehr
Posts by WassdSchoBassdScho
-
-
Hi AndreasDe,
danke für deine XML - das Ergebnis ist aber das selbe.
Gruß
-
Wenn ich im Internet nach Beispielen (VM XML) nutzen eigentlich alle eine ähnliche Konfiguration (stets IDE)
-
Die Konfiguration ist aktuell über Univention Corporate Server erstellt worden.
Weitere VMs gibt es nicht.
Die ISO-Datei ist lesbar.
-
Hier noch die XML der VM:
Code
Display More<domain type='kvm'> <name>testsystem</name> <uuid>a69ae851-2333-4899-bdc0-8ed8c1196bfb</uuid> <description>Test</description> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-i440fx-2.8'>hvm</type> <boot dev='cdrom'/> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/testsystem-0.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/debian-9.0.0-amd64-netinst.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='piix3-uhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </memballoon> </devices> </domain>
-
Ich versuche nur eine zu starten.
Die VM hat testweise:1 CPU
1024MB RAM
Dazu wird ein virtuelles CD Laufwerk gemounted, welches auf die debian-netinst.iso (liegt auf dem Server) zugreift.
Es wird auf dem Server (Host) ein qcow2 Image mit einer Größe von 20 GB angelegt.
-
Code
Display Moreprocessor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz stepping : 1 microcode : 0x1 cpu MHz : 2399.996 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch vnmi ept fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat bugs : bogomips : 4799.99 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:
(das ganze natürlich 12x - aber ich darf nur 10.000 Zeichen posten)
Ich sehe auch das VMX aktiv ist, aber trotzdem ist das Ergebnis (egal welche Distribution, egal welcher Kernel etc) immer das selbe gewesen.
-
Ich kann mir nicht vorstellen, dass /dev/shm das Problem war.
Denn diese Werte passen ja nun.
Was mir eben auffällt, ist das wenn ich eine VM starte der qemu-Prozess sofort 100% CPU frisst.
Im SCP (Statistik) ist dann eine CPU ebenfalls komplett auf 100% Auslastung.Und damit bekomme ich wieder die "CPU stuck" Meldungen und der Server friert ein.
Gruß
-
Ich lese nun immer wieder auf anderen Seiten, dass man evtl im BIOS etwas einstellen kann - da komm ich aber natürlich ja nicht hin.
Und ich glaube netcup hilft mir da auch nicht weiter.
-
Nunja, wie auch immer..
Ich habe es nun öfters und mit mehreren Distributionen, verschiedenen Kernels, verschiedenen Lösungen probiert.
Auch "Fertiglösungen" die mit KVM arbeiten (oVirt, Proxmox, Univention Corporate Server) hatten immer das selbe zur Folge: Server ist nicht mehr erreichbar.
Ich werde das nun wahrscheinlich aufgeben..
-
Erst wollte der Support mich auf eine neue Node migrieren, jetzt können sie den Fehler nicht mehr nachvollziehen.
Wenn ich den CMD nun ausführe (3x):
Code
Display More[root@virt1 ~]# dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB) copied, 9.54639 s, 1.1 GB/s [root@virt1 ~]# dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB) copied, 23.0079 s, 456 MB/s [root@virt1 ~]# dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB) copied, 11.2602 s, 931 MB/s [root@virt1 ~]#
Mittlerweile bin ich echt etwas enttäuscht vom Support.
Ich habe den größten Root-Server genommen mit maximaler Laufzeit und zusätzlich direkt das VMX Feature.
Und bekomme nach ewigen Mailketten "wir können das nicht nachvollziehen"....
-
Ich habe es eben mal dem Support geschickt, ich bin gespannt auf die Antwort...
-
Wenn du es noch nicht aufgegeben haben solltest, so könntest du uns mal das erste bis dritte Ergebnis des folgenden Befehls hier posten. Eventuell liegt es auch am IO des RAM´s. Denn deine VM, die du auf deinem Root-Server startest, verhält sich wie ein zusätzlicher Prozeß (ein Prozeß pro Kern deiner VM) auf deinem Root-Server, der in RAM geladen wird. Ist dieser Ladevorgang aufgrund schlechtem IO des RAM´s zu träge, aber die Kerne deines Root-Servers bekommen die volle Leistung pro Kern vom Wirt-System durchgereicht, so steigt zwangsweise auch das Load Average an. Im ungünstigsten Fall friert dein Root-Server - wie auch schon von dir hier berichtet - dadurch ein.
dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output
Im günstigsten Fall sollte der Durchsatz zwischen 1 bis 5 GB/s liegen, um eine virtuelle Maschine darin ohne Probleme starten zu können.Result:
-
Hallo zusammen,
ich habe es auch immer über die Netinst ISOs probiert, das hatte aber nichts geändert.
Gruß
-
Ja, ich habe es noch nicht aufgegeben.
Das liegt daran, dass der Server für ganze 12 Monate gebucht ist.
Da man VMX natürlich nur für alle Prozessoren nehmen kann, läuft das auch für volle 12 Monate.
Und über die Zufriedenheitsgarantie ist netcup nicht bereit, die Kosten für das VMX-Flag zurückzuerstatten.
Hier noch die Ausgabe des CMD:
-
Code
Display More======================================================================== BYTE UNIX Benchmarks (Version 5.1.3) System: virt1: GNU/Linux OS: GNU/Linux -- 4.11.0-1.el7.elrepo.x86_64 -- #1 SMP Mon May 1 09:01:59 EDT 2017 Machine: x86_64 (x86_64) Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8") CPU 0: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 1: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 2: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 3: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 4: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 5: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 6: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 7: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 8: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 9: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 10: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 11: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (4800.0 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 23:55:37 up 4 days, 4:43, 1 user, load average: 0.27, 0.16, 0.07; runlevel 2017-05-11 ------------------------------------------------------------------------ Benchmark Run: Mon May 15 2017 23:55:37 - 00:24:37 12 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 34476963.7 lps (10.0 s, 7 samples) Double-Precision Whetstone 3280.9 MWIPS (15.4 s, 7 samples) Execl Throughput 4817.1 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 1045129.7 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 281916.4 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 2063683.0 KBps (30.0 s, 2 samples) Pipe Throughput 1581611.4 lps (10.0 s, 7 samples) Pipe-based Context Switching 45660.7 lps (10.0 s, 7 samples) Process Creation 6857.7 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 6039.6 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 3069.9 lpm (60.0 s, 2 samples) System Call Overhead 2278268.4 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 34476963.7 2954.3 Double-Precision Whetstone 55.0 3280.9 596.5 Execl Throughput 43.0 4817.1 1120.3 File Copy 1024 bufsize 2000 maxblocks 3960.0 1045129.7 2639.2 File Copy 256 bufsize 500 maxblocks 1655.0 281916.4 1703.4 File Copy 4096 bufsize 8000 maxblocks 5800.0 2063683.0 3558.1 Pipe Throughput 12440.0 1581611.4 1271.4 Pipe-based Context Switching 4000.0 45660.7 114.2 Process Creation 126.0 6857.7 544.3 Shell Scripts (1 concurrent) 42.4 6039.6 1424.4 Shell Scripts (8 concurrent) 6.0 3069.9 5116.5 System Call Overhead 15000.0 2278268.4 1518.8 ======== System Benchmarks Index Score 1318.5 ------------------------------------------------------------------------ Benchmark Run: Tue May 16 2017 00:24:37 - 00:53:53 12 CPUs in system; running 12 parallel copies of tests Dhrystone 2 using register variables 353221518.2 lps (10.0 s, 7 samples) Double-Precision Whetstone 49760.2 MWIPS (11.7 s, 7 samples) Execl Throughput 30148.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 735751.1 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 194307.4 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 2023514.9 KBps (30.0 s, 2 samples) Pipe Throughput 15155597.6 lps (10.0 s, 7 samples) Pipe-based Context Switching 1515684.6 lps (10.0 s, 7 samples) Process Creation 53298.1 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 39069.1 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 6388.9 lpm (60.1 s, 2 samples) System Call Overhead 5881677.5 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 353221518.2 30267.5 Double-Precision Whetstone 55.0 49760.2 9047.3 Execl Throughput 43.0 30148.8 7011.4 File Copy 1024 bufsize 2000 maxblocks 3960.0 735751.1 1858.0 File Copy 256 bufsize 500 maxblocks 1655.0 194307.4 1174.1 File Copy 4096 bufsize 8000 maxblocks 5800.0 2023514.9 3488.8 Pipe Throughput 12440.0 15155597.6 12183.0 Pipe-based Context Switching 4000.0 1515684.6 3789.2 Process Creation 126.0 53298.1 4230.0 Shell Scripts (1 concurrent) 42.4 39069.1 9214.4 Shell Scripts (8 concurrent) 6.0 6388.9 10648.2 System Call Overhead 15000.0 5881677.5 3921.1 ======== System Benchmarks Index Score 5667.3
-
Mit CentOS 7 kommen die Kernel Meldungen auch.
Der Server läuft aber danach weiter, hat aber eine load avarage von >20.0Über VNC komme ich nicht auf meine VM (State running)
VNC ist aber offen:
[root@virt1 var]# netstat -tln|grep :59
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTENWenn ich über VNC verbinden möchte, erhalte ich einen Timeout.
UPDATE: Jetzt - nach gut 10 Minuten - reagiert auch CentOS 7 nicht mehr auf Eingaben.
-
@AndreasDe
habe ich alles schon probiert, es verhält sich immer gleich. -
Hat schon jemand neue Erkenntnisse?
-
->
root@virt1:~# virt-host-validate
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking for device /dev/kvm : PASS
QEMU: Checking for device /dev/vhost-net : PASS
QEMU: Checking for device /dev/net/tun : PASS
LXC: Checking for Linux >= 2.6.26 : PASS
root@virt1:~#