[How-to] Schnell effizient falten mit einer VM

Sag mal hast du ne Idee warum immer, wenn ich den Ordner (mit der vmx) irgendwohin verschiebe und von dort starte eth0 auf eth1 umgestellt wird?

Du verschiebst sicher auf einem Rechner ? Mach mal 'ne Sicherungskopie der Linux64_FAH.vmx und vergleiche sie nach dem Verschieben und Start der VM mit der im neuen Verzeichnis (z.B. mit WinMerge, WinMerge). Falls es Unterschiede gibt, poste sie mal.
Ich weiß eigentlich nur, dass die MAC-Adresse geändert wird, wenn man die VM auf einen anderen Rechner kopiert / verschiebt.
Übrigens habe ich den Netzwerk-Adapter meiner VM auf bridged umgestellt, damit ich bei Bedarf transparent mit PuTTY (ssh) auf die VM komme. Da Sollte aber eigentlich kein Zusammenhang mit dem von Dir geschilderten Effekt existieren.
 
Ich benutze deshalb NAT, weil bridged irgendwie nicht funktioniert. Da zeigt er zwar ne IP (169.irgendwas..) aber verbinden kann man sich nicht mit der.

Nach dem Verschieben sind sie gleich. Wenn man dann die Kopie öffnet und wieder schließt.
Der Unterschied ist tatsächlich bei den Netzwerkadressen

Original:
ethernet0.generatedAddress = "00:0c:29:ca:ed:79"
uuid.location = "56 4d 55 01 8e 7a 33 8a-d3 48 de 8e 5b ca ed 79"
uuid.bios = "56 4d 55 01 8e 7a 33 8a-d3 48 de 8e 5b ca ed 79"

Kopie:
ethernet0.generatedAddress = "00:0c:29:df:2b:b1"
uuid.location = "56 4d 75 ab f8 15 fa 07-b1 e4 2d 0e 54 df 2b b1"
uuid.bios = "56 4d 75 ab f8 15 fa 07-b1 e4 2d 0e 54 df 2b b1"

Irgendwelche Tipps wie man das vermeiden kann?
 
Ich benutze deshalb NAT, weil bridged irgendwie nicht funktioniert. Da zeigt er zwar ne IP (169.irgendwas..) aber verbinden kann man sich nicht mit der.

Nach dem Verschieben sind sie gleich. Wenn man dann die Kopie öffnet und wieder schließt.
Der Unterschied ist tatsächlich bei den Netzwerkadressen

Original:


Kopie:


Irgendwelche Tipps wie man das vermeiden kann?

Füge vor dem Start der VM mal folgende Zeile ein in die Linux64_FAH.vmx:

uuid.action = "keep"
 
Hier, hoffe es hilft.

#!/usr/bin/vmplayer
.encoding = "windows-1252"

# Filename: Linux64_FAH.vmx
# Generated 2009-10-29;06:06:21 by EasyVMX! 2.0 (beta)
# EasyVMX!: Virtual Machine Creator

# This is a Workstation 6 config file
# It can be used with Player
config.version = "8"
virtualHW.version = "6"

# Selected operating system for your virtual machine
guestOS = "other26xlinux-64"

# displayName is your own name for the virtual machine
displayName = "Linux64_FAH_amd-main"

# These fields are free text description fields
annotation = "Linux64 FAH"
guestinfo.vmware.product.long = "Linux64 FAH"
guestinfo.vmware.product.url = "http://www.easyvmx.com/"
guestinfo.vmware.product.class = "virtual machine"

# Number of virtual CPUs. Your virtual machine will not
# work if this number is higher than the number of your physical CPUs
numvcpus = "4"

# Memory size and other memory settings
memsize = "1536"
MemAllowAutoScaleDown = "FALSE"
MemTrimRate = "-1"

# PowerOn/Off options
gui.powerOnAtStartup = "FALSE"
gui.fullScreenAtPowerOn = "FALSE"
gui.exitAtPowerOff = "FALSE"

# Unique ID for the virtual machine will be created
uuid.action = "create"

# Settings for VMware Tools
tools.remindInstall = "FALSE"

# Startup hints interfers with automatic startup of a virtual machine
# This setting has no effect in VMware Player
hints.hideAll = "TRUE"

# Enable time synchronization between computer
# and virtual machine
tools.syncTime = "TRUE"

# First serial port, physical COM1 is not available

# Optional second serial port, physical COM2 is not available

# First parallell port, physical LPT1 is not available

# Logging
# This config activates logging, and keeps last log
logging = "TRUE"
log.fileName = "Linux64_FAH.log"
log.append = "TRUE"
log.keepOld = "3"

# These settings decides interaction between your
# computer and the virtual machine
isolation.tools.hgfs.disable = "FALSE"
isolation.tools.dnd.disable = "FALSE"
isolation.tools.copy.enable = "TRUE"
isolation.tools.paste.enabled = "TRUE"

# Other default settings
svga.autodetect = "TRUE"
mks.keyboardFilter = "allow"
snapshot.action = "autoCommit"

# First network interface card
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.generatedAddressOffset = "0"

# Settings for physical floppy drive

# Settings for physical CDROM drive
ide1:0.present = "TRUE"
ide1:0.deviceType = "cdrom-raw"
ide1:0.startConnected = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.autodetect = "TRUE"

# First IDE disk, size 4Gb
ide0:0.present = "TRUE"
ide0:0.fileName = "Linux64_FAH.vmdk"
ide0:0.mode = "persistent"
ide0:0.startConnected = "TRUE"
ide0:0.writeThrough = "TRUE"

# Hardware clock to UTC
rtc.diffFromUTC = 0

extendedConfigFile = "Linux64_FAH.vmxf"
virtualHW.productCompatibility = "hosted"

uuid.action = "keep"

checkpoint.vmState = ""
ethernet0.generatedAddress = "00:0c:29:ca:ed:79"
uuid.location = "56 4d 55 01 8e 7a 33 8a-d3 48 de 8e 5b ca ed 79"
uuid.bios = "56 4d 55 01 8e 7a 33 8a-d3 48 de 8e 5b ca ed 79"
cleanShutdown = "TRUE"
replay.supported = "FALSE"
replay.filename = ""
ide0:0.redo = ""
ethernet0.pciSlotNumber = "16"
vmotion.checkpointFBSize = "16777216"
serial0.present = "FALSE"
serial1.present = "FALSE"
parallel0.present = "FALSE"
floppy0.present = "FALSE"
 
Jo, hat's. Da ist schon / noch ein Eintrag drin:

# Unique ID for the virtual machine will be created
uuid.action = "create"
.
.
.
virtualHW.productCompatibility = "hosted"

uuid.action = "keep"

checkpoint.vmState = ""
.
.
.
Die Zeile mit dem rot markierten Eintrag löschen und am besten die andere Zeile der Übersichtlichkeit halber nach oben verschieben.
 
Danke so funkionierts, werde ich ändern und neu-hochladen.

Edit: done. @NFS-game, den link zu deinem server hab ich rausgenommen da ich die Dateien dort icht aktualisieren konnte

Edit: die Dateien sind auch wieder auf NFSgames Server.
Außerdem habe ich die Empfehlung hinzugefügt den Langouste De-coupler zu aktivieren.
 
Zuletzt bearbeitet:
Tolles How-to!

Ich falte erst knapp einen Monat und taste mich langsam an die Materie ran. Alleine hätte ich es nichtmal versucht unter Linux :huh: zu falten. Aber mit diesem How-to ist es wirklich kinderleicht! Ich habs installiert und nun rennen die vier Kerne meines Prozis wie bekloppt. 5100 PPD mit einem i7 auf Standardtakt.

Vielen Dank für dieses How-to! :hail:
 
5100 PPD mit einem i7 auf Standardtakt.
Der i7 hat ja Hyperthreading. Weil F@H nur so viele Threads verwendet, wie Kerne physisch vorhanden sind, lastet ein SMP-Client den i7 nur zu ~50% aus, weshalb man da gerne 2 SMP-Clients verwendet.

Beherrscht VMware Hyperthreading? Wenn ja, kann man einfach 8 Kerne einstellen, ansonsten 2 VMs. Damit könntest du deine Faltleistung erheblich steigern.
 
Ja man muss in den VMware Einstellungen 8 (oder 7 wenn man einen freilassen will) Kerne einstellen. In der Webkonfiguration des Clients muss dann dieselbe Anzahl einstellen.
Es kann sein dass der Client dann mehr Ram verbraucht.
 
Zuletzt bearbeitet:
oder 7 wenn man einen freilassen will
Ich lasse keinen Kern frei. Sinnvoller ist es, wenn man der VM im Taskmanager eine niedrige Priorität zuweist, so bekommen die Windows-Programme genug Leistung und trotzdem kann man eine maximale Faltleistung erhalten.

Es kann sein dass der Client dann mehr Ram verbraucht.
Eine VM mit 8 Kernen dürfte immer noch weniger RAM verbrauchen, als 2 VMs.
 
@Argead
Ich habe HT eingeschaltet und auch in der Config auf 8 Kerne geändert. Aber die VM kann nur vier Kerne verwalten. Zumindest in dieser Version.

Aber auf vier Kerne läuft es wunderbar mit einer Auslastung von 100%. Zusätzlich lasse ich noch eine GTX260 falten. Dabei kann man immer noch ohne Probleme durchs Netz surfen. Volle Auslastung auf 8 Kerne möchte ich meinem Prozi auch nicht antun, weil ich nur den Boxed-Lüfter drauf hab. :fresse:
 
Ich habe HT eingeschaltet und auch in der Config auf 8 Kerne geändert. Aber die VM kann nur vier Kerne verwalten. Zumindest in dieser Version.

In welcher Config hast Du die 8 Kerne eingetragen, vom Folding-Client ?

Welche VMware Software hast Du ? Der Player 3.0 sollte alle Kerne unterstützen, hier ein Auszug aus dem Handbuch:

Using Virtual Symmetric Multiprocessing
Virtual Symmetric Multiprocessing (SMP), you can assign up to four or more virtual processors to a virtual machine on any host machine that has four logical processors.
The following are all considered to have four or more logical processors:

  • A multiprocessor host with four or more physical CPUs
  • A single-processor host with a multicore CPU
  • A single-processor host with hyperthreading enabled
NOTE On hyperthreaded uniprocessor hosts, performance of virtual machines with virtual SMP might be
below normal.
With VMware Player you can power on and run multiple four-processor virtual machines concurrently.
Wenn Du es doch mal testen willst und die Konfiguration im grafischen Frontend des Players nicht auf 8 Kerne anpassen kannst, trage es mal vor dem Start der VM manuell in der vmx-Datei ein:
Ungerade Zahlen gehen scheinbar nur so (habe ich mit meinem Q9550 und drei Kernen probiert).
 
Der Player 3.0 sollte alle Kerne unterstützen
In den VM-Settings kann man nur vier Kerne auswählen. Die vmx-Datei habe ich noch nicht bearbeitet. Aber mir reichen im Moment auch vier Kerne. Bei ausgelasteten 8 Kernen gehen die Kerntemperaturen über 70°C. Boxed-Lüfter *hust*

Nun gibt es aber ein neues Problem. Die erste WU wurde durchgekaut aber der Client kann die fertige WU nicht hochladen:
.
.
.
[08:18:43] Loaded queue successfully.
[08:18:43]
[08:18:43] + Processing work unit
[08:18:43] Core required: FahCore_a2.exe
[08:18:43] Project: 2677 (Run 5, Clone 27, Gen 69)
[08:18:43] Core found.


[08:18:43] + Attempting to send results [January 15 08:18:43 UTC]
[08:18:43] Working on queue slot 05 [January 15 08:18:43 UTC]
[08:18:43] + Working ...
[08:18:43] - Couldn't send HTTP request to server
[08:18:43] + Could not connect to Work Server (results)
[08:18:43] (171.64.65.56:8080)
[08:18:43] + Retrying using alternative port
[08:18:43] - Couldn't send HTTP request to server
[08:18:43] + Could not connect to Work Server (results)
[08:18:43] (171.64.65.56:80)
[08:18:43] - Error: Could not transmit unit 01 (completed January 14) to work server.


[08:18:43] + Attempting to send results [January 15 08:18:43 UTC]
[08:18:43] - Couldn't send HTTP request to server
[08:18:43] + Could not connect to Work Server (results)
[08:18:43] (171.67.108.25:8080)
[08:18:43] + Retrying using alternative port
[08:18:43] - Couldn't send HTTP request to server
[08:18:43] + Could not connect to Work Server (results)
[08:18:43] (171.67.108.25:80)
[08:18:43] Could not transmit unit 01 to Collection server; keeping in queue.
.
.
.
Jetzt knabbert der Client an einer neuen WU.
Gestern hat der Client schon einige Male versucht die fertige WU hochzuladen, aber ohne Erfolg. Sind da die Server überlastet oder gibt es vielleicht einen anderen Grund dafür? Ich meine, es kann ja nicht an mir liegen! :P
 
Wenn du "enable Langouste De-coupler" ausgewählt hast (bei der Konfiguration) blockiert die Einstellung den Upload, damit der Client sich sofort eine neue Wu holt und lädt die Ergebnisse selber hoch.

Du kannst an der Netzwerkauslastung beobachten, oder auch einfach an der Punktegutschrift nachher sehen das es hochgeladen wurde.
 
Wenn du "enable Langouste De-coupler" ausgewählt hast...
Habe ich eingeschaltet.

Du kannst an der Netzwerkauslastung beobachten, oder auch einfach an der Punktegutschrift nachher sehen das es hochgeladen wurde.
Juchu! :D Die Punkte wurden gutgeschrieben. Ich war einfach zu ungeduldig, aber ich habe auch nicht mitbekommen, dass etwas hochgeladen worden ist.

Dank an Argead! :hail:
 
Wenn du "enable Langouste De-coupler" ausgewählt hast (bei der Konfiguration) blockiert die Einstellung den Upload, damit der Client sich sofort eine neue Wu holt und lädt die Ergebnisse selber hoch.

Du kannst an der Netzwerkauslastung beobachten, oder auch einfach an der Punktegutschrift nachher sehen das es hochgeladen wurde.

Unter /tmp/langouste werden die Upload-Protokolle als langouste-helper-<pid>.log gespeichert, z.B.:

.
.
.
Launch directory: /tmp/langouste/1919/clientdir
Executable: ./fah6
Arguments: -send 04

[11:24:15] - Ask before connecting: No
[11:24:15] - Proxy: localhost:8080
[11:24:15] - User name: mattifolder (Team 70335)
[11:24:15] - User ID: 78264DB97C84A1C1
[11:24:15] - Machine ID: 7
[11:24:15]
[11:24:15] Loaded queue successfully.
[11:24:15] Attempting to return result(s) to server...
[11:24:15] Project: 2671 (Run 21, Clone 19, Gen 189)
[11:24:15] - Read packet limit of 540015616... Set to 524286976.


[11:24:15] + Attempting to send results [January 15 11:24:15 UTC]
[11:35:10] + Results successfully sent
[11:35:10] Thank you for your contribution to Folding@Home.
[11:35:10] + Number of Units Completed: 33


Folding@Home Client Shutdown.
ls: cannot access work/wuresults_04.dat: No such file or directory
unit 04 sent!
all done
Mometan migriere ich das Protokoll noch manuell in die FAHlog.txt und die lokale Anzahl der Projekte in die client.cfg:

Mal sehen, ich habe noch einen feature-request beim langouste-Entwickler im Folding-Forum laufen, dass es gleich mitgemacht wird (Folding Forum • View topic - Langouste -- WU upload/download de-coupler [Linux only]). Vielleicht probiere ich auch mal selbst eine Anpassung, sollte das Script langouste-helper.sh im fah-Verzeichnis sein.

Habe gerade "mal gesehen";), die Anpassung im langouste ist wahrscheinlich kritisch, da das fah-executable die client.cfg und FAHlog.txt die ganze Zeit geöffnet halten. Werde wohl mal versuchen, für das /etc/rc.d/init.d/rc.local_shutdown ein kleines plugin-script schreiben, das diese Migration vornimmt. Damit sind die Werte zwar nicht gleich online verfügbar, stehen aber beim nächsten Start korrekt in der Client.cfg bzw. FAHlog.txt / FAHlog-Prev.txt.
 
Zurück