VMware-Forum

Hi,

ich habe seit einiger Zeit das Problem, dass meine drahtlose USB-Maus nach dem Starten des Systems in der VM nicht richtig funktioniert, Sie bewegt sich, man kann auch auf auf alles klicken und die Anzeige verändert sich kurzzeitig, aber es passiert nichts. Heißt: kein Fenster öffnen oder schließen, nichts markieren oder sonst etwas geht.
Folgende Fehlerbehebung funktioniert:
mit der Tastatur in die Einstellungen -> Geräte -> Maus, Tastatur und Stift -> hier "VMWare virtual USB Maus" Gerät entfernen. Dann funktioniert sie wieder wie sie soll. Das System erkennt und installiert gleich wieder eine neue Maus, aber bis zum Neustart habe ich erst mal keine Probleme.
Entfernen im Greätemanager dagegen bringt nichts. Nach Neustart geht das Spiel meistens (aber nicht immer) von vorne los.

Systeme: Host und Gast Windows 10 Pro 1903 beide auf aktuellem Stand, Maus: Logitech USB Blutooth
Vmaware Workstation 15.5.2 (allerdings funktionierte es bei der 15.0 auch schon nicht)

Was ich schon gemacht habe: VMware.tools neu installiert, in den Einstellungen "gespielt" mit verschiedenen USB-Einstellungen. USB-Kontroller in der VM entfernt und neu eingebunden (mehr als einer geht ja nicht).
Alles ohne Erfolg.
Was ich nicht machen möchte: VMWare oder Windows neu installieren. In einer Linux-VM hatte ich bisher noch keine Probleme.

Tante google zeigte mir, dass schon mal jemand dasselbe Problem unter WindowsXP hatte, aber alle die angezeigten Lösungen halfen auch nicht weiter.
Jetzt brauche ich Eure Hilfe...

Gruß Rollo

Lade dir wie im Thread VMware-Tools für Workstation, Player, Fusion und vSphere beschrieben eine ältere Tools-Version herunter und probiere damit. Die Tools haben hin und wieder Probleme nach den M$-Updates und müssen etwas angepaßt werden.

Hallo,

danke erst mal. Hat aber leider nichts gebracht. Das Problem bleibt weiterhin bestehen...

eventuell noch andere Lösungsansätze? Das ist zwar nur ein kleines Problem, da ich es relativ schnell beheben kann, aber eine dauerhafte Lösung wäre mir lieber. Ist eben nur nervig.

Wird irgendwie aus versehen und automatisch die USB Maus an die VM gereicht?

Wie verhaelt es sich wenn du per RDP zugreifst?

Gruss
Joerg

irix hat geschrieben:Wird irgendwie aus versehen und automatisch die USB Maus an die VM gereicht?

ich weiß nicht genau was Du damit meinst.
Ich nutze die VM schon längere Zeit. Das Problem besteht erst seit ca. 1/2 Jahr ohne Veränderungen an der Konfiguration. Wie oben beschrieben habe ich ja verschieden Einstellungen ohne Erfolg getestet.

Wie verhaelt es sich wenn du per RDP zugreifst?

RDP funktioniert irgendwie nicht, weil ich in der VM kein Passwort vergeben habe. Da kommt bei der Anmeldung dann eine (wie bei Windows üblich nichtssagende) Fehlermeldung.
Werd's mal testen, wenn ich etwas mehr Zeit habe.

wenn es keine einfache Lösung gibt, werde ich wohl damit leben müssen. Ich weiß ja wie man es bei jedem Start abstellen kann. Ist eben nur nervig...

Hänge mal bitte die gezippten "vmware.log" an und wir schauen uns das mal genauer an. Vielleicht entdecken wir Möglichkeiten zur Problemlösung.

Hattest du zuvor mal die WS-Version aktualisiert?
Hast du die automatische Aktualisierung von VMware-Tools oder v.HW-Version immer abgelehnt?

Hallo Dayworker,

anbei die gewünschte Zip-Datei.

Automatishe Updates der VM-tools hatte ich deaktiviert. Hab's zwar jetzt eingeschaltet, aber VMWare sagt immer, dass alles auf dem aktuellsten Stand ist.

ach ja, noch ein Hinweis: im Augenblick habe ich die VM ohne Probleme gestartet. Wie gesagt tritt das Problem nicht immer auf, aber immer öfter.

Datei habe ich mir schon geladen...

acpi.mouseVMW0003 = "FALSE"
acpi.smbiosVersion2.7 = "FALSE"
checkpoint.vmState = ""
cleanShutdown = "TRUE"
config.version = "8"
cpuid.coresPerSocket = "3"
displayName = "Clone of Windows 10 pro"
ehci.pciSlotNumber = "34"
ehci.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.displayName = "VMnet0"
ethernet0.generatedAddress = "00:0C:29:9B:15:A9"
ethernet0.generatedAddressOffset = "0"
ethernet0.pciSlotNumber = "37"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.wakeOnPcktRcv = "FALSE"
extendedConfigFile = "Clone of Windows 10 pro.vmxf"
floppy0.autodetect = "TRUE"
floppy0.present = "FALSE"
floppy0.startConnected = "FALSE"
guestOS = "windows9-64"
guestOS.detailed.data = ""
gui.exitOnCLIHLT = "TRUE"
gui.lastPoweredViewMode = "fullscreen"
gui.stretchGuestMode = "fullfill"
gui.viewModeAtPowerOn = "fullscreen"
hgfs.mapRootShare = "TRUE"
hpet0.present = "TRUE"
mem.hotadd = "TRUE"
memsize = "5792"
migrate.hostlog = ".\Windows 10 pro-21f0d00a.hlog"
mks.enable3d = "TRUE"
monitor.phys_bits_used = "43"
numa.autosize.cookie = "30032"
numa.autosize.vcpu.maxPerVirtualNode = "3"
numvcpus = "3"
nvram = "Clone of Windows 10 pro.nvram"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "TRUE"
pciBridge4.functions = "8"
pciBridge4.pciSlotNumber = "21"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge5.pciSlotNumber = "22"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge6.pciSlotNumber = "23"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
pciBridge7.pciSlotNumber = "24"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
policy.vm.mvmtid = ""
powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.reset = "soft"
powerType.suspend = "soft"
replay.filename = ""
replay.supported = "FALSE"
sata0.pciSlotNumber = "36"
sata0.present = "TRUE"
sata0:0.deviceType = "rawDisk"
sata0:0.fileName = "Clone of Windows 10 pro-0.vmdk"
sata0:0.redo = ""
sata0:1.autodetect = "TRUE"
sata0:1.deviceType = "cdrom-raw"
sata0:1.fileName = "auto detect"
sata0:1.present = "TRUE"
sata0:1.startConnected = "FALSE"
scsi0.pciSlotNumber = "160"
scsi0.present = "TRUE"
scsi0.sasWWID = "50 05 05 63 64 a4 0a d0"
scsi0.virtualDev = "lsisas1068"
scsi0:0.fileName = "Windows 10 pro-cl1.vmdk"
scsi0:0.present = "TRUE"
scsi0:0.redo = ""
scsi0:1.deviceType = "rawDisk"
scsi0:1.fileName = "Clone of Windows 10 pro.vmdk"
scsi0:1.present = "TRUE"
scsi0:1.redo = ""
scsi0:2.deviceType = "rawDisk"
scsi0:2.fileName = "Clone of Windows 10 pro-3.vmdk"
scsi0:2.redo = ""
serial0.fileName = "thinprint"
serial0.fileType = "thinprint"
serial0.present = "TRUE"
sharedFolder.maxNum = "2"
sharedFolder0.enabled = "FALSE"
sharedFolder0.expiration = "never"
sharedFolder0.guestName = "Portable"
sharedFolder0.hostPath = "C:\Portable"
sharedFolder0.present = "TRUE"
sharedFolder0.readAccess = "TRUE"
sharedFolder0.writeAccess = "TRUE"
sharedFolder1.enabled = "TRUE"
sharedFolder1.expiration = "session"
sharedFolder1.guestName = "Usb-Laufwerk"
sharedFolder1.hostPath = "F:\"
sharedFolder1.present = "TRUE"
sharedFolder1.readAccess = "TRUE"
sharedFolder1.writeAccess = "TRUE"
sharedFolder2.enabled = "TRUE"
sharedFolder2.expiration = "never"
sharedFolder2.guestName = "F"
sharedFolder2.hostPath = "F:\"
sharedFolder2.present = "FALSE"
sharedFolder2.readAccess = "TRUE"
sharedFolder2.writeAccess = "TRUE"
softPowerOff = "TRUE"
sound.autodetect = "TRUE"
sound.fileName = "-1"
sound.pciSlotNumber = "33"
sound.present = "TRUE"
sound.virtualDev = "hdaudio"
svga.graphicsMemoryKB = "524288"
svga.guestBackedPrimaryAware = "TRUE"
svga.maxHeight = "768"
svga.maxWidth = "1024"
svga.vramSize = "268435456"
tools.remindInstall = "FALSE"
tools.syncTime = "FALSE"
tools.upgrade.policy = "useGlobal"
toolsInstallManager.lastInstallError = "0"
toolsInstallManager.updateCounter = "20"
usb.pciSlotNumber = "32"
usb.present = "TRUE"
usb.vbluetooth.startConnected = "TRUE"
usb:1.deviceType = "hub"
usb:1.parent = "-1"
usb:1.port = "1"
usb:1.present = "TRUE"
usb:1.speed = "2"
usb_xhci.pciSlotNumber = "192"
usb_xhci.present = "TRUE"
usb_xhci:4.deviceType = "hub"
usb_xhci:4.parent = "-1"
usb_xhci:4.port = "4"
usb_xhci:4.present = "TRUE"
usb_xhci:4.speed = "2"
usb_xhci:5.deviceType = "hub"
usb_xhci:5.parent = "-1"
usb_xhci:5.port = "5"
usb_xhci:5.present = "TRUE"
usb_xhci:5.speed = "4"
usb_xhci:6.deviceType = "hub"
usb_xhci:6.parent = "-1"
usb_xhci:6.port = "6"
usb_xhci:6.present = "TRUE"
usb_xhci:6.speed = "2"
usb_xhci:7.deviceType = "hub"
usb_xhci:7.parent = "-1"
usb_xhci:7.port = "7"
usb_xhci:7.present = "TRUE"
usb_xhci:7.speed = "4"
usb_xhci:8.deviceType = "hid"
usb_xhci:8.parent = "4"
usb_xhci:8.port = "0"
usb_xhci:8.present = "TRUE"
uuid.bios = "56 4d 0d d3 64 a4 0a da-59 f2 0d 3a 33 9b 15 a9"
uuid.location = "56 4d 51 94 11 db e4 8f-89 b8 0d 8f c0 1f 75 b1"
vc.uuid = ""
vhv.enable = "TRUE"
virtualHW.productCompatibility = "hosted"
virtualHW.version = "16"
vm.genid = "-2217812903918890492"
vm.genidX = "-9056518419840362736"
vmci0.id = "1514904761"
vmci0.pciSlotNumber = "35"
vmci0.present = "TRUE"
vmotion.checkpointFBSize = "4194304"
vmotion.checkpointSVGAPrimarySize = "268435456"
vmxnet3.serialNumberV2 = "FALSE"
vpmc.enable = "TRUE"
vvtd.enable = "TRUE"

Hat die VM eigentlich einen funktionalen Zweck oder ist das nur eine Machbarkeitsstudie?
Du gibst der VM ganze 3 Kerne auf 3 Sockel sprich 9 vCPUs und gönnst der VM auch 5792MB vRAM. Eine ungerade CPU-Kernanzahl, wie mal von AMD vor einigen Jahren eingesetzt, ist etwas unvorteilhaft und hatte zu einigen OS-Problemen geführt. Deine Hexacore-CPU i7-8750H mit HT bietet zwar 12 logische Kerne, aber die Arbeit muß nachher doch wieder von den 6 physischen Kernen geleistet werden. Läuft auf dem Host sonst noch eine SW, bekommt die VM in jedem Fall durch den VMware-Hypervisor nur dann Rechenzeit zugeteilt, wenn 9 logische Kerne frei sind. Die VM wird mit diesen Einstellungen also immer langsam in der Ausführung sein und etwaige Handhabungsprobleme wie keine Reaktion auf Mausaktionen in der VM dürften sich fälschlicherweise als Grafikprobleme zeigen, obwohl sie rein CPU-limitiert verursacht sind. Eine sehr schnelle NVMe-SSD als Host-Datenträger könnte die VM etwas beschleunigen, würde aber zeitgleich auch wieder viel CPU-Leistung binden und nimmt man dann noch das weiterhin existente VMware-Auslagerungsverhalten hinzu, bleibt die VM langsam. Um dem etwas entgegen zu wirken, bindest du alle vDISK als RAWDISK sprich per physischen Datenträgerzugriff ein.
Du hast die VM auch als sogenannte Nested-VM (vhv.enable="true") konfiguriert, damit wird etwaige an eine VM durchgereichte HW in meinen Augen auch an das Nest sprich die VM in der VM weitergereicht.

2020-04-05T01:30:37.241+02:00| soundWavePlayback165| I125: VTHREAD 12968 "soundWavePlayback165"
2020-04-05T01:30:37.241+02:00| soundWavePlayback165| I125: SOUNDLIB: SoundWaveThread: Poll thread entered : id(12968)

Ein vernüftige sprich nicht leiernde oder mit Störungen wie Knacken, Rauschen etc durchzogene Soundausgabe ist in einer VM aufgrund der Abhängigkeit zur Host/Gast-Auslastung und damit einhergehenden etwas flexibleren Zeit kaum möglich und eine Soundaufnahme dürfte das sogar fast unmöglich machen.

In den Release-Notes zur WS15 unter https://docs.vmware.com/en/VMware-Workstation-Pro/15/rn/workstation-15-release-notes.html findet sich auch ein Passus hinsichtlich deiner Mausgeschichte:

Known Issues

• Mouse-clicking functionality might stop working in a virtual machine when certain third-party software is installed on the host

When you install certain software, such as WizMouse, on the host, the mouse-clicking functionality might stop working in virtual machines.

Workaround:

1. Power off the virtual machine.
2. Add the following entry to the .vmx file of the virtual machine:
   mks.win32.processWin32MouseInput = "TRUE"
3. Power on the virtual machine.

wow! Danke erst mal für die viele Mühe die Du Dir gemacht hast. Muss ich alles erst mal verdauen...

Dayworker hat geschrieben:Hat die VM eigentlich einen funktionalen Zweck oder ist das nur eine Machbarkeitsstudie?
Du gibst der VM ganze 3 Kerne auf 3 Sockel sprich 9 vCPUs und gönnst der VM auch 5792MB vRAM...

nene, ich arbeite schon mit der VM. Meistens um Programme Testweise zu installieren und auszuprobieren, ohne gleich mein System zu zerschießen. Ist also keine Machbarkeitsstudie.
Die drei Kerne habe ich eigentlich vergeben, weil ich irgendwo mal gelesen hatte, dass zwei Kerne zu wenig sind und das zu Problemen führen könnte. War aber im Zusammenhang mit einer Android-VW. Gut das kann ich dann schon mal auf zwei zurück stellen.
Die 5792 MB Speicher sind mir noch gar nicht aufgefallen. Ursprünglich hatte ich ja 4GB (4092MB) Speicher eingestellt. Keine Ahnung wann und wie das geändert wurde. An dem Rechner sitze nur ich.

...Um dem etwas entgegen zu wirken, bindest du alle vDISK als RAWDISK sprich per physischen Datenträgerzugriff ein....

eigentlich nicht. Ich habe eine normale vituelle Disk erstellt und darauf lauft das BS. Und ich habe ich eine Partition eines physischen Datenträgers als zweites LW eingebunden. Das ist richtig.

...Du hast die VM auch als sogenannte Nested-VM (vhv.enable="true") konfiguriert, damit wird etwaige an eine VM durchgereichte HW in meinen Augen auch an das Nest sprich die VM in der VM weitergereicht.....

das verstehe ich jetzt nicht so ganz. Ich weiß auch nicht, wo ich etwas ein- oder abstellen muss. Könntest Du mir das bitte genauer erklären?

...

2020-04-05T01:30:37.241+02:00| soundWavePlayback165| I125: VTHREAD 12968 "soundWavePlayback165"
2020-04-05T01:30:37.241+02:00| soundWavePlayback165| I125: SOUNDLIB: SoundWaveThread: Poll thread entered : id(12968)

Ein vernüftige sprich nicht leiernde oder mit Störungen wie Knacken, Rauschen etc durchzogene Soundausgabe ist in einer VM aufgrund der Abhängigkeit zur Host/Gast-Auslastung und damit einhergehenden etwas flexibleren Zeit kaum möglich und eine Soundaufnahme dürfte das sogar fast unmöglich machen.

hatte ich noch nichts negatives festgestellt. Sound- und Videoprogramme bzw. -Bearbeitung laufen ohne Probleme in der VM. Kein Knacken, Rauschen oder sonstwas.
Wo kann ich das ändern und was soll ich einstellen? Die Soundkarte ist auf Conection -> use dafault host sound card eingestellt

Mir fällt da gerade ein, dass irgendwann mal die gesamte VM abgeschmiert war und sich nicht mehr zum Neustart überreden ließ. Erst nachdem ich das gesamte System neu gestartet hatte konnte ich auch die VM wieder nutzen. Könnte hier vielleicht irgendwas in den Einstellungen zerschossen worden sein?

Wenn Du willst, kann ich ja noch ein paar Screenshots von den Einstellungen machen und Dir zur Verfügung stellen. Ich denke, dass da auch noch was vermurkst ist.
Beim Prozessor sind nämlich die drei Einstellungen Virtualize Intel VT..., Virtual CPU performance counters und Virtual IOMMU... angehakt. Ich weiß aber nicht so recht was die Schalter bewirken. Auch kann ich nur einen USB Controller einbinden. Es kommt die Fehlermeldung "Maximum limit reached." Aber das kann ja auch normal sein.

Bezüglich des Hinweises auf die Release-Notes kann ich es ja mal probieren. Ich habe allerdings keine zusätzliche Software auf dem Host installiert. Ist ja auch eine stink normale Logitech wireless mouse und die läuft ohne besondere Treiber oder Software.
Nun gut, wenn man's nicht probiert, weiß man auch nicht ob es funktioniert. Ich teste es mal.

Vielen Dank noch mal für die Hilfe.

Uiii das wird wieder ein langer Post werden

In der VMware-Welt gilt unverändert die Devise: "Nur soviel (vRAM, vDISK, vCPU) wie nötig und nicht wie möglich".
Beherzigt man das nicht, läuft die VM langsamer, weil die VMware-VM dann deutlich weniger Rechenzeit erhält. Daher sind viele CPU-Kerne hinderlich in einer VMware-VM und wer bei der Virtualisierung auf Höchstleistung aus ist, hat eindeutig auf das falsche Pferd gesetzt. Bei Virtualisierung geht es um Konsolidierung sprich der Energieeinsparung durch Abschalten nur im Leerlauf betriebener Server-HW auf weniger verbleibende Systeme mit dann höherer Auslastung.
Der Grund weshalb ich hier so oft VMware betont habe, liegt daran, daß VMware sowohl CPU-Zuweisung als auch Scheduling wesentlich stringenter als Micro$ofts Hyper-V handhabt. Mit einer Single- oder Dualcore-VM stehen bei VMware die Chancen wesentlich besser, freie CPU-Kerne zu finden und damit auch Rechenzeit zugewiesen zu bekommen. Notfalls muß man bei gleicher Arbeitsaufgabe wirklich mal mit der Stoppuhr die Zeiten nehmen und vergleichen, ob sich eine Quadcore-VM oder grösser rentieren würde. In jedem Fall würde ich bei deiner "kleinen" Host-CPU nicht über 6 Kerne sprich 6 vCPUs *1 hinausgehen, weil HT allerhöchstens 40% Leistung eines pKerns liefert und das Host-OS auch noch Leistung benötigt. Steht dem Host-OS nicht genügend CPU-Zeit zur Verfügung, nimmt es sich diese als Herr*in im Hause sowieso und durch eine hohe Gast-Last dauert die Abarbeitung der Host-Last entsprechend länger. Das setzt eine Spirale in Gang, bei der sich am Ende Host und Gast bzw Gäste im Wege sind.

*1Eine Dualcore-VM läßt sich auf zwei Arten erreichen, entweder Singlecore mit 2 Sockets oder Dualcore auf einem Socket. Einzigster Unterschied dabei ist die Rücksichtnahme auf die Lizenzierung der in der VM laufenden SW. Wenn diese pro Sockel lizensiert werden muß, kann man mit einer Singlesocket-VM einiges Geld sparen. Funktionstechnisch ist das jedoch in einer VM vollkommen egal, weil der Hypervisor beliebige freie Kerne auch auf Mehrsockelsystemen (inzwischen unter Beachtung von NUMA-Gesichtspunkten) dieser VM zugewiesen werden und durch den Hypervisor weiß bekommt das Gast-OS auch nicht mit, auf welchem Kern des Hosts die VM wirklich ausgeführt wird. Der Gast kann die Auslastung eines Kerns bzw der CPU überhaupt nicht einschätzen. Das ist gleichzeitig auch er Grund, weshalb sich aktive Energiesparfunktionen in einem Gast so negativ auf die Host-Gesamtleistung auswirken, wenn dort mehr als "Bildschirm abschalten nach Zeit X" aktiviert wurde und selbst letzteres sorgt bei einigen VMs für Verbindungsprobleme.


Ähnlich verhält es sich auch mit dem vRAM bei VMwares Desktopprodukten. Bei diesen läßt sich trotz entsprechender Einstellmöglichkeiten seit geraumer Zeit eine Auslagerung des vRAMs in den Virtuellen Arbeitsspeicher des Host-OS sprich Auslagerungsdatei (Windows, Linux) bzw -partition (Linux) nicht mehr wirksam verhindern. Das bedeutet das ab einer je nach WS-versionsabhängigen vRAM-Grösse nur noch eine kleinere Menge des vRAMs einer VM im pRAM des Hosts gehalten und der grössere Rest als auslagerungsfähig gekennzeichnet wird. Damit liegt dann ein Großteil des vRAMs einer VM auf dem Host-Datenträger, der dann hoffentlich eine schnelle SSD ist oder die VM(s) reagieren wie Kaugummi.
Gibt man einer VM beispielsweise 4GB vRAM, dürften nur 1-2GB wirklich im pRAM des Hosts verbleiben und der Rest liegt im Virtuellen Arbeitspeicher des Host. Gründe dafür dürften für VMware gewesen sein, daß sie Supportanfragen minimieren wollten. Die wenigsten Benutzer haben verstanden, weshalb eine VM mit 4GB vRAM sich nicht auf einem Host mit 2GB vRAM starten läßt, während Windows/Linux damit bei anderer SW keine Probleme haben oder warum sich auf Rechner XYZ immer nur 1 VM starten läßt. VMware hat das nachgebogen, damit Benutzer schneller an eine oder mehr laufende VMs kommen, aber schnell ist natürlich anders. Die einzigste verbliebene Einstellmöglichkeit besteht darin, die Doppelspeicherung des vRAMs auf dem Host-Datenträger abzuschalten und dadurch den Host-Datenträger zu entlasten. Beim Start einer VM legen alle Desktop-Produkte zusätzlich eine VMEM-Datei in der Grösse des vRAMs an (in deinem Fall vom 5792MB Grösse), prüfen diese auf Konsistenz und booten erst dann die VM. Das kann dann je nach Geschwindigkeit bzw Schreibleistung des Host-Datenträger so aussehen, als ob die VM wegen dem schwarzen Bildschirm nicht startet würde. Mit kleinerem vRAM würde die Datei dagegen fast verzögerungsfrei angelegt werden und das vBIOS gefolgt vom Bootscreen des Gastes würde direkt sichtbar sein. Nur die Erstellung der vmem-Datei läßt sich noch durch einen entsprechenden Eintrag in die VMX-Datei verhindern, was aber Nebenwirkungen hat, wenn man eine VM suspenden/pausieren will. In diesem Fall würde der Inhalt des vRAMs erst auf den Host-Datenträger geschrieben werden müssen, bei der die Workstation je nach Host kurz oder auch längere Zeit nicht reagiert, bevor die VM wirklich abgeschaltet hat.

Hallo,

danke Dayworker, auch wenn ich nicht alles verstanden habe

Ich habe die cores jetzt auf zwei gestellt und den Speicher auf 4GB wie es ursprünglich mal war. Dazu noch den Eintrag in der .vmx gemacht, Was am Ende geholfen hat weiß ich nich, aber es scheint erst mal zu funktionieren.

Trotzden hast Du mir ein paar Fragen leider noch nicht beantwortet.
- die Frage nach der Einstellung mit der Soundgeschichte
- das mit dem Durchreichen der VM (irgendwas mit "Nest")
- warum ich nur einen USB-Kontroller einbinden kann (Maximum limit reached)

Trotz alledem; großes Lob und Daumen hoch für Deine Hilfe!!

Gruß Rollo

Rollo121 hat geschrieben:- das mit dem Durchreichen der VM (irgendwas mit "Nest")

Du hast die VM so konfiguriert das du innerhalb der VM weiter virtualisieren koenntest. Wenn man das nicht will dann ist es kontraproduktiv es zu aktivieren.

Gruss
Joerg

irix hat geschrieben:
Du hast die VM so konfiguriert das du innerhalb der VM weiter virtualisieren koenntest. Wenn man das nicht will dann ist es kontraproduktiv es zu aktivieren.

nicht dass ich wüsste. Wo/wie macht man das?

VMs eignen sich aus den von mir bereits beschriebenen Gründen nicht wirklich für die Audioausgabe. Wenn das bei dir paßt, sei froh. Die Leistung der heutigen CPUs hat die Lage zwar etwas entspannt, trotzdem wird alles in der VM in SW abgebildet.

Ich kenne jetzt nicht die genauen Möglichkeiten deiner WS-Version. VMware bastelt da manchmal etwas rum und hat auch viel erweitert. Jede VMX-Datei ist jedoch eine reine ASCII-Datei und darf nach dem Bearbeiten keinerlei Formatierungen enthalten. Ein Texteditor wie Notepad++ etc reicht aus, um notfalls alle Einträge von Hand zu bearbeiten. Von daher bei vollständig beendeter VM den Eintrag vhv.enable = "FALSE" setzen. Ein Suspend bzw Pausieren reicht nicht aus, weil die VMX-Datei immer Teil des Suspend ist und beim Restore ggf überschrieben wird, falls VMware deswegen nicht schon vorher einen Fehler meldet.

VMware unterstützt nur einen USB-Controller mit 2 Anschlüssen. Wenn du mehr brauchst, kann du zumindest bei den Desktopprodukten auch einen USB-Hub in eine VM reichen. Falls die VM flexibel auf mehreren Hosts ausgeführt werden soll, würde ich einen USB-Device-Server empfehlen. Letzteres hilft einen auch weiter, wenn auf einem potentiellen Host aus Sicherheitsgründen die USB-Anschlüsse gesperrt sind.

Danke nochmal für die Hilfe.
Hab die Anzahl der Nunbers of processors auf 2 und die cores auf 1 gesetzt. Und den Speicher wieder auf 4GB eingestellt. Jetzt scheint es wieder sauber zu laufen. Gibt jedenfalls seit ein paar Tagen keine Probleme mehr.