It's more comparable to virtualenv with virtualenvwrapper. Also, it manages multiple versions of Ruby (AFAIK virtualenv was coupled to a single version of Python) and has a per-directory dotfile (that way, when I switch to ~/Projects/something rvm automatically switches to correct ruby and gemset).

It generally feels more 'complete' to me.

I didn't do any serious work with virtualenv in quite some time, so this may have changed.

virtualenv -p python2.5 will create a virtualenv with the Python 2.5 interpreter. I like the per-directory dotfile approach for autodetecting/activating a virtual ruby setup.

Virtualenvwrapper gives you per-VENV postactivate hooks that do the same thing.