In Part 1 of this series on virtual private servers (VPS), we looked at the rationale behind going virtual. In this installment, we take you through some of the details involved in getting up and running.

As you might imagine, your VPS experience all starts with an account. Whichever service you want, you first establish an account. Some hosts may require a separate confirmation stage even after a credit card number is validated. This is clearly to prevent spammers, phishers, and crackers from setting up VPSes using a stolen (but not yet reported or discovered) credit card.

For example, Rackspace says it will call you to confirm within 15 minutes of setting up an account. However, in setting up two accounts, I wasn't called in either case. In the first, an emergency, I called after an hour or so, and stayed on the line for tens of minutes to get activated. In the second, a test setup for this article, I was never called (I let the account remain dormant).

With an account in place, you next set up an instance size. Most hosts have a menu of standard setups to choose from; a few let you pick more à la carte. Because of how virtualized host servers are set up, adding more memory or hard disk storage often comes at what seems like a ridiculously high price. That's because the change may prevent the company from offering a full additional server on the same machine.

As part of setting up an instance, you nearly always have to choose a Linux distribution to work with. Some VPS firms also offer Windows Server options, often at about 5 to 10 percent higher cost than a comparable Linux option. While every host varies in which Linux distros are supported, most include CentOS, Debian, Fedora, Red Hat, and Ubuntu. ArchLinux, Slackware, and others are available at particular hosts, and some are available only at certain data centers run by a given company. In some cases, you can choose between 32-bit and 64-bit virtual machines and operating systems, too. (I'm a CentOS convert after years of Red Hat. It was an easy transition. Yes, I know [your flavor of Linux/BSD here] is much better than CentOS, but I can use that distro without pain to do everything I want.)

The standard distribution image is loaded into the virtual machine, and your instance's installation becomes immediately persistent. The flip-side is that if you shut down an instance on any service but Amazon, you continue to pay for it at the hourly rate. You have to delete the instance to stop the hourly clock. Amazon doesn't charge for halted instances that were booted from persistent volumes. With some services, you can take a running or halted instance, write its image to a storage area (for which you pay a per GB/per month fee to use), and later restore from that image. (Amazon as the constant exception lets you boot from both non-persistent model images that you can customize, but which are erased when you shut them down, and persistent volumes that retain all charges. You can also boot from stock, non-persistent images, and specify a script which can mount separate persistent volumes.)

An instance includes a single publicly reachable IP address, but you can add more for a monthly fee. You usually only need an extra IP address if you're using an older version of Apache with SSL/TLS support. Private IPs can also be set up, and are generally free. These private IPs (as noted earlier) allow intra-instance communication within a single data center operated by a host at no additional cost. That's extremely useful when you're moving data back and forth quite a bit among your own operations.

In all the cases I've checked, instances launch with a firewall enabled, sometimes allowing just SSH remote access. Even SSH access might require using a more elaborate key-based authentication, as with Amazon, rather than just a user name and password. The most deeply rooted task you'll carry out is configuring the firewall at the command line to open up services for which you need remote access. (Amazon and some other firms have Web-based firewall configuration wizards, however.)

Most Linux distributions come with associated update services, such as yum with Fedora and CentOS, and apt with Debian and Ubuntu. Since some of my hardware servers dated back several years, and required tons of customization to get to work, I had rarely had the pleasure of automated updates. You can get used to it.

The only place I ran into trouble with my distribution setup was with SSL/TLS and Apache. The CentOS 5.5 distribution of Apache doesn't include SNI (Server Name Indication) support that allows shared used of the same IP address for multiple SSL/TLS Web servers. I had to roll up my sleeves and compile newer versions of openSSL and Apache. That solved the problem, but it does take a bit away for the joy of not needing to compile one's own software. I'm currently in a holding pattern on MySQL 5.5, which is generally available, but not yet part of the CentOS 5.5 updated distributions.

You can go so far as to install upgraded kernels or even swap out kernels altogether. That gets risky, however. VPS hosts typically only provide limited support for the logical machine you're running, and even then only for the standard distributions the provider offers. If you perform a kernel upgrade or OS sidegrade, and things go pear-shaped, you may have to revert to a previously saved image.

Once you've set a machine up to your liking, you almost always have the option to save an image: this is sometimes tied into a separately priced or on-demand backup system. A saved image is a precise clone of your server, and can be used at most hosts to launch new instances. The image can also usually be moved among data centers run by the same firm if you have a reason to switch, or to create redundancy.

With an instance up and running, what could possibly go wrong? Lots. But a well-run VPS host can do quite a bit right to offset potential problems.

Remote Hands through a Dashboard

The point of using a VPS is to be less concerned about hardware. And that has been the case for me and colleagues I've surveyed. But such anxiety reduction doesn't mean that all the hardware that hosts your VPS will work perfectly. Sometimes hardware fails. A good host will have reasonably large amount of redundant hardware on-site to replace hosts and drives as they inevitably fail. (For details on how providers set up their servers' drives, see the backup section, next.)

If a virtualization host fails, which happened to me just a few weeks after moving entirely to VPS hosting, the service provider moves or repoints the drive array, assuming it's undamaged; or migrates images by copying them to unreserved and unused space on other servers. In my case, my server was copied over and relaunched on a new host with a short interruption in service. The IP address and other characteristics naturally remained the same.

But if the hardware's fine, and you're having a virtual machine issue, you turn to the dashboard. Service providers offer a variety of dashboards, including widely supported open-source front-ends, in-house developed Web apps, and commercially licensed software. The basic dashboard shows you the health of a server, lets you control parameters (including upgrades), provides charts and other statistics about use, and offers access to recover, restore, and back up an instance.

The dashboard's remote access feature is key in a couple of circumstances. First, if you can't reach your instance, the ability to fire up a Web-based Java of AJAX terminal session to gain access directly through the host hardware is a powerful tool. This has let me figure out on a couple occasions that a routing issue is the problem, rather than the instance having gone bad. You can also use this Web-based access to fix network interface problems, if you've foolishly disabled an interface or set an adapter to an unreachable IP address. (Let me be the first to raise my hand here and say, "Hi, I'm Glenn, and I'm a foolish remote network adapter misconfigurer." "Hi, Glenn!")

You can also use remote access to figure out in how bad a shape your instance is in before taking the next step. In my examination of the services I've used directly and those surveyed in the chart, recovery comes in one of four forms. Some services combine these, or offer even more fine divisions among them.

Soft restart. Press a Web button to push a reboot to the virtual image that halts all processes and acts just like a soft restart on a physical machine. This is sometimes necessary if a machine becomes so bogged down or otherwise unreachable that you can't carry this out via an SSH session. I've had to use this when tuning Apache in recent weeks: we simply didn't have enough RAM allocated to a VPS, and Apache kept clogging. Being able to soft reset (or sometimes halt and restart Apache through the Web-based terminal) kept us sane. Hard restart. This option is used to simulate power cycling. The current image's memory is dropped, and the virtual machine reloads from its stored image. This can be fatal at times, depending on what was wrong, and journaled or other disk recovery may be necessary. Recovery. Some hosts, such as Linode, will let you boot an unmodified distribution identical to the one you're using and mount your damaged instance as a drive on the boot disk. You can then attempt to repair whatever problem was caused, or transfer data off if it seems unrecoverable as a bootable system. Restore. If all else fails, you can select a disk image backup you've created (see the backup section, next) to restore from, wiping out whatever changes were made in the interim in the interest of returning to a usable instance.

Consider each of these operations if you had to work with your own hardware stored at a colocation data center, or even in your own office. Each operation would require phone calls or the use of remote power-cycling devices. A recovery or restore from an image could take hours and a lot of hassle, including a need for separate hardware to help with recovery.

Our last stop in the VPS tour is with backups, which underlie how robust a VPS instance can be, and help you deal with other problems that may arise.