Absent Member.. Absent Member..
Absent Member..
1036 views

DP 6.2 VMWare Integration Agent - Unable to delete disk scsi0:0 when restoring VM

Hi All,

 

Once again another request for assistance with the VMWare integration,

 

We are running DP 6.2 on Windows Server 2008 and have recently -after much effort - managed to successfully test the restore of a single file using the VMWARE GRE integration.

 

I would now like to test restoring a whole gues VM to its original location in the datacentre -rather than to a different filesystem such as a mount proxy- but when I do this I get an error similar to the following:

[Normal] From: OB2BAR_VEAgent@mountproxyhost "/Datastore"  Time: 8/11/2011 4:28:26 PM
 Virtual Machine 'DP-Test': deleting disk scsi0:0...

 

[Critical] From: OB2BAR_VEAgent@mountproxyhost "/Datastore"  Time: 8/11/2011 4:28:28 PM
 Virtual Machine 'DP-Test': could not delete disk scsi0:0

 

The above error was received when I used the default option of deleting the existing virtual machine before the restore.

 

I then tried the same restore but specifying the "delete after restore" option and this time the messages were:

 

[Normal]

From: OB2BAR_VEAgent@mountproxyhost "/Datastore" Time: 8/11/2011 4:35:08 PM

Starting OB2BAR Restore: vCentersystem:/%2FDatastore/4/%2FDatastore%2Fhost%2FDR%2FDP-Test "VEAgent"

 

[Critical]

From: OB2BAR_VEAgent@mountproxyhost "/Datastore" Time: 8/11/2011 4:35:12 PM

Virtual Machine 'DP-Test': error creating disk scsi0:0

 

[Critical]

From: OB2BAR_VEAgent@mountproxyhost "/Datastore" Time: 8/11/2011 4:35:12 PM

Virtual Machine 'DP-Test': Error restoring item \a1f9f4e3-482d-4b7f-afcb-cb16babe1980\%2FDatastore\vms\%2FDatastore%2Fhost%2FDR%2FDP-Test\images\2\scsi0-0.meta.

 

[Normal]

From: OB2BAR_VEAgent@Mountproxyhost "/Datastore" Time: 8/11/2011 4:35:12 PM

Completed OB2BAR Restore: vCentersystem:/%2FDatastore/4/%2FDatastore%2Fhost%2FDR%2FDP-Test "VEAgent"

 

[Normal]

From: RSM@CellManager "" Time: 8/11/2011 4:35:14 PM

OB2BAR application on "mountproxyhost" disconnected.

 

I should mention that as part of the test scenario I asked my VMware admin to make the test virtual machine unbootable which he did by renaming the .vmx file which I believe -correct me if I am mistaken- will effectively remove visibility of the virtual machine's disks rendering it unbootable.

 

I should also note however that when I have taken Virtual Environment Integration backup and then performed the restore of the test vm to a mount proxy for the purposes ofa stepping through the GRE restore that no .vmx file is listed in the restore folder on the mount proxy.  The only files that exist on the mount proxy are a virtaul machine.vmdk file, a virtual machine-flat .vmdk file and then a scsi0.meta file but no .vmx file.

 

I have not cleaned-up these previously restored files from the mount proxy since I am trying to restore directly to the original datastore that the virtual machine was hosted on rather than to the mount proxy LUN.

 

Do I need to first cldelete the restore files from my previous GRE based restore off the mount proxy?

 

Also, where is the .vmx file?

 

Thanking you for your considered replies.

 

Michael

 

 

 

0 Likes
1 Reply
Micro Focus Expert
Micro Focus Expert

Hello Michael

 

It could be for several reason, the best way is reproduce issue in debug mode and then we be able to see what is happening.

 

Please open a call support ant they will give to you details.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.