You're correct that it takes a snapshot, it basically quieces the filesystem so that no more writes occur, all changes will be in redo/snapshot .vmdk. VCB will then mount up (filelevel) or just copy the .vmdk to your external storage, whatever that maybe. Once the copy has occured, it'll unfreeze the VM and the comit will occur to apply all changes back to the primary .vmdk. Since it's talking directly to the SAN depending if its FC / iSCSI, it goes pretty fast and huge changes hopefully won't be taking place during this period. You can setup schedules on when you want the backup to occur and that hopefully should allieviate some of the high load on the VMs during the snapshots. Also it's best practice to only do 1-2 backups on a given LUN so you don't impact other VMs, so you only concern is space on your external filer not on the SAN itself, especially if you follow the best practice of have only 1-2 active backup per LUN. It's always good to keep a good buffer of space on your LUNs, in case of snapshot creation and that number can be 10-20% free space of the LUN.
The snapshot is created when the command is initiate by the backup utility. Yes, you have to care about the space but remember that this process is fast so you don't need a lot of space on the datastore.