This hashing method is a handmade construction, which, like almost all handmade constructions, is weak.
In this case, it commits the two cardinal sins of password hashing:
- The hashing function allows for parallel attacks.
- The hashing function is way too fast.
Here, if two users have the same password, then they end with the same hash. This means that if the attacker has a thousand password hashes to work with (e.g. he dumped the corresponding database table through some SQL injection), then he can hash a potential password and look up the hash value in the table: the attacker attacks 1000 passwords simultaneously, for roughly the same cost of attacking one. This is very bad. Salts are meant to avoid that, but this works only if each salt is used for one hashed password, not for all the hashed passwords on a given server.
As for speed: a basic PC will go through several millions of SHA-512 instances per second. Not many user-chosen passwords resist for a long time when the attacker can try millions per second...
@paj28's suggestion is somewhat better, however not as optimal as could be wished for. Using a hash of the username concatenated with a server-global value (but distinct from server to server) ensures some sort of worldwide uniqueness; however, if a user changes his password, then he will use the same "salt" (since this is on the same server, and the user did not switch names, just passwords). The attacker who could get the hashes of the old and the new password will still be able to attack both in parallel. This is better than the previous method, but still not perfect.
Also, the speed issue remains, and it is serious enough to warrant anathema on this proposal.
Read this answer to learn how password should be hashed, and what theoretical concepts are at work here. The short answer is: use bcrypt.