cancel
Showing results for 
Search instead for 
Did you mean: 

NBU 8.1 Status and Duplicate UUID Issue via SAN

HunkerDownOneMo
Level 4

Not sure how many users out there are impacted by this, however, the issue remains in 8.0 as the older VDDK is still used - if you have a duplicate VM BIOS UUID and use SAN Transport, backup will fail. We are stuck using the much slower NBD backup transport method. The fact that Veritas and VMWARE cant seem to get together and offer an EEB patch until 8.1 (which supposedly will use a newer VDDK and resolves the issue) is released is absolutely unacceptable.

Its been MONTHS and MONTHS with zero word on any update or resolution. The lack of response and lack of updates on this critical issue is very frustrating. When can we expect an 8.1 release with the updated VDDK to resolve this issue?  Its now almost around 6 months since 8.0 came out with NO updates or fixes to this issue - unreal from a world-class company like Veritas. 

I hope that if you use SAN transport and happen to have duplicate BIOS UUIDs (required for replication or otherwise) that you aren't stuck like this. It certainly is business impacting and with zero patches and lack of updates, its been very frustrating. Where is 8.1 or an EEB?

10 REPLIES 10

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Best to get hold of NBU Product Management via your local Veritas SE.

 

That has been done numerous occasions, clearly no action has been taken. Nothing but silence on the issue - no acknowledgement on the known issues pages, no EEB, nothing. This was not an issue in 772 and broke in 773. 772 doesn't support later version of vCloud Dir that 773 / 8.0 does. Both contain the BIOS UUID issue. The fact an EEB can't be provided after 6 months or longer with this issue present is just beyond comprehension for a world class provider like Vertias. 

Nicolai
Moderator
Moderator
Partner    VIP   

Do you have a open support ticket on the issue ?

If yes, can you have a valid support contract, I suggest to escalate the issue by call the support line and asking for the duty manger. You have to escalate the issue, veritas support staff won't do it themselves.

 

We have done that numerous times. We have noted this as a severe, critical issue numerous times with escalation as far as we can take it - and still - nothing. No EEB, no 8.1 release to fix it, nothing. Its not even acknowledged as an issue and it should be! We have requested escalation every which way possible and we get nothing. 

If you could just waive a magic wand and have all VMs with no duplicate BIOS UUIDs or magically have 10 gig fiber for NBD traffic that would be one thing, but its impossible - SAN backups need to work, duplicate UUID or not. It was NEVER a problem prior to 772 - and it should have never been MADE an issue to begin with. Unreal that it was not tested before release. 

Funny... still no word from Vertias, no update, nothing. As if this is not a huge problem. This has been a huge issue since 773 and we can't get an EEB or patch out? This is truly unreal. Smiley Mad

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified
The fact that Veritas and VMWARE cant seem to get together and offer an EEB patch until 8.1 (which supposedly will use a newer VDDK and resolves the issue) is released is absolutely unacceptable.

It sounds like you understan that VDDK is a root cause of the problem. And you probably understand that it isn't always possible to add newer VDDK support to older releases using EEB. If you have a support contract you should be able to contact Product Manager who knows for sure what version of VDDK will be used in 8.1 and that ETracks will be closed in new release. Could you share ETrack numbers support team gave to you?

No excuse. You have a broken product. It was the same VDDK "version" in 772 and 773, yet there was no issue in 772 and broke in 773... such a SLIGHT difference caused this issue. No one tested it, no one thought to stop before release and realize what happened? We know the newer VDDK will be in 8.1 We get that. The impact is way too signnificant to sit on it this long. So you are saying its OK for SAN transport to be broken since 773?

Symatnec \ Vertias used to provide much quicker patch releases and fixes, and now its been since Dec last year with no updates or fixes since 8.0 came out - WAY too long. Its such a critical issue 8.1 fix should have been released months ago - there is no way it takes from Dec until almost middle of June (and I assume much longer) to release a fix.

I don't have the etrack numbers otherwise I'd gladly share them - they are formally being handlded by someone else - however, etrack or no etrack, so just let this sit there and to do nothing and just let this continue to be an issue since 773... there is just no excuse. This has been known for QUITE some time... and I guess to expect a more timely release / fix is just too much? 

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified

I totally understand your emotions regarding the problem but VOX isn't the best way to solve  problems that require engineering team,  patches and so on. I believe that you need to have a conversation with a Product Manager and get firsthand information. 

Genericus
Moderator
Moderator
   VIP   

IMHO, if a vendor has an issue they are not addressing, the VOX arena IS the best place for it.

1. more customers will seek resolution, increasing urgency at Veritas

2. impacted customers will NOT update to the flawed version, I always look for this type thing here before I upgrade. It is not like Veritas indicates on the update page - upgrading to 8.0 will break your VDDK replication

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

We have gone that route - and nothing. We have requested numerous updates, we have requested a fix, we have gone up the ladder - and we get nothing. This forum will help bring this issue to light - we can't be the only folks that this is happening to - and the bigger issue is that its not even addresssed as a known issue. This was never an issue pior to 772 - I understand the reason it was changed was to increase performance - but there appears to have been no QA, no validation that this was not an issue - and just released it. 7612 is end of life; 772 does not support newer vCloud Director versions and 773 and of course 8.0 does - so we are between a rock and a hard place at this point. Can't use end of life software and can't run versions that dont support newer vCloud versions - so what do we do - keep replying on over the wire backups? Its terrible. A fix needs to happen - and soon. Its business and performance impacting to a very high degree.