Anyone else having these VDR issues?

[jarsenea]

I love the fact that VMware is providing VDR as part of the vSphere package. It's definitely a step in the right direction, albeit I'm still inclined to think this software hasn't been put through the ringer in terms of proper QA. I'm just trying to put out a feeler to see how many others have experienced some of the same issues I'm having.

To start, I'm backing up my VMs via a network share on a standalone Windows 2003 server that has a NAS attached to it.

Some of the issues I've noticed:

1) Backups take an inordinate amount of time. I can understand the first backup, but my VMs don't change very much from day to day. Most of the data being manipulated is located on RDMs are these are backed up using Tivoli, not VDR (I use VDR solely for the OS partitions). Each partition is approximately 25GB, there are 15 VMs and my backup window (10pm - 6pm) isn't sufficient to complete the process.

2) Integrity checks for the backups are taking a crazy amount of time and will usually stop due to my window being closed (see point #1)

3) I'm getting inconsistent "failures" for certain VMs (the report will simply state that a VM failed to backup, not much else). It also varies per night and not always the same VMs (not exactly sure if this is related to #1 where the window is closing while VDR is executing)

4) I had the most difficult time setting up the remote share from the VDR appliance in vSphere. The username and password would never be accepted (even though if I tried the same share with the same user/pass on a Windows machine, it would work fine). I finally narrowed down the problem to the simple fact that the VDR appliance can't handle passwords that have special characters in them (this password had an "@" and a ","). Looking at the console while attempting to mount the share would spit out a CIFS error -22. Changing the password to include only numbers and letters was sufficient to work around this issue.

5) Snapshots not being created for no apparent reason and thus failing the VDR process. I'm fully able to do a manual snapshot with or without the memory state, so I'm not sure why VDR can't do it. This issue is very intermittent. I had it often when I first setup VDR, but now it only happens every so often (without any type of consistency).

I think that's all I can think about for now..

[RParker]

I appreciate the comments and we take them to heart.

I'm sorry but that's not good enough. I don't think YOU have any authority, and given the fact the VM Ware products over the past year have been LESS then stellar at release, or like now obviously BETA material, certainly NOT GA release, that doesn't seem to be the case.

Maybe you THINK they take it to heart, but actions speak louder than words. I see no changes in the way VM Ware releases their product, that is issue.

Why can't we being the people who buy, use and manage this software test it BEFORE you check it off the list to be release? That's all we are asking.

Take that heart and get back to me.

[RParker]

Having all of these issues myself. VDR is defintely not ready for a small business let alone enterprise.

Or even testing... I can't even TEST with it, it's so rediculous.

What is most annoying though is the constant WAITING. I get hardly any feedback as to what is going on.

Or from the engineers at VM Ware.

Failing snapshots, random terminations, slow backing up etc..etc..etc...etc..

Poor implementation, remedial sparse documentation, poor customization, limited options . . . . .

Really don't see how it ended up in 4.0 in this state. This isn't even beta level.

I second that! It's like pre-Alpha.

[RParker]

Will try 1.0.1 VDR

Yup back to Vizioncore

7/17/ - VDR 1.01 seems to be better, I can login now, and so far no snapshot snafus.. although 1 VM (with multiple previous snapshots gives an error, and it will not delete the snapshot). If I check the VM manually, it shows the snapshot as gone... Everything else is .. dare I say it.. adequate (not perfect)

Message was edited by: RParker

[Oletho]

But esXpress does not support vSphere, right?

Ole Thomsen

[certtrainer]

I believe the new version does- going to test this week.

[petedr]

Ole,

You are correct that the current version of esXpress does not support vSphere.

However the esXpress 3.5-9 which will be released this week will support vSphere hosts.

Pete@esXpress

www.phdvirtual.com, makers of esXpress

[petedr]

A follow up, the esXpress 3.5-9 release which supports vSphere is now available.

Pete@esXpress

www.phdvirtual.com, makers of esXpress

[RParker]

Don't think I will bother putting in an SR- this product does not look reliable.

VDR 1.01 is better.. have you tried that, NOT the one that was release with ESX 4.0 this is an update . . . . .

[KBuchanan]

I am running v1.0.1 - and it is still buggy to some degree. I opened SR 1431443551 because I am getting integrity errors, some of the machines fail to backup, and I can't restore some of the images.

Well - for a backup product, VDR is failing miserably. I would like to hear that someone is actually successful with the backups and then understand why their experience with VDR isn't repeatable. There is a lot of "problems" circulating in the forum - which tells me VDR has some serious flaws for the masses!

[certtrainer]

As per my post above-

It still does not work correctly.

[KBuchanan]

Frustrating, isn't it? I have an SR opened (yesterday) - so, I am expecting a follow=up today. I'll post the outcome here. I am very anxious to know that this product "DOES INDEED" perform as VMWare states - but, so far, I can't say it can perform "as stated" with a high degree of reliability and repeatability.

Kevin

[pkurnaev]

Hi everybody! I`ve got the same issue - VDR crashes while backing up VM with large virtual disks (40250250Gb).

Did anyone noticed relationship between VM's size and backup process reliability?

[mgaub]

Hi everybody! I have the same problems. I have VDR 1.0.1 running for a few days, backing up 21 VM's without any problem. As soon as I add a VM with large disks (24500100100100 GB) VDR crashes. After that, my destination volume is corrupt with error -2241, and the integrity check stucks at 33%. I had to reformat the volume to make it working again!

Marc

[Steve5]

Well, I can't even get a backup to run. I'm running 1.0.1.362 with a local share (why can't I browse locally?) and I've had to format my destination twice to pass the integrity check.

Immediately after starting a backup using Backup Now, the job fails and I get:

"Can't access Backup Set /my ip/my share, error -2246 (wrong Destination index found)

This is fresh install of VDR on a fresh install of VC. I've changed the local share username and password to alphanumerics with no change to the error.

[RParker]

product "DOES INDEED" perform as VMWare states

Can you say with reasonable amount of certainty that your backups are SAN based and not network? I figured out I am getting a permissions error (vcbAPI) not sure why that is...

[KBuchanan]

RParker wrote: product "DOES INDEED" perform as VMWare states

Can you say with reasonable amount of certainty that your backups are SAN based and not network? I figured out I am getting a permissions error (vcbAPI) not sure why that is...

I'm not sure if you were directing your comment to me. But, I am backing up the VMs to SAN storage - and regrettably, it is SAN storage in the "same rack". I would prefer to have the VDR backing up to a NFS share in another data center. I tried to do that, and I kept getting failures.

Currently, I have 4 days of successful with VDR. I have been able to sucessfully restore each VM to a "re-named/re-directed VM". I had a SR opened regarding failures with backups (see this thread). I was getting a Incompatible device backing specified for device '1' error. The VM Support Tech admitted there was a bug. I posted the resolution and a workaround is in the link.

The largest VM I am backing up is around 60G. I don't have enough confidence in VDR to say it is reliable, and I have strong reservations that it can backup to a storage device across the network (ie, CIFS, NFS). I tried NFS, and kept getting numerous backup failures and integrity check errors. I am not getting any errors backing up to a SAN.

My advice: TEST IT, and it your test is sucessful, TEST IT AGAIN. Keep testing every few days to see if it can restore - and WATCH THOSE LOGS!

[alexlie]

I'm using VDR 1.0.1.362 with two local destinations disks with ~2 TB total (via iSCSI)

I've notices the following issues:

1) If a vm has more than one disks with the same name (e.g. xyz.vmdk) on different datastores the restore tab only shows the first disk on the vm after the backup

2) In the navigation pane some machines show up with a nested second machine with the same name when expanded (it's not recursive - despite the +-sign the nested instance does not have a vmdk)

3) During the last backup job some vmdks vanished in the navigation pane - the are all back now

4) Got some errors: -3941 (create snapshot failed), "failed to create snapshot for xyz, error -1" - Don't know what to do.

5) Got "Destination "/SCSI-0:2/" will be locked until the restore point with errors are delete and integrity check succeeds." - Nice, what should I do? Which are the restore points with errors?

6) During the last automatic integrity check I've noticed a task without name and with start-time - what's that?

7) All in all backups took very long (>2 days for machines with ~200 GB disks)

I really like the concept of VDR but in the current state it is barely useable nor can I rely on it as our only backup solution.

[KBuchanan]

I would be surprised if VMware is actually reading this.

Kevin Buchanan

Chief Information Officer

Lexington Memorial Hospital

336-238-4286

kbuchanan@lexmem.org

[admin]

Alexie

A) You mentioned iSCSI as your destination disk? Can you confirm that the iSCSI array is listed in the VMware storage compatibilty list

http://www.vmware.com/resources/compatibility/search.php

B) Are the disks destination disk thick or thin provisioned? We have some recommendations on this here:

http://viops.vmware.com/home/docs/DOC-1551

We have seen a lot of issues with customers using non-HCL compliant storage. They fall under one of two categories

a. Low end NAS solutionsthat support CIFS/iSCSI/NFS and additional protocols.

b. Repurposed Windows 200x shares.

Obviously, how efficient these types of destination disks are will impact how well VDR performs. Our recommendation is to utilize HCL compliane storage for VDR destination disks.

On your questions

1) My guess is that this is a bug - thanks for finding it. However, is this something that is typical in your environment?

2) Which navigation pane? Main, Backup or Restore?

3) Which navigation pane? Main, Backup or Restore?

4) I know that this is passing the buck, but snapshots are executed by the vmkernel - VDR just makes an API call and reports back the result. Has a VDR snapshot (i.e subsequent backup) failed? I know of some customers that have said that rebooting the VDR appliance solves this problem, but we are not convinced that they are related.

5) In VDR/Configuration/Logs, scan to the last failed integrity check and you will see the restore points with errors. The quick workaround is to manually mark these restore points for deletion, though obviously, we are concerned about how these restore points got into this error state to begin with. Do you see any clues in the logs around errors for these VMs/restore points?

6) Don't know - if you see it again, can you get a screen shot?

7) Obviously, the backup duration will be dependent on amount of data to be copied and how many of the vSphere optimization is being utilized?

How many VMs were being backed up per backup job?

I assume these VMs had been backed up before and there are restore points in the dedupe store?

Are the VMs HW 4 or HW7 (HW is better since we do not have to scan to the disks to determine changed blocks?

I assume that the logs state that the snapshots are being hot-added to the VDR appliance (as opposed data being copied over the network)? Obviously, copying over the network will be much slower that performing hot-adds of the snapshots

[ehinkle]

Point number one is a known issue with esx3.5 and creating snapshots on a vm with virtualdisk having the same name on different data stores you will need to rename the virtual disk.

KB 5096672 -http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=5096672&sliceId=1&docTypeID=DT_KB_1_1&dialogID=32222594&stateId=0%200%2028722776