Version 68 (modified by Jamie McClelland, 5 years ago) (diff)


This page documents the procedure for creating a new KVM guest on a mayfirst server. To decommission a server see this faq

Creating a new KVM guest

In these direcitons, the host (or <hostname>) refers to the name of the kvm host computer (e.g. negri, or bolivar, etc.). The guest (or <guestname>) refers to the name of the virtualized server you are creating. The examples use negri as the host and hay as the guest.

Initial steps

  • Pick an activist to name the server after. Find the wikipedia page (or a similar page) describing your activist.
  • Allocate an IP Address using this method.
  • Add a Host record in the May First/People Link -> -> DNS section of the control panel matching your server name with the IP you have allocated for it.
  • Make sure there is an open ticket for creating the new server. The ticket should be tagged with "new-server."
  • In your local puppet Create Manifest file
    • Copy an existing puppet node file, preferably one from the same host, naming it after your activist (pick either the first or last name of the activist, up to you) and replace all instances of the old guest name with your new guest name and change the namesake URL and description text and anything else (be sure that the onsite/rdiff-backup server is in the same colo center as the server you are creating) and replace the IP address in the nagios stanza with the correct IP address
  • Edit the puppet configuration file for the host server. Copy an existing m_kvm::guest stanza, replacing values as needed. The stanza will look something like this:
      m_kvm::guest {
          guest_nameservers => "",
          guest_ipaddress => "",     
          guest_netmask => ""
          guest_gateway => "",
          guest_ram => "2GB",
          guest_disksize => "50G",
  • commit changes to the puppet repo and git push to the host machine
    1. git pull --rebase origin master
    2. git push origin master
    3. git push <hostserver> master

While root on the host machine

  • Create a symlink to the ISO in the newly created user's home directory...
    ln -s /usr/local/share/ISOs/<guestname>.iso /home/<guestname>/vms/<guestname>/cd.iso
  • Start the new guest
    update-service --add /etc/sv/kvm/<guestname>
  • Remove the symlink to the ISO in the newly created user's home directory...
    rm /home/<guestname>/vms/<guestname>/cd.iso

While logged in as <guestname>@<host>

  • Enter the screen session:
    screen -x
  • Press enter to start the install. Confirm the disk format.
  • Afer installation:
    • ssh -t <guestname>@<host> screen -x
    • Login with root and no password (type 'root' at login prompt and hit enter).
  • The preseed file will leave all leftover space on the disk in a logical volume called "delete". You can remove this logical volume with:
    lvremove vg_<guestname>0/delete
  • Replace <guestname> with the name of the server,


lvremove vg_hay0/delete
  • If your server is not running MySQL, you may want to also delete the mysql partition (and edit /etc/fstab to remove the /var/lib/mysql entry)
  • To create one or more new volumes from the remaining free space
    lvcreate --size <size> -n <logical-volume-name> vg_<guestname>0
    lvcreate --size 80G -n home vg_goldman0
  • Edit fstab with the mount point(s) for the new logical volume(s)
    /dev/mapper/vg_<guestname>0-<logical-volume-name>  <mount point>  <type>  <options>  <dump>  <pass>
    /dev/mapper/vg_goldman0-home     /home     ext3     defaults,relatime,nosuid,nodev   0     2

You may need to create a file system for the new volume group.

mkfs.ext3 /dev/mapper/vg_<guestname>0-<logical-volume-name>
  • Mount the new logical volume(s). This will test the syntax of fstab to ensure successful mount(s) on the next reboot.
    mount <mount point>
    mount /home
  • Set the root password. If you run the keyringer pass command without any arguments, it will prompt you with a random password and store the password in keyringer. To set the root password on the guest do:
  • Check the ssh host fingerprint (for comparison during steps below)
    ssh-keygen -l -f /etc/ssh/

While in your puppet conf directory on your local machine

  • Setup a remote for the new server:
    freepuppet-helper gsr:<guestname>
  • Initialize the new server for puppet with:
    # make sure you get the key in your authorized keys file (see above for fingerprint)
    ssh root@<guestname>
    freepuppet-helper is:<guestname>
  • Push git repo to guest:
    freepuppet-helper gp:<guestname>
    • If you get errors during this process, which is likely--they show up in some attention grabbing color, purple for me--rerun the process with the following:
      freepuppet-helper pr:<guestname>
  • Sign host key:
    freepuppet-helper shgk:<guestname>
  • Sign root user key:
    freepuppet-helper srgk:<guestname>
  • Push changes to the nagios server and to each of the backup servers

NOTE: We have experienced errors with backup servers syncing. Please see ticket:5455#comment:3 if you see errors syncing backups. You also may need to run freepuppet-helper gsr:SERVER_NAME for this step, if you haven't set the remotes for these servers yet.

freepuppet-helper gp:jojobe
freepuppet-helper gp:<onsite-backup-server>
freepuppet-helper gp:<offsite-backup-server>

Restart the server!

MOSH servers

If you are installing a MOSH server:

  • Grant access to the Control panel database, from your local machine:
    freepuppet-helper rda:<guestname>
  • Add the server to the red_server table in the red/seso database. Setting accepting = 1 will enable it to show up in the drop down list for everyone:
  • NOTE: The command below may not work properly, in which case you should login to hay and run it from the mysql cli.
    ssh mysql -e "INSERT INTO red_server SET server = '<guestname>', accepting = 1" seso

You can toggle the value of accepting with the following sql statements:

UPDATE red_server SET accepting = 0 WHERE server = '<guestname>';
UPDATE red_server SET accepting = 1 WHERE server = '<guestname>';

Setting to "accepting = 0" in the above statement will remove the option to create new hosting order in the indicated guest server for members who have not previously created hosting orders within that server. However members who have previously created hosting orders in that guest can still create new ones there. To prevent any new hosting orders on the guest in question the following statement is needed.

UPDATE red_server SET closed = 1 WHERE server = '<guestname>';

Dedicated MOSH servers

Some groups request a dedicated virtual private servers. Unfortunately, you have to jump through a few hoops to get this done.

Usually, the reason for the request is because the user wants to run CiviCRM or otherwise wants PHP to perform more efficiently than is possible with suExec. These directions assume that's the purpose of the MOSH:

  • In the puppet configuration, specify the following in the m_mosh call:
     php => "mod_php",
     apache_user => "USERNAME",
     apache_group => "GROUPNAME",
    Here's an example of a real live config:
      class { "m_mosh":
        php => "mod_php",
        apache_user => "nybrecht",
        apache_group => "brechtforum",
        apache_max_clients => 40

Sadly, there's a chicken/egg problem. You can't know what the USERNAME and GROUPNAME will be until you've added a hosting order via the control panel. But, you can't add a hosting order via the control panel until you configured puppet. So, I suggest start by keeping the USERNAME/GROUPNAME place holders and tolerate puppet reporting an error (it will tell you that apache failed to start).

Next, create a hosting order for the requesting member in the control panel. If you specified "accepting = 1" in the steps above, the server should be available (and hopefully no other member has decided to put a hosting order there).

After you have created your hosting order, manually update the red_server table to change the accepting field to 0 so other members can't use it.

Then, in the control panel, click on Top and then click the Server Access tab. Create a new record specify the member requesting the server, the server that you have added, and the user account that, when they login to the control panel, should have full access to the server. This probably will be the user account that was created in the previous step but it doesn't have to be (if they have hosting orders on other servers).

Now, you can modify the puppet record for the server and replace the USERNAME and GROUPNAME with the user account that you created for the hosting order on this server. The username and groupname should be the same.