Böse Falle - VC löscht die falschen vmdk's

[GTMK]

Schönen (oder auch nicht so schönen) guten Abend,

vielleicht handelt es sich hier um einen ziemlich üblen Bug im Virtual Center...

Ich bin momentan mit Performancetests auf meiner frischen DS3400 beschäftigt und habe daher einer VM über das VC wiederholt Platten (auf einem VMFS, als RDM in physical oder virtual mode) zugewiesen und wieder weggenommen (aber bis gerade eben bei diesem Vorgang nicht von der Platte gelöscht). Ich habe dann festgestellt, dass sich gut 20 solcher RDM-Mapping-Files im Verzeichnis der VM angehäuft hatten, die ich dann mit einem beherzten "rm -f *rdm*" weggefegt habe. Anschließend zwei neue Mappings eingerichtet, Tests durchgeführt, VM heruntergefahren, die RDMs entfernt und diesmal "Delete from disk..." ausgewählt.

Effekt: Eines der RDM-Mapping-Files ist noch da, aber dafür sind zwei vmdk-Dateien mit dem Betriebssystem und anderen Dateien verschwunden, die laut VC noch vorhanden sein sollten. Maschine futsch.

Backup ist natürlich - da Testmaschine - keines vorhanden....

Das VC hat die (fragwürdige?) Eigenschaft, gelöschte Platten nicht aus dem .vmx zu entfernen, sondern nur ein "scsix.y.present = false" einzufügen. Vielleicht hat es hier einen Overflow o.ä. gegeben, VMware Support werde ich morgen kontaktieren, auch wenn das Kind schon im Brunnen liegt.

Spaßeshalber poste ich mal die .vmx...

Grüße, Georg.

Code: Alles auswählen

#!/usr/bin/vmware
config.version = "8"
virtualHW.version = "4"
floppy0.present = "true"
nvram = "M-SRV2.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"
powerType.powerOff = "default"
powerType.powerOn = "default"
powerType.suspend = "default"
powerType.reset = "default"

displayName = "M-SRV2"
extendedConfigFile = "M-SRV2.vmxf"

scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "3072"
scsi0:0.present = "true"
scsi0:0.fileName = "M-SRV2.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
sched.scsi0:0.shares = "normal"
ide1:0.present = "true"
ide1:0.clientDevice = "true"
ide1:0.fileName = "/usr/lib/vmware/isoimages/windows.iso"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.startConnected = "false"
floppy0.startConnected = "false"
floppy0.fileName = "/dev/fd0"
ethernet0.present = "true"
ethernet0.virtualDev = "vmxnet"
ethernet0.wakeOnPcktRcv = "false"
ethernet0.networkName = "GKnet"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:94:31:03"
guestOS = "winnetstandard"
uuid.bios = "50 14 c8 43 14 b0 73 db-0c e0 ae f2 09 5f 18 9b"
log.fileName = "vmware.log"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.minsize = "3072"
sched.mem.shares = "normal"

draw = "gdi"
evcCompatibilityMode = "FALSE"
guestCPUID.0 = "00000002756e65476c65746e49656e69"
guestCPUID.1 = "00000f280001080b000000000febbbff"
guestCPUID.80000001 = "00000000000000000000000000000000"
hostCPUID.0 = "00000002756e65476c65746e49656e69"
hostCPUID.1 = "00000f290002080b00004400bfebfbff"
hostCPUID.80000001 = "00000000000000000000000000000000"
isolation.tools.dnd.disable = "true"
priority.grabbed = "normal"
priority.ungrabbed = "normal"
scsi0:0.redo = ""
userCPUID.0 = "00000002756e65476c65746e49656e69"
userCPUID.1 = "00000f290002080b00004400bfebfbff"
userCPUID.80000001 = "00000000000000000000000000000000"
vmware.tools.requiredversion = "7302"

tools.syncTime = "false"
uuid.location = "56 4d df 42 4c 37 85 db-28 e1 8c d0 4d a1 f6 9f"
sched.mem.max = "unlimited"
sched.swap.derivedName = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SR
V2/M-SRV2-e42a39e5.vswp"
scsi0:1.present = "true"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:1.filename = "M-SRV2_1.vmdk"
scsi0:1.mode = "persistent"
scsi0:1.redo = ""

annotation = " "

scsi0:2.present = "false"
scsi0:2.fileName = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-S
RV2.vmdk"
scsi0:2.mode = "independent-persistent"
scsi0:2.deviceType = "scsi-hardDisk"
scsi0:3.present = "false"
scsi0:3.fileName = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-S
RV2_1.vmdk"
scsi0:3.mode = "independent-persistent"
scsi0:3.deviceType = "scsi-hardDisk"
scsi0:4.present = "false"
scsi0:4.fileName = "M-SRV2_24.vmdk"
scsi0:4.mode = "persistent"
scsi0:4.deviceType = "scsi-hardDisk"
scsi0:5.present = "false"
scsi0:5.fileName = "M-SRV2_25.vmdk"
scsi0:5.mode = "persistent"
scsi0:5.deviceType = "scsi-hardDisk"

scsi0:2.redo = ""
scsi0:3.redo = ""
scsi0:4.redo = ""
scsi0:5.redo = ""
scsi0:6.present = "false"
scsi0:6.deviceType = "scsi-hardDisk"
scsi0:6.filename = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-S
RV2_6.vmdk"
scsi0:6.mode = "independent-persistent"
scsi0:6.redo = ""
scsi0:8.present = "false"
scsi0:8.deviceType = "scsi-hardDisk"
scsi0:8.filename = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-S
RV2_7.vmdk"
scsi0:8.mode = "independent-persistent"
scsi0:8.redo = ""
scsi0:9.present = "false"
scsi0:9.deviceType = "scsi-hardDisk"
scsi0:9.filename = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-S
RV2_8.vmdk"
scsi0:9.mode = "independent-persistent"
scsi0:9.redo = ""
scsi0:10.present = "false"
scsi0:10.deviceType = "scsi-hardDisk"
scsi0:10.filename = "/vmfs/volumes/4526cbca-8fc241e3-80e8-000e0cbcc6f4/M-SRV2/M-
SRV2_9.vmdk"
scsi0:10.mode = "independent-persistent"
scsi0:10.redo = ""

sched.cpu.affinity = "all"


[GTMK]

Asche auf mein Haupt: Den Bock habe ich geschossen (aber mich noch nicht bei VMware Support blamiert).

Es werden ja beim RDM nicht nur die *rdm.vmdk bzw. *rdmp.vmdk-Dateien angelegt, sondern auch die ganz normalen (ein paar hundert Byte großen) .vmdk-Dateien mit den Metadaten. Die habe ich (bei laufender VM) ebenfalls per rm -f *.vmdk entsorgt - im Vertrauen darauf, dass die vmdks, die ich benötige, ja gesperrt sind. Es kam auch das erwartete

Code: Alles auswählen

rm: cannot remove `M-SRV2_1-flat.vmdk': Device or resource busy
rm: cannot remove `M-SRV2-flat.vmdk': Device or resource busy


Blöderweise sind die Metadaten nicht gelockt... und das habe ich übersehen.

Ich kann jetzt nicht mehr nachvollziehen, ob ich in geistiger Umnachtung die Flat-Dateien auch gelöscht habe oder das das VC gemacht hat. Ich habe mich noch nicht ernsthaft damit beschäftigt, die Metadaten per Hand wiederherzustellen - gibt es bei sanbarrow bspw. nicht Anleitungen, wie das geht?

Jedenfalls: Wieder was gelernt, wenn auch schmerzhaft.

Georg.

[irix]

Bis auf die CID und die UUID steht ja in den Meta VMFKs immer das gleich sofern man die Groesseangabe der Disk mal ausen vorlaesst..

Die Frage nur was CID und UUID genau ist und was passiert wenn diese wechselt. Mein erster Versuch waere in einer neuen VM eine Disk mit der gleichen Groesse/Controller anzulegen und dann nur die Extent description anzupassen. Dann mal gucken was passiert.

Waere schoen wenn du berichten kannst ob du es wieder hinbekommen hast bzw. was der Support sagt. Wobei ich erwarten wuerde das es schon nen KB Artikel zu diesem Thema gibt.

Gruss
Joerg

[GTMK]

Hallo Jörg,

ich habe die Sache nicht weiter verfolgt, da die flat-Files ja auch weg waren und ich auch die Dinge nicht mehr hundertprozentig nachvollziehen konnte. Beim nächsten Mal halt nicht ganz so locker flockig vorgehen... und Dinge voraussetzen, von denen ich nicht weiß, ob ich sie voraussetzen darf.

Georg.