Erfahrungen vRanger 5.5

[PeterDA]

Hi,
nachdem ich heute früh das Update von vRanger 5.3 auf 5.4 eingespielt habe, habe ich gerade gesehen, dass es schon die Version 5.5 gibt.

Frage hat diese Version schon jemand im Einsatz und kann etwas dazu sagen?

Gruß Peter

[irix]

Ich hatte ueber das Quest Forum davon erfahren und es wurde berichtet das "nur" eine zusaetliche Sprache hinzu kam. Fehler oder Erweiterungen gabs wohl keine ansonsten mal schauen ob es eine ReleaseNote gibt.

Gruss
Joerg

[PeterDA]

Hi Joerg,
in den Whats new habe ich auch nicht so wirklich tolle Neuerungen entdeckt. Dann bleib ich ertsmal bei der 5.4. Die scheint mir auch etwas flotter zu sein als die 5.3.0

Gruß Peter

[Supi]

Ich kämpfe seit monaten mit einem Bug, vielleicht kann das mal einer in einer Ruhigen Minute testen.
Umgebung Vshpere 4.1
Server 2008 VM. 2 Disk , C und D. C liegt auf Datastore 1 und D auf Datastore 2.
Laut Vcenter haben beide den gleichen Namen "ABCD.VMDK" nur halt auf anderen Datatstores.
Backup option Quiscing, CBT, ABM.
Ich bekomme hier seit Vranger 5.3.1 die Meldung: "Error 2800 - filter file contains the wrong number of blocks"

Erst dachte ich und der Quest Support, es ist nur eine VM. War trotz vieler Logs nicht nachvollziebar (für Quest)
Jedoch habe ich heute 3 andere VM's mit gleicher konfig (2 HDD's, 2 verschieden DataStores für C und D , gleicher VMDK Name) getestet und erhalten immer diesen Fehler.
Er verfolgt mich quasi ?!

[irix]

Hi Stefan,

ich hatte den Fehler auch schon weiss aber nicht wie ich ihn wegbekommen habe bzw. was die Ursache ist.

Auf jeden Fall hab ich viele Konstellationen wo ich vDisks in unterschiedlichen Datastores habe und das darunter sind auch W2k8 und W2k8R2 VMs. Also das ist zumind. kein generelles Problem.

Gruss
Joerg

[Supi]

Hi Joerg,

nur seltsam ist halt wirklich, dass ich den Fehler sofort weg bekomme, sobald ich die VMDK's unterschiedlich heißen.
Haben in deinen gleichen Konstellation die VMDK's auch immer den gleichen Namen?

Blöd ist ja auch, das trotz 4.1 U3 immer noch das Shrinken nicht klappt, da meine DS alle die gleiche Blocksize haben. Zuvor mit Vsphere 4.0 hat diese noch geklappt.

Erst dachte ich halt, es liegt nur an einer VM mit dem Error 2800. .Aber das Problem habe eigentlich alle (Server 2008) .

Was ich getestet habe:
VM mit vm.vmdk auf DS1 und VM.vmdk. (second VM Disk) aud DS2.
ESXI 4.1 U3, Server 2008 VM.
Den Datastore (DS) für beide DISK zu DS3 geändert. Erste Disk bleibt VM.vmdk, die zweite Disk wird zu vm_1.vmdk.
> Backup läuft problemlos.
SV Moved nur die Disk1 von DS3 zu DS1. Disk1 heißt noch vm.vmdk and Disk 2 bleibt vm_1.vmdk auf DS3.
> Backup läuft problemlos.
SV-Moved Disk2 (vm_1.vmdk) zu DS2. > vm_1.vmdk wird dadurch zu vm.vmdk. (wird quasi ja neu angelegt, es gibt noch keine vm.vmdk auf dem DataStore)
Ergebnis: DS1 "Disk 1" vm.vmdk and DS2 "Disk 2" vm.vmdk.
> Backup klappt nicht , es kommt Error - Filter file contains the wrong number
of blocks.
Nur ich kann doch jetzt nicht vranger genehm alle vdisk's umbenennen?

[irix]

Ich habe nur mit vSphere 5 getestet. Ich schau mal ob ich nen v4 ESXi ausgraben kann. Muss die VM an sein oder schlaegt es fehlt auch wenn die VM aus ist?

Gruss
Joerg

[Supi]

@irix
Das Problem tritt wohl nur auf, wenn die VM an ist.

[Supi]

@Irix: Gerade eben noch mal 2 neue SRV2008 und R2 VM's erstellt und nur die VM Tools verteilt.LW C ist auf LUN1 und LW D ist auf LUN2.
bei beiden bringt der Vranger: Error Message: 2800 - filter file contains the wrong number of blocks

[irix]

Ich ziehe meine Aussage zurueck und behaupte das Gegenteil. Hier sieht eigentlich jede VM anders aus. Da wo ich dachte die vDISK Namen sind gleich ist dem nich so aber trotzdem hab ich VMs wo das so ist.

Code: Alles auswählen

~ # cd /vmfs/volumes/grp01-005-l/zirkon/
/vmfs/volumes/4d7f9cf7-7ca5779c-06f7-b8ac6f985141/zirkon # grep vmdk *.vmx
scsi0:0.fileName = "/vmfs/volumes/4efc4615-d5d36232-7e51-b8ac6f985214/zirkon/zirkon_1_1.vmdk"
scsi0:1.fileName = "/vmfs/volumes/4efc4615-d5d36232-7e51-b8ac6f985214/zirkon/zirkon_2_1.vmdk"
scsi0:3.fileName = "/vmfs/volumes/4f682099-c1b30cac-f501-b8ac6f985141/zirkon/zirkon_5.vmdk"
scsi0:4.fileName = "/vmfs/volumes/49b77358-8fce9cb4-c614-001b211fd98c/zirkon/zirkon.vmdk"
scsi1:0.fileName = "/vmfs/volumes/49b77358-8fce9cb4-c614-001b211fd98c/zirkon/zirkon_1.vmdk"
scsi1:1.fileName = "/vmfs/volumes/49b77358-8fce9cb4-c614-001b211fd98c/zirkon/zirkon_2.vmdk"
scsi1:2.fileName = "/vmfs/volumes/49b77358-8fce9cb4-c614-001b211fd98c/zirkon/zirkon_3.vmdk"
scsi1:3.fileName = "/vmfs/volumes/4f09c4df-37371cba-8d29-b8ac6f985214/zirkon/zirkon_4.vmdk"

und hier mal eine mit gleichen

Code: Alles auswählen

/vmfs/volumes/4f682099-c1b30cac-f501-b8ac6f985141/spinell # grep vmdk *.vmx
scsi0:0.fileName = "/vmfs/volumes/49b50269-b6675d82-36f8-001b211fda7c/spinell/spinell.vmdk"
scsi0:1.fileName = "/vmfs/volumes/503a846c-4c56e7fe-7a05-b8ac6f985214/spinell/spinell_1.vmdk"
scsi0:3.fileName = "/vmfs/volumes/4db94db9-f0f64dc8-4cbd-b8ac6f985214/spinell/spinell.vmdk"
scsi0:4.fileName = "/vmfs/volumes/4db94db9-f0f64dc8-4cbd-b8ac6f985214/spinell/spinell_1.vmdk"
scsi1:0.fileName = "/vmfs/volumes/4bf00979-7d50f7e6-f59e-001b211fd98c/spinell/spinell.vmdk"
scsi1:1.fileName = "/vmfs/volumes/4db94db9-f0f64dc8-4cbd-b8ac6f985214/spinell/spinell_2.vmdk"
scsi1:2.fileName = "/vmfs/volumes/4d7ce314-8838c22f-b357-b8ac6f985141/spinell/spinell.vmdk"
scsi1:3.fileName = "/vmfs/volumes/49b50269-b6675d82-36f8-001b211fda7c/spinell/spinell_1.vmdk"
scsi1:4.fileName = "/vmfs/volumes/4f09c4df-37371cba-8d29-b8ac6f985214/spinell/spinell.vmdk"
scsi2:0.fileName = "/vmfs/volumes/4efc4615-d5d36232-7e51-b8ac6f985214/spinell/spinell.vmdk"
scsi2:1.fileName = "/vmfs/volumes/4f09c4df-37371cba-8d29-b8ac6f985214/spinell/spinell_2.vmdk"
scsi2:2.fileName = "spinell_3.vmdk"

Gruss
Joerg

[Supi]

Anbei wie der ESXi 4.1 die VM anlegt beim "cold" SV-Motion
Die VM wurde zuerst auf einem anderen (lokalen) Datastore mit beiden Platten angelegt, da hatte die zweite Platte den namen srv2008_test_1.vmdk

Und mit dieser oben abgebildeten gleichen Bezeichnung kommt der Vranger nicht klar. (Zumindest seit Version 5.3)

[Dayworker]

Ich ziehe meine Aussage zurueck und behaupte das Gegenteil. Hier sieht eigentlich jede VM anders aus. Da wo ich dachte die vDISK Namen sind gleich ist dem nich so aber trotzdem hab ich VMs wo das so ist.

Sind deine VMDKs eigentlich alle gleicher Grösse?
Falls ja, würde das das Problem erklären können. Der vRanger scheint intern nicht die Möglichkeit in Betracht zu ziehen, daß derselbe VMDK-Name auf verschiedenen DS und trotzdem unterschiedlicher Grösse vorkommen kann.
Wenn dem so sein sollte, müßte der Bugfix eigentlich ganz einfach sein. Der vRanger müßte dazu nur die Angaben zur "CID" und "parentCID" in der Beschreibungs-VMDK beachten, denn daran erkennt VMware normalerweise ob ein Snapshot sauber durchgeführt wurde.

[Supi]

nein, sie haben nicht die gleiche Größe. Das war auch einer der ersten "tests" des Quest Supports. Meine 2 Test VM haben je 20GB "C" und 10 bzw 5GB "D".

[irix]

Ich ziehe meine Aussage zurueck und behaupte das Gegenteil. Hier sieht eigentlich jede VM anders aus. Da wo ich dachte die vDISK Namen sind gleich ist dem nich so aber trotzdem hab ich VMs wo das so ist.

Sind deine VMDKs eigentlich alle gleicher Grösse?

Nein, wir vermeiden vDISKs mit der gleichen Groesse damit eine identifizierung fuer uns im Fall der Faelle moeglich ist.

Gruss
Joerg

[Supi]

nein, sie haben nicht die gleiche Größe. Das war auch einer der ersten "tests" des Quest Supports. Meine 2 Test VM haben je 20GB "C" und 10 bzw 5GB "D".

[Dayworker]

Nein, wir vermeiden vDISKs mit der gleichen Groesse damit eine identifizierung fuer uns im Fall der Faelle moeglich ist.

Okay, dann scheint Quest dort den DS nicht oder nur halbherzig zu integrieren und intern bei gleichem VMDK-Namen stillschweigend von gleicher VMDK-Grösse auszugehen.

Blöd ist ja auch, das trotz 4.1 U3 immer noch das Shrinken nicht klappt, da meine DS alle die gleiche Blocksize haben. Zuvor mit Vsphere 4.0 hat diese noch geklappt.

Eventuell liegt das Problem aber auch an VMware selbst und vRanger ist aufgrund dessen über die API zum scheitern verdammt.

[Supi]

@Daywalker:
mit dem Shrinken meine ich das hier: http://vmguy.com/wordpress/index.php/archives/1639

[Supi]

Neuer Tag, neuer Test.

Server 2003 R2 VM 2 Disk auf 2 DataStores (gleicher VMDK Name), Backup funktioniert.
Wird also immer konfuser.

[Dayworker]

Klingt für mich irgendwie nach einem Problem mit W2k8 bzw W2k8-R2...
Kannst du das mal für Win7-64 mit/ohne SP nachstellen? Rein theoretisch solltest du aufgrund dessen Binärkompatibilität zu W2k8/W2k8-R2 dort dasselbe Problem haben.
Das von mir daher zu erwartende Ergebnis könnte man dann dem Quest-Support mal vor die Füß kippen.

[Supi]

@Daywalker : Ich teste doch gerne....
Win7 Pro klappt ohne Probleme.
Ich vermute ja, es hat was mit der Einstellung : disk.EnableUUID "true" zu tun.
Mit vranger 5.2.1 klappte es ja, da musste diese Einstellung nochauf "false" gesetzt werden.
Seit Vranger 5.3 soll dies "true" sein, womit der Ranger wohl ein Problem hat.

Windows 2008 application-consistent quiescing
http://kb.vmware.com/selfservice/micros ... Id=1028881

[Supi]

Also, quest vermeldet, sie konnten es nachstellen.

.... nachdem sie das jetzt auch mal mit Vcenter 4 getestet haben und nicht mit einem Vcenter5 ?!
Schön, dass mann das nach Monaten dann doch mal (richtig) probiert...

[Dayworker]

Na immerhin haben sie es jetzt endlich probiert, wahrscheinlich nachdem die kritische Menge an Mecker aufgelaufen war.
Irgendwo lustig wäre es aber, wenn das Problem mit vSphere5 oder 5.1 nicht mehr auftritt. Wie man bei letzterem und auch bei der WS9 im Desktopbereich bisher gesehen hat, macht das umgehende Upgrade auf eine neue Version nicht immer Sinn und erweist sich in vielfacher Hinsicht als echter Bumerang.

[irix]

Bei vSphere 5 tritt es nicht auf und der Kram ist dann auch schon ueber ein Jahr alt. Aber so ist das halt mit den Benutzern und den Upgrades

Gruss
Joerg

[ribaadmin]

Kann mir jemand sagen ob ich beim 5.5 ein pre und post Backup Script einstelle?
Oder gibt es diese Funktion nicht?

[irix]

Wenn du INNERHALB der VM was ausfuehren willst dann geht das, aber es hat mit vRanger weniger etwas zutun sondern das sind die CustomQuiescing Scripts welche automatisch gesucht und ausgefuehrt wuerden. Allerdings auch wenn man dann mal einen Quiesced Snap ueber den vSphere Client erstellt.


Ich habe frueher ueber ein PowerShell Script aktionen ausgefuehrt und dann den vRanger Job gestartet. Ist der Job dann mal angelaufen bzw. die VM hat nen Snap gehabt dann hab ich wieder eine Aktion ausgefuehrt. Auf diesem Wege hatte ich mal eine Konsistente Sicherung einer VM mit einem NetWare Server gemacht.

Gruss
Joerg