• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

opinions on vRanger?

T

Thuleman

Supreme [H]ardness
Joined
Apr 13, 2004
Messages
5,833
Does anyone have any practical experience with vRanger?

Dell is offering it bundled at approximately $400 per socket (your pricing may vary) per year. Just looking to see whether there are any glaring reasons as to why not to get it and get something else instead (or nothing at all?).
 
Oh, vDanger.

It's called that for a reason.

Use VCB and an appropriate integration module, if you're looking for ESX support.

edit: vRanger is pretty bad about cleaning things up when it fails. Absolutely horrible. It leaves snapshots behind lots of times, commits the snap header but not the snap, and doesn't know to commit on a failure. Nice GUI though.

Personal opinion and all, but there are better options.
 
I am buying a couple Dell 2950 IIIs with an PS5000E, and the Dell rep as well as the VAR I am working with both pushed vRanger pretty hard. I have a face-to-face with both of them tomorrow, will bring the points you mentioned up and see what they have to say about it.

At roughly 50K for the setup $400 per socket isn't a big deal, but on the other hand if I can save the $1600/year in operating costs, or get something better instead, then I may as well do that.
 
I'd strongly suggest VCB and a module. VCB is a lot more reliable from a failure standpoint - first thing a failure does is commit the snap, which is VERY important. It won't even try again till that snap is gone, and given how an ESX snapshot works, this is a major major issue. I've seen 32-deep nested vRanger snapshots before.

Most of the major backup programs (backupexec/netback/etc) have good integration modules for VCB and work great.

Please note: This is my personal opinion. Nothing more.
 
Ahh ..., I don't have a "major backup program", I am using Amanda/Zmanda for backups and the system is too well established across servers and clients to change that. Zmanda doesn't offer an integration module.

Thanks for the warning though, I will definitely bring those points up tomorrow.
 
In that case it gets a bit more difficult. You can easily write your own scripts to call VCB, but it ~is~ a windows program. VCB can easily run on your VC server without any problem.
 
I just use VCB. I haev a windows machine that has scheduled tasks that calls batch jobs to run that do the backups.

:)

Why pay when you can do it for free?
 
MrFace said:
I just use VCB. I haev a windows machine that has scheduled tasks that calls batch jobs to run that do the backups.

:)

Why pay when you can do it for free?
Click to expand...

This too

Especially since we have the cscript commands built in. Fix the config.js file to fit your environment, then call the suckers. :)
 
lopoetve said:
Oh, vDanger.

It's called that for a reason.

Use VCB and an appropriate integration module, if you're looking for ESX support.

edit: vRanger is pretty bad about cleaning things up when it fails. Absolutely horrible. It leaves snapshots behind lots of times, commits the snap header but not the snap, and doesn't know to commit on a failure. Nice GUI though.

Personal opinion and all, but there are better options.
Click to expand...

Wow... Where to begin? First off, I agree, 100%. Where I work, we have 4 fully populated HP blade centers. Each blade has two quad core Xeons (don't remember the speeds) with 16GB of RAM per blade in the first two blade centers, 24GB per blade in the last two. All are diskless with boot from SAN from EMC Clarions with 4Gbps dual connections.

vRanger has resulted in data loss for us on more than one occasion thanks to redo logs created from failed snapshots and resource contention caused by vRanger hammering a blade by taking snapshots of multiple VMs at the same time. This also doesn't account for its infamous ability to create a bloated snapshot of the system (regardless of disk usage, it snaps the entire drive) and often failing to clean up the snapshot afterwards.

Fair warning when you restore a VM from vRanger, doing so changes the MAC of the NICs of that VM. So if you're like us and set static IPs via DHCP reservations, you will have to update them once you restore a VM from a vRanger backup. If it were not for the fact that the product was already purchased by someone else, we would have removed it from service. Honestly, given its history that may become true regardless.

Despite this, we found one positive use for vRanger and that is Physical to Virtual migrations. You can use it to take a backup of a physical system. That backup can then be "restored" as a VM with the hardware already reconfigured and fully functional as a VM. We have tested P2Ving NT 4, XP, 2000 and 2003 machines with success each time. It's proven faster than VMWare's Converter utility.
 
wait, vRanger doesnt' back up the VMX in a consistent state? Wow, didn't know that. :p It's even worse than I thought!
 
We were huge users of ESX Ranger in it's early incarnation back when we were running 2.5.2. After the move to VI3 we still used it. Before I left I was working on setting up VCB. Wish I had actually been able to set it up. Has it gotten better since it's first inception? That might be more rhetorical than anything, but I haven't had a chance to look at it since. Judging by all the comments, it sounds like it's the best way to go now. I only had to recover 1 or maybe 2 VM's using it and I never really had any issues with Ranger. Vizioncore's method was the 1-2 punch, I think it was called. Ranger > VCB. I do however, remember failed snapshots. What a pain in the ass that was.

This subforum is making me more and more want to pursue getting back into virtualization in general. I had so much fun learning the power of the tool. But alas, I found network security and that has been my new found desire and focus.
 
So I grilled the reps on this today during a face-to-face meet. They acknowledged that the "run-away" redo log is a known issue and that there's some shared blame between vRanger and VMware. According to them the most current version of vRanger is self-aware of the problem and will send out a notification when it occurs so that the admin can go in and fix the problem.

A new release scheduled for Jan 2009 (together with a 64 bit version) is supposedly going to correct the snapshot issue for good.

They also acknowledged that it's not a good idea to create a snapshot of a large VM (i.e. 2 TB, which is something a different user had by accident tried to do).

As a work-around to this issue snapshotting on the SAN level was suggested where it was pointed out that EqualLogic provides excellent application aware snapshot capability (at no extra charge).

Still, Dell signed an OEM agreement with Vizioncore, effectively pushing vRanger to all of Dell's new virtualization customers. The primary usage that was suggested today was VM imaging, were vRanger supposedly does an excellent job in only imaging used disk space rather than allocated disk space, and provides a simplified method to store, transfer, catalog, and restore backups (with the ability to restore individual files out of an image).

I think I may just try vRanger out and see how it does once I get the hardware. I am currently running Hyper-V, and I am not using snapshots at all. While I see potential uses for snapshots, I don't consider snapshots to be backups. So perhaps the issues with snapshots won't actually affect me since I won't be using snapshots on a regular basis.
 
No offense, but they're feeding you a line.

It sends no notification as of yet. I just had a case with it yesterday. 1.5TB drive that had filled from the redo log and no warning/notification was given. 3 deep nest of snaps. :) Latest version, and they lost data. It still doesn't clean up after a failure, and that's their problem, not vmwares - it's just a normal snap, and they should be committing it on any kind of failure no matter what.

Snapshotting on the san causes additional issues they didn't mention - namely ESX blocks access to those luns without a resignature, and a resig is a SIGNIFICANT downtime for your environment. You'll have to down ALL vms on that lun, un register, and then rereg after the operation is done. Bit annoying to try and restore one VM, isn't it?

VCB also only gets used disk space, even for linux and FreeBSD VMs (I use it regularly on my FreeNAS VM, with 5gb total disk but only 1gb used, and it only grabs the 1gb). Cloning/etc that we do also only gets the used part - they're probably using Vmware's tools for that, not their own. We can also do individual files - the main program of VCB, vcbmounter, has a file mode.

No offense intended, but every point they brought up is already a feature in VCB, and far less buggy too.

I don't know how it works on Hyper-V, but I guarantee that it's nothing but problems on ESX. Especially since VCB is free.
 
lopoetve said:
No offense intended, but every point they brought up is already a feature in VCB, and far less buggy too.

I don't know how it works on Hyper-V, but I guarantee that it's nothing but problems on ESX. Especially since VCB is free.
Click to expand...

Question: Does VCB work with ESXi? I recently got a 19 inch 1U rack server that I want to use with ESXi to breakup my FreeBSD machine into individual VMs and seperate out functionality. Would I be able to use VCB with ESXi for backup purposes?
 
auswipe said:
Question: Does VCB work with ESXi? I recently got a 19 inch 1U rack server that I want to use with ESXi to breakup my FreeBSD machine into individual VMs and seperate out functionality. Would I be able to use VCB with ESXi for backup purposes?
Click to expand...

absolutely. VCB installs on a windows system that talks to either the ESX host or the VC host :) It backs the VMs up to the windows system so you can copy them to tape / whatever afterwards.

edit: VCB is free if you have Virtual Center Foundation or higher. It's not available with the free ESXi standalone version. All the VC licenses come with VCB.
 
lopoetve said:
absolutely. VCB installs on a windows system that talks to either the ESX host or the VC host :) It backs the VMs up to the windows system so you can copy them to tape / whatever afterwards.

edit: VCB is free if you have Virtual Center Foundation or higher. It's not available with the free ESXi standalone version. All the VC licenses come with VCB.
Click to expand...

I think I should have specified the ESXi Free version. Sounds like VCB is not good to go with the free version of ESXi and I would just need to keep with my normal backup system for the individual VMs (dumpfs, Acronis, etc).
 
auswipe said:
I think I should have specified the ESXi Free version. Sounds like VCB is not good to go with the free version of ESXi and I would just need to keep with my normal backup system for the individual VMs (dumpfs, Acronis, etc).
Click to expand...

probably, yeah. Sorry :(
 
lopoetve said:
No offense, but they're feeding you a line.

It sends no notification as of yet. I just had a case with it yesterday. 1.5TB drive that had filled from the redo log and no warning/notification was given. 3 deep nest of snaps. :) Latest version, and they lost data. It still doesn't clean up after a failure, and that's their problem, not vmwares - it's just a normal snap, and they should be committing it on any kind of failure no matter what.
Click to expand...
Quoted for truth. We can template and snapshot all day, never had an issue.

lopoetve said:
Snapshotting on the san causes additional issues they didn't mention - namely ESX blocks access to those luns without a resignature, and a resig is a SIGNIFICANT downtime for your environment. You'll have to down ALL vms on that lun, un register, and then rereg after the operation is done. Bit annoying to try and restore one VM, isn't it?
Click to expand...
It also doesn't matter what version of ESX you use. We have had this problem occur on 2.5.2, 3.0, 3.5 and 3.6
 
lopoetve said:
Snapshotting on the san causes additional issues they didn't mention - namely ESX blocks access to those luns without a resignature, and a resig is a SIGNIFICANT downtime for your environment. You'll have to down ALL vms on that lun, un register, and then rereg after the operation is done. Bit annoying to try and restore one VM, isn't it?
Click to expand...

I followed up on this and here's what I was able to find out (second hand info!).
Apparently EqualLogic doesn't have this problem anymore since they introduced Auto Snapshot Manager / VMware Edition. It hooks directly into the VMware API, tells vCenter to essentially "stun" the VM(s) while the snapshot is taken. It seems like NetApp has some sort of similar system that you can buy at additional cost (while it is included in the EQL SAN price). Doesn't seem like other SAN vendors have caught up on that just yet.
 
Thuleman said:
I followed up on this and here's what I was able to find out (second hand info!).
Apparently EqualLogic doesn't have this problem anymore since they introduced Auto Snapshot Manager / VMware Edition. It hooks directly into the VMware API, tells vCenter to essentially "stun" the VM(s) while the snapshot is taken. It seems like NetApp has some sort of similar system that you can buy at additional cost (while it is included in the EQL SAN price). Doesn't seem like other SAN vendors have caught up on that just yet.
Click to expand...

That's not the problem I was describing :)

You snapshot a lun, that snapshot is 100% useless until you resignature the snapshot. Doing so may not be an insignificant procedure, depending on the status of the environment.

This is a LUN metadata issue, there's no way around it.
 
Keep in mind any app that uses VMware Snap shots i.e. VCB by its self, vRanger and vRanger using VCB. They all just use the VMware snap shots API provided.

In the cases of vRanger, I will say the cleanup process could be better. Since ESX 3.x VMware took over the commit process for snap shots, when a 3rd party app send the close command they take over and add a helper snap shot while the inner snap shot is closed.

Why would vRanger not send a close request or the request would fail? There are a few reasons
1. Admin powers off the host running vRanger in the middle (I have seen this)
2. Power outage and the vRanger host does not have a battery backup
3. Service console is get starved for resources
4, Admin closes the vRanger backup process in the middle of a backup

To shed some light on item 3, the VMware process called HostD is in charge of handling all APIs and Virtual Center admin command traffic. The service console is stuck on CPU 0 and is not allowed to move. The service console also has less resources then my iPhone. Its suggested to have the highest level of success with Snap shots to give the service console 1500 MHz and 800 MB RAM (by default it has 300 MHZ and 272 MB)

With vRanger one thing it does do, if the snap shot names vRanger is seen on the next backup cycle it will close it and start a new backup.

vRanger does grab the VM meta data or VMX in all cases. in Fact it will copy the VMX file at the time of backup to a temp name so that it does to change during a backup.

vRanger and VCB work together very well and its able to compress the VMDK's before they hit the disk and you have the option to perform image level differential's without staging to disk. Thus reducing your disk requirements needed for VCB.

When using VCB you remove all snap shot management from vRanger and it will only grab data given to vRanger by VCB, vRanger no longer control snap shots.
 
vRanger most certainly does not close the existing snap to take a new one. I can say this from MANY MANY experiences that it gladly just keeps nesting them, at least by default. VCB will refuse to do so unless overridden by editing the config.js file. :)

VCB and vRanger with VCB both use a different set of parameters to the snap API calls, so you do get slightly different results. vRanger also fails to close descriptor files sometimes, resulting in the file being lost.
 
The case you’re talking about was a Snap shot API issue, that VMware API went into a Loop and cause a large chain to occur.

If you perform a backup and after the snap shot is added, kill the backup, come back and perform a backup vRanger will close the open snap shot and start a new one.

VCB an vRanger both use the same API, you browse the MOB and see this.. i.e. http://<server>/mob will see the only API options you can submit over SOAP.

or read the VMware Docs on API
http://pubs.vmware.com/vi3/sdk/ReferenceGuide/vim.VirtualMachine.html#createSnapshot
 
vRanger.. ugh!!! I hated it. Everything just didn't seem to flow for me when I was using vRanger.

I personally went with esXpress and have been loving it ever since.
 
One of the issues which is faced by many is that whereas in the corporate world there is a system admin group, a virtualization group, a storage admin group, in many SMB shops all those functions are confined to one guy, THE guy.

The problem this presents is that while a team dedicated to one task has a lot more resources to troubleshoot things, the primary function of THE guy is to make decisions as to prevent trouble in the first place since he just doesn't have the time to deal with problems. (I am not saying that dedicated teams are not trying to prevent issues, but they have troubleshoot time built into their fiscal and time budget.)

Finding a product that is likely to work without much monkeying is the truly tricky part.
 
jmattox said:
The case you’re talking about was a Snap shot API issue, that VMware API went into a Loop and cause a large chain to occur.

If you perform a backup and after the snap shot is added, kill the backup, come back and perform a backup vRanger will close the open snap shot and start a new one.

VCB an vRanger both use the same API, you browse the MOB and see this.. i.e. http://<server>/mob will see the only API options you can submit over SOAP.

or read the VMware Docs on API
http://pubs.vmware.com/vi3/sdk/ReferenceGuide/vim.VirtualMachine.html#createSnapshot
Click to expand...

I'm well aware of the documents, thank you, and I'm telling you now that vRanger may claim to do that, but in reality and in practice it does not. Indeed, it simply nests further. I can't count the number of times I've seen this, and lots of data damage as well.
 
I was referring to the API being the same not the closing snap shot issue you’re talking about. When and why the Snap shot API's are sent are 100% on the 3rd party apps i.e. VCB or vRanger, I just want to be clear that vRanger does use the same API as VCB.

BTW, I just installed a build from the website killed a backup, came back and did another backup and vRanger did close the older snap shot and open a new one.
 
jmattox said:
I was referring to the API being the same not the closing snap shot issue you’re talking about. When and why the Snap shot API's are sent are 100% on the 3rd party apps i.e. VCB or vRanger, I just want to be clear that vRanger does use the same API as VCB.

BTW, I just installed a build from the website killed a backup, came back and did another backup and vRanger did close the older snap shot and open a new one.
Click to expand...

of course it does, but how they call the api and what they do to check status before calling is what makes a difference.

I'm glad it worked for you. For many of my customers, it did not, and many of them have lost data.

Simply comes down to this - why pay for something when there's a version out there you've already paid for with just as much, if not better, functionality?
 
My VAR recommended a product from Idealstor called iBac VIP. They had used Vranger before and were turned off by the complexity and cost of licensing. I have also heard of issues regarding support for VSS. This one is priced per host - not processor.

If interested, here is the link they sent us - http://www.idealstor.com/VIP.html
 
Well, I guess that I will go against the grain and add my positive experience with vRanger. I haven't had any problems with it, and to protect against possible nested snapshots I run a simple PowerGUI script that checks for any leftovers in the morning (which in the past year has not happened).

Good tip about increasing the service console resources ... I had maxed the memory but I'll add some CPU resources as well.
 
We have been using vRanger for over a year now and it has been very solid. We have regular BCP testing and we are always able to restore. We use the restore as feature a lot for testing. Also we use data domain device for storage and we couldn't be more pleased.
 
Have you checked out a backup/restore tool called SSVCBAgent it is provided by a company called STORServer and from the issues listed here, would be worth checking out.

you can find info about it at www.storserver.com
 
You must log in or register to reply here.
Back
Top