VMware Block Optimization Support doesn't work

[alexey107]

Hi, i am using BE2014 SP1. While protecting some of Virtual machines within EXSi5.5 update2 vCenter5.5 update 2 infrastructure i have an issue. BE backups the whole vmdk disk of vm with guest os centos 4/5/6 (32bit) instead of backing up only used space.

For example.

srvTEST00:

guest OS: centos 4/5/6 (32bit)
VM version: 8
Hard Disk: Thick provision Lazy Zeroed, 51 GB. Disk type- BASIC MBR. 2 Volumes EXT3, 1 Volume Linux Swap.
SCSI controller Type: LSI logic Parallel

BackUP job settings:

GRT disabled

After backup finishes, i see Byte count = 51 GB. Summary size of backup sets files = 51 GB also.

With guestOS like windows, Red Hat, VMware Block Optimization Support works correct and backing up noly used space in .vmdk

P.S. BE2010 R3 SP4 have this issue too.

Please help!!!

[VJware]

Probably because CentOS isn't actually listed in the SCL, though RHEL is. Do you see this behavior on any supported OSes ?
 

[alexey107]

Thank you for reply.
I didn't find anything in SCL (http://www.symantec.com/business/support/library/BUSINESS/xCL/TECH217478/be_2014_scl.pdf) about compatibility between BE vMware agent and guestOS in vCenter. There are only between BE and vCenter. We have only one VM with centos which is backed up normaly:


srvTEST01:

guest OS: centos 4/5/6/7 (64bit)
VM version: 8
Hard Disk: Thick provision Lazy Zeroed
SCSI controller Type: LSI logic Parallel

the only difference between them is guest OS version and real installed centos version:

srvTEST01 have CentOS release 6.5 (final)

srvTEST00 have CentOS release 5.11 (final)

All others VMs is backed up normaly. They are windows and RHEL.

[VJware]

Would recommend to log a formal support case and pls PM me the case number as well. Thanks.

[alexey107]

We don't have BE2014 in product. We use trial version to test it. And may be buy it to upgrade BE2010 R3 in future. How can i start case using trial version?

[VJware]

Do all the VMDKs reside on the same datastore ? Are the CentOS VMDKs residing on a NFS datastore ?

Have you tried to reset the CBT for these VMs ?

[Colin_Weaver]

VJware is basically asking if you have done this

http://www.symantec.com/docs/TECH197311

[alexey107]

Yes, vmdk from srvTest01 and from srvTest00 are on the same datastore. Data store type is VMFS5. I tried to reset CBT using this http://www.veeam.com/kb1113 . It doesn't help.

[alexey107]

Thank you for reply.

Have just read your tech-link. I have the same errors in my beremote log. I will try to do steps in solution section once again more carefully. Will reply with reults later.

[alexey107]

Thank you for answers.

After a tests i found out that this fix http://www.symantec.com/docs/TECH197311 resloved this issue. This error has gone "[fsys\vmvcb]         - SymVmTools: GetDiskChangedInfoAPI: SYM_VMC_ERROR:  SOAP_ERROR". But i stil had big backup. It was because of LVM installed in centos. After removing LVM backup size became small. But stil doesn't equal to used space. My vmdk file is:

52GB Basic MBR:
- Volume '/boot'. Size: 101,9 MB. Used: 28.02 MB. EXT3.

- Volume 'Local volume'. Size: 46,58GB. Used: 14,07GB. EXT3

- Volume 'Local volume'. Size: 5,324GB. Used:4 KB. Linux Swap.

Theoretically my backup size must be 14,1GB, but it is 22.2GB now. Why?
I will try to use some tools to check disk and fix errors.

[Colin_Weaver]

That could just be a block size handing issue as I doubt the process could ever get down to exactly the same byte count.

[alexey107]

Checked logical disks- no errors found. What is block size handling issue? With windows and RH vMware backup i have byte count=used bytes on .vmdk

[VJware]

 For non-windows VMs, we rely on the result from VMware APIs about the changed/used blocks, whereas for windows based VMs, we try the VMware code first and if it doesn't work, we fall back to our code to calculate the size.

I would recommend to enable debugging and check the vmware logs as to what size is being returned by the APIs.

[alexey107]

Could you please explain what debugg log do you mean? There are a lot fo different logs.

[alexey107]

2014-12-09T08:42:09.649Z| vcpu-0| I120: DISKLIB-VMFS  : "/vmfs/volumes/520f35ab-02615c9c-d937-d48564526442/srvWEB03.clone00/srvWEB03.clone00_1-flat.vmdk" : open successful (65557) size = 55834574848, hd = 0. Type 3

This is from debugg log of virtual machine. We see size of 52GB. It is hard disk drive size.

[alexey107]

Please, explain what kind of debugg log do you mean? Where can i see what?

[VJware]

You could start off with this KB - http://www.symantec.com/business/support/index?page=content&id=TECH63926

It'll probably be easier to log a formal support case to review the logs.

[alexey107]

Hello.

Detected en error in the log, captured using "Backup Exec Debug Monitor" with vmware agent selection.

BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\shared]        - The disk '[VM SATA Storage 01] srvWEB03.clone00/srvWEB03.clone00_1.vmdk' is using the transport mode 'hotadd'.
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - VM_VCBPROXY_FS::GetVmdkDiskBitMap: INFO: Disk total sectors = 109051904, Disk capacity bytes = 55834574848 <0xd00000000>
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - ResolveVolumes: DynVolsNotSupported=0, GptVolsNotSupported=0
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - ResolveVolumes: Saving partition: systemId = 0x83, partition number 0
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - ResolveVolumes: detected UNSUPPORTED partition, 131
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - ResolveVolumes: retVal = 0XE00095A5
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - ResolvePartitions: retVal = 0XE00095A5
BEREMOTE: [12/16/14 12:27:56] [2864]     [fsys\vmvcb]         - VM_VCBPROXY_FS::GetVmdkDiskBitMap: status CODE (E00095A5) for VM <(DC)1st Datacenter(DC)\vm\1.SIT Stage\RT\srvWEB03.clone00>

We see "detected UNSUPPORTED partition, 131".