Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Erfahrungen vRanger 5.5
Erfahrungen vRanger 5.5
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
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
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 ?!
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 ?!
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
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
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
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?
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?
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
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.
und hier mal eine mit gleichen
Gruss
Joerg
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
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)
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Sind deine VMDKs eigentlich alle gleicher Grösse?irix hat geschrieben: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.
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.
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Dayworker hat geschrieben:Sind deine VMDKs eigentlich alle gleicher Grösse?irix hat geschrieben: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.
Nein, wir vermeiden vDISKs mit der gleichen Groesse damit eine identifizierung fuer uns im Fall der Faelle moeglich ist.
Gruss
Joerg
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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.irix hat geschrieben:Nein, wir vermeiden vDISKs mit der gleichen Groesse damit eine identifizierung fuer uns im Fall der Faelle moeglich ist.
Eventuell liegt das Problem aber auch an VMware selbst und vRanger ist aufgrund dessen über die API zum scheitern verdammt.Supi hat geschrieben: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.
@Daywalker:
mit dem Shrinken meine ich das hier: http://vmguy.com/wordpress/index.php/archives/1639
mit dem Shrinken meine ich das hier: http://vmguy.com/wordpress/index.php/archives/1639
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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.
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.
@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
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
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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.
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.
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
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
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
Zurück zu „3rd Party Zubehör und Produkte“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste