From PrgmrWiki
Revision as of 22:11, 4 March 2016 by Paul (talk | contribs) (Background)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

See also Category:User Questions

Click here to add a question to this page

purpose of big_blank_file?

The backup script includes this:

dd if=/dev/zero of=/tmp/xvda1/big_blank_file

rm /tmp/xvda1/big_blank_file

So what is the purpose of this?


The dd utility copies the hard drive bit-by-bit as opposed to file-by-file. When you run dd if=/dev/zero of=/drive/blank.file it writes zeros to the partition until it fills up. When you the go to make a disk image you can compress it (due to the redundant nature of zeros) to at least the size of the data you had on it.

If you didn't do this all of your old files that you simply deleted would clog up your drive image. It wouldn't be unlikely if your 12GB partition with just 2GB of data on it needed an image 10GB in size.

Determining monthly usage statistics

How does one determine their average monthly resource usage (e.g. monthly network I/O, typical and max RAM usage, CPU usage, etc.)?

This info would be helpful to determine how well one is utilizing their VPS slice, for tuning purposes, and whether or not more/fewer resources are needed.

One can use 'df -h' from the shell to get disk usage info.

SSH Login Clarification for New Users

There are a few minor details related to SSH login procedures that may help users who are new to and/or Xen. I would like to share those details with you. There is a TL;DR at the bottom.


There are two layers to the service provides. You can log in to either layer and this could be a point of confusion for new users. There is a control layer and there is, of course, the virtual instance layer. I'll explain those layers in more detail as well as how to log in to each. Most importantly, I will explain the functions of each layer so you can understand why and when you might want to log into either layer.

The reason you signed up for an account with is to have access to your own (virtual) computing resources. You get most of the advantages of a colocated box in your data center at a much cheaper price, with greater convenience, and with the significant advantages of virtualization. But the relevant point for this article is that you want access to your own virtual instance -- and I want to make it clear how to log into that instance.

Let's clarify a few terms. A virtual instance can go by several names in the documentation on Xen. These include virtual private server, VPS, guest (or guest OS), "your domain", "your console", and domU. Sometimes the docs even refer to your domU by your account name. For the sake of this discussion, all these terms refer to the same layer -- the layer that holds your virtual computing resources.

The other layer I referred to -- the control layer -- is known in various documentation as the host or dom0. (It is also loosely the layer that provides the grid or cloud computing infrastructure.) Technically, dom0 is what controls the other domU's (virtual private servers) on the same physical server.

In other virtualization systems such as VMware, VirtualBox, Amazon EC2, etc., you will find similar layers. The AWS Management Console is an example of a control layer. A single EC2 instance is an example of a virtual private server (domU in Xen).

Account Setup

Account setup details are covered fairly well in other documentation. I'll assume you can generate an SSH key pair. After you request a virtual private server from you will receive an email with the info similar to the following:

"you ordered a xen vps, 256MiB ram,6GiB disk, 40 GiB transfer Xen VPS, username YOURACCOUNT

"Before can set you up, I need to know what distro you would like and an OpenSSH format public key (on a *NIX, run ssh-keygen and send me either the or file in an attachment)"

After you provide that info, you'll receive a response similar to this:

"Your vps is setup now, your host server is Login with your username and ssh key and follow the instructions at The default root password for the vps is password. Thanks very much."

Note that YOURSERVER is the name of a physical machine (a host) that runs Xen and a number of virtual private servers. This name does not refer to your virtual private server. It is just the name of the box in's colocation center where your virtual private server will live.

Logging In Via dom0

As mentioned above, the login instructions can be found here at Quickstart. However, this document provides more of an overview -- specifically, more info about what you are logging in to (given that there are at least two choices/layers, as explained above).

You can log in to either dom0 (the control layer) or domU (your virtual private server). However, when you are first getting started, you must log in to dom0 directly. And once there, you can log into your domU indirectly -- and that might cause some initial confusion.

Initially, there is no way to log in to the domU (guest) remotely at all, as disables root login via ssh by default (which is good).

You have to do a few simple admin tasks on your domU before you or your users can log into it directly. Once your domU is set up, you will work with it directly as you would with any other virtual private server, and you will use the dom0 menu infrequently for control functions.

Chapter 7, Hosting_Untrusted_Users_Under_Xen:_Lessons_from_the_Trenches has some interesting details about the relationship between dom0 and domU and the rights you have in each layer. I will not repeat those details here -- I'll stick to what is relevant to this discussion. Plus, that discussion is a bit dated and (I'm told) the implementation details at are different from those discussed in Chapter 7.

The Quickstart documentation does a good job of explaining how to log in. It does not explain well, in my opinion, that you are logging in to dom0! Even though the menu shows the name of your domU (your account name), this merely indicates that the menu shown gives you control over that domU. You are not yet logged in to that domU. You are in a restricted account on the dom0. The details are explained in Chapter 7. Here, I only want to stick to the relevant points for someone getting started.

To log in to this control menu (running on dom0, controlling your domU), use a command similar to this:

$ ssh -i id_rsa

From there, you can enter 1 to bring up a console for your domU (and press the return key at least once... usually more).

Initially, to log in to your domU, you log in as root using password "password". As the Quickstart explains, this is safe because allowRootLogin in sshd config is set to no. But you should still immediately change the root password.

Using these steps you have logged into your domU, but you did it through the control menu running at the dom0 layer. This is necessary for initial setup and it is fine in many admin situtations, but it is probably not how you normally want to SSH into your vps (domU, your domain). That's a critical point that I think is overlooked in the Quickstart.

The dom0-hosted console is really only meant for initial setup and for emergencies where the user has messed up the firewall or networking to the point where they can't log in directly to the domU.

Logging In Via domU -- Your Domain

You can log into your virtual private server directly. There are two key points that the other documentation doesn't seem to explain. First, you log in to a different address. Second, you have to manually add users (no surprise).

Even though you have what appears to be a user named YOURACCOUNT (also referred to confusingly as your "username" in the order confirmation email from, this is not a user account on your new virtual private server (domU) -- at least not unless you manually set it up to be later.

The only user present initially is root. But you cannot log in directly as root. Therefore, you cannot log into your virtual private server directly until you take care of the two steps mentioned above: create user accounts and then SSH into the correct address.

To add a user, here's one way that works on Debian/Ubuntu:

adduser <username>

If you want that user to be able to sudo, follow up the above command with this one:

adduser <username> sudo

In CentOS/Fedora, you would use:

useradd <username>

and for root access, you would do:

usermod -a -G wheel <username>

You'll need to create an authorized_keys file in ~/.ssh/ of course. In brief, here's one way to do it:

remote$ cat ~/ >> ~/.ssh/authorized_keys

Now you can log in to your domU using your new user account. Here's an example SSH command. Note the all important different in the URL compared to the dom0 example. Not knowing this caused me quite a bit of confusion initially.

$ ssh -i id_rsa

Where NEWUSER is an account you previously created using adduser NEWUSER at the command prompt (explained above).

The welcome email from informs you that, "your host server is" It neglects (as of this date) to also inform you that Your vps (domU) also has the hostname

You can also log in to your domU/vps directly using your IP address (no surprise there). Here's an example:

$ ssh -i id_rsa NEWUSER@

Here's how I obtained the IP address of my domU running Ubuntu. (There are better ways, but I wanted lynx anyway.)

From the console in your domU, run these two commands:

sudo apt-get install lynx


Summary (TL;DR)

Log in to the control menu:

$ ssh -i id_rsa

Note that YOURSERVER is the name of a physical machine. This name was given to you in the welcome email from YOURACCOUNT is your username but it is not a user account on your virtual private server.

Log in as root (only possible through the dom0 control menu):

username: root

password: password

Log in to your domU/virtual private server:

$ ssh -i id_rsa

Note that NEWUSER is a new user account you previously created on your domU/vps and YOURACCOUNT is your username (not a user account on your domU).

Compare the URL's:

ssh <-- log in to dom0, get access to out of band console for domU

ssh <-- log in directly to your domU (vps/guest)

I wonder

if bots will exercise the "add question" link ...

Is there a way to forcibly disconnect a dead connection to Dom0?

If I ssh into Dom0 and the connection dies (e.g., if my laptop kernel panics), sometimes the dead connection will just linger there and I can no longer connect to the out of band console. Other than a reboot, is there a way to somehow kill that dead connection?