Stuck VMDK files attached to Veeam Proxy

[kjstech]

Hello,

Were on Veeam 7.0.0.871. We do plan on upgrading to 8 so I'm curious if this issue has been fixed in version 8 or not?

We have to go through this procedure perhaps every other month. It's a random thing.
http://www.veeam.com/kb1775

We have a server called Veeam and also a proxy called C3P0. (Yes, Star Wars fans).

The environment is ESXi 5.0.0, 2000308.

I have C3P0's vmx file showing 9 disks. It should only have 1 disk (its own). After business hours I have to RDP to it, shut it down and register it on another vm host and then remove the references to the extra vmdk files. This is because the host its on has an issue with hostd right now and wont come up. Machines are working but vSphere cannot manage the ESXi host. Not sure if these two are related.

Again long story short, is this improved in version 8?

[Vitaliy S.]

Hello Keith,

Since this KB talks about invoking API calls that are controlled by vSphere, I'm not sure it applies to any of Veeam version. Anyway, upgrading to the latest release of Veeam and patching ESXi hosts does make sense.

Thank you!

[kjstech]

I realize Veeam is just doing API calls, but what it could do is just check that the snapshot disks were disconnected properly and the snapshot was in fact consolidated. Once this check returns true then it can proceed with the next operation. If it does not succeed then it can retry those API calls and retry until its done right. Basically take my manual intervention out where I look for delta vmdk files and where they are. That's a good indication were still running on snapshots.

There are a large amount of "troubleshooting VMware Snapshots" articles out there, like this one for example: http://searchvmware.techtarget.com/tip/ ... -snapshots

There are common steps for each one. Instead of me or another admin doing these checks, maybe Veeam can script it out. I say if you can't control the other end (VMWare API in this instance), you should at least do checks upon checks and recovery actions if needed, rather then just fire away commands and think that they worked without checking.


By the way, these files are in the folder for VM C3P0, a Veeam backup proxy. Is it safe to delete these? They look old...

Code: Select all

-rw-------    1 root     root        16.3M Oct  8 04:45 email-000006.vmdk-delta.REDO_OVz2gx
-rw-------    1 root     root          371 Oct  8 04:32 email-000006.vmdk.REDO_OVz2gx
-rw-------    1 root     root        16.2M Sep  6 04:44 email-000012.vmdk-delta.REDO_qurntx
-rw-------    1 root     root          371 Sep  6 04:35 email-000012.vmdk.REDO_qurntx
-rw-------    1 root     root       204.0k Sep  8 13:19 email.vmdk-delta.REDO_iHsLUN
-rw-------    1 root     root          357 Sep  8 13:19 email.vmdk.REDO_iHsLUN
-rw-------    1 root     root        18.0M Oct  8 04:45 email_1-000006.vmdk-delta.REDO_dZzxJt
-rw-------    1 root     root          376 Oct  8 04:32 email_1-000006.vmdk.REDO_dZzxJt
-rw-------    1 root     root        18.0M Sep  7 05:22 email_1-000012.vmdk-delta.REDO_SaKwbp
-rw-------    1 root     root          376 Sep  7 05:06 email_1-000012.vmdk.REDO_SaKwbp
-rw-------    1 root     root        18.0M Sep  7 05:06 email_1-000014.vmdk-delta.REDO_9NMWgz
-rw-------    1 root     root          376 Sep  7 04:42 email_1-000014.vmdk.REDO_9NMWgz
-rw-------    1 root     root        16.3M Oct  8 04:45 email_2-000006.vmdk-delta.REDO_zDiIas
-rw-------    1 root     root          375 Oct  8 04:32 email_2-000006.vmdk.REDO_zDiIas
-rw-------    1 root     root        16.2M Sep  7 05:06 email_2-000014.vmdk-delta.REDO_gbicHb
-rw-------    1 root     root          375 Sep  7 04:42 email_2-000014.vmdk.REDO_gbicHb

[Vitaliy S.]

Once you have removed all disks, it is safe to remove these files as well. I guess the reason why sometimes you can see this situation, is that the API call returns true for snapshot consolidation, however in reality in can be the opposite. I see your point and agree with this.

These kind of issues could have been resolved in latest VMware updates, so I would suggest upgrading to 5.5 (if there is such possibility) and then check if you have the same behavior or not.

[kjstech]

Ok thank you for the update.

I will remove those files. They have old dates and I don't see them referenced anywhere else anyway.

I updated to Veeam 8 and the patch 1.

As far as upgrading VMWare ESXi to 5.5, well I have 4 new servers on order. When they come in possibly we could think about that. 5.0 works nicely though. No dumb slow web gui, just the simple vSphere client. No stupid single sign on service. Its just a simpler system. I was going to wait until 6.0 came out, but maybe we will look at 5.5. There's other elements at play though like vmware servers at our DR site, SRM, VMWare Replication, VMWare update manager, the long drawn out and complicated certificate process for vmware services, etc...

[Vitaliy S.]

No dumb slow web gui, just the simple vSphere client. No stupid single sign on service. Its just a simpler system. I was going to wait until 6.0 came out, but maybe we will look at 5.5.

As far as I remember, at VMworld event VMware promised to keep Windows-based vSphere Client in v6, besides it works well in v5.5 in our labs

[Gostev]

Again long story short, is this improved in version 8?

Chances are, yes (as there were some hot add related logic improvements). Would be interesting to see if that helps you.