Thanks RParker. I'll try out VDR 2.0 on 4.1. I do need to figure out the problem with this version however.
I took a look at the Client Log after failing to Edit Comments. Here's the error that is the root of the problem:
Exception: "RefBackupset::Connect error -2246"
This error is generated multiple times after the Mount. The mount succeeds. The restore points are available. But I can't back up to it, Edit Comments or run an Integrity Check.
I searched this forum and the knowledge base for "2246" and found it refenced in KB 1024210. And then it all came back to me, I've been down this road before. I've deleted the catalog files and rebuilt them. It doesn't immediately fix the problem.
Just now, I've gone back to my Destinations and there's the comment field filled out. It was empty before. So the connection succeeded just enough to retrieve the comment field. Oops, now the log is showing the connection error again. And I can't Edit Comments.
So this is intermittent and I have no workaround as I suggested in my initial posting.
I now think this is a NAS problem. I've seen it before working with the ix2-200r because that unit has issues with NFS mounted vmdk's. And now I'm seeing it with the QNAP not with the internal array but with an eSATA connected external drive. So the problem is intermittent connections between VDR 1.2 on ESX 4.1 and a QNAP connected external hard drive.
I'll post here if I discover anything more.
I titled this thread "VDR and Edit Comments" issue and that's been a good choice. The absence of comments after mounting a VDR destination is an indication you will see "RefBackupset::Connect: error -2246" logged in the VDR Client log (Shift-Log). Your mount will appear successful. You will see restore points. But you won't be able to backup to the destination. And you won't be able to perform an Integrity Check.
The knowledge base gives an example of a 2246 error but in the context of performing a backup. Not just after mounting as I see it. I use to follow it's advice of rebuilding the catalogs but it did not fix the problem. Then, at some point, the mount would work. The comments would reappear. No error in the Client log. And full destination functionality restored.
Here's what I saw today. I ran a full backup to a QNAP TS-459U+ and it's NFS shared eSATA external drive. The backup was successful. However, I noticed my comments had disappeared. The Client log was producing a steady stream of 2246 errors. This is because if you have a Backup job pointed to a mounted destination, VDR will constantly access that destination (probably only when you have the plug-in GUI active). In this case, VDR couldn't access it thus the 2246 error. I added other QNAP NFS shares with destination disks I know are good. None of them would mount with comments. All of them showed the 2246 error when mounting.
I then added a destination drive from a ReadyNAS 2100. The comments showed up. No 2246 error. Yet unmounting and mounting the QNAP drives still showed the error. So it appears to be a QNAP problem similar to what I've seen on the Iomega NAS.
Later, the comments appeared on the QNAP drive I had mounted. The connection had been restored.
I've made sure it isn't something like "hard disk standby". I don't have a fix as the connection has restored itself.
I'll keep looking!
I looked up the VDR 2.0.0 Release Notes and saw that vSphere 4.1 is supported. Very good!
So I upgraded and tested it out with the QNAP. Quite reliably, the problem is still there. Error -2246 when mounting the QNAP eSATA external drive. No problem mounting ReadyNAS or QNAP internal drives.
Rebooting the QNAP allowed me to mount its external drive. Ooops, now it won't.
I finally figured it out. My problems mounting destination disks with VDR 1.2.1 or 2.0 have nothing to do with whether the destination is located on a particular NAS or a hard drive mounted externally to a that NAS. Instead, it matters what SCSI ID number I give the disk when I first add it to the VDR appliance.
Here's what happens:
If after I mount a destination, its comments do not appear, -2246 errors are logged in the VDR client log (sometimes every second or so), and I find the destination declared mounted but it can't be used as a backup destination ("unavailable"), then I will find an existing backup job that was previously used with the same SCSI ID as the destination disk I am trying to mount.
The workaround is to either delete the old backup job(s) or add the destination disk to VDR with a SCSI ID different from the old backup job(s). Then I will be able to mount the new destination cleanly with no errors.
This has worked on VDR 2.0 and I duplicated the same fix for the guys across the hall with VDR 1.2.1.
This is why one of the "fixes" seen in this forum for problems with VDR destinations has been to delete all the existing backup jobs. But I've never seen it explained why this worked. These jobs are actively looking for their destinations by SCSI ID. If you attempt to mount a different destination with the same SCSI ID, a -2246 error (and others) is generated. But the disk will appear to mount without the comments displaying and it will be unusable.
Before I understood this, I opened a rare support request with VMware and duplicated my problems to the representative. He is unaware of this issue as he blamed the problem on my high latency devices and recommended I stop trying to use VDR to back up to these externally mounted USB drives. I pointed out that all my backup devices show high latencies and that it was unrealistic for the engineers to expect VDR to be used only with 20ms write latency devices such as a 12 spindle NetApp or such.
I'm attempting to reopen the support case. VDR needs to do a better job handling this with a warning or by fixing the code. Yes, I can see why you wouldn't want all your jobs ready to do a scheduled backup to every destination you mount. But screwing up the mount and generating obscure client log errors is not informative. It's been messing with my head since VDR was first released.