Gandi Kitchen

Home > Hosting > How is a virtual machine set up?

How is a virtual machine set up?

Disclaimer

The setup process of a virtual machine on Gandi IaaS has changed but the new process is still considered unstable and the API calls may change in the near future. If you chose to play around this new mechanism to develop new ways to commission virtual machines, let us know! And keep in mind this is an early release of our provisioning tools, for which we cannot guarantee a stable interface yet.

The old method

Up until November 2013, each virtual machine (VM) created on Gandi IaaS platform was started from a copy of master disks and booted. The gandi-kernel service started at launch, downloaded the kernel module tree for the booted kernel and the gandi-config service - started as early as we could - was in charge of configuring and adjusting the system (like preparing the /etc/hosts file). Other scripts started by udev events were configuring the additional CPU, the additional virtual disk or the additional virtual interface by calling DHCP client. Once the VM was successfully booted, the Gandi backend was connecting to the Gandi agent on the VM and was configuring some element from customer input (creating the administrator user and changing the root access).

We needed to change this process

As per our previous announce, we enabled the VLAN feature on our IaaS hosting for all the customers. The next logical step is to allow the creation of VM without any public network interface. We still rely on the first boot of the VM for any particular configuration. And as some VM may not have access to public Internet or even our mirrors server, we had to pass the informations to the setup scripts during the boot. Our backend could no longer connect to each VM and set up the last step of the configuration process.

The new method

Our new configuration process is using the swap space. This space is created at each boot by our infrastructure and destroyed at each stop. We made some changes in the swap creation to fill the swap disk with a tar file structure containing a simple bootstrap script, a JSON containing specific information about the VM and the kernel module tree for the booted kernel.

Once the VM booted for the first time, a new service called gandi-bootstrap is started as early as possible and untar the data from the swap space. It triggers the simple bootstrap script which creates the administrator user, changes the root access, configures the first virtual interface in static mode. Then the same service installs the kernel module tree in the correct directory (either /lib/modules or /usr/lib/modules).

After the first regular boot with the new setup, your network configuration will be written in the regular configuration file of your system. In case of a Debian system, this will be - at least - /etc/network/interfaces.

The already existing gandi-config is still present and runs some configuration on the VM. It still reads /etc/{default,sysconfig}/gandi. But this configuration step is less complex and less long. The udev rules described in /etc/udev/rules.d/86-gandi.rules are still present. The activation of virtual CPU, additional disk(s) and additional virtual interface(s) (not eth0) is still supported live. The gandi-mount service is also still present. It starts during the beginning of the boot and re-triggers udev calls to attach any remaining virtual disk.

At the end, the gandi-postboot service runs a command that the customer had specified during the creation request (from the website or from the public API). The customer script could be a sequence of shell commands like:

  • wget -O /install https://mywebsite.tld/install && chmod +x /install && /install,
  • it could register the VM to a Puppet/Chef/Salt server,
  • any idea or need you can have!

The JSON configuration file in /gandi/config is present after the run of the 'gandi-bootstrap' service and contains many information about the VM. Your install script/program could easily read and parse the JSON. Here is a sample json configuration file:

{
    "nameservers": [
        "217.70.184.225",
        "217.70.184.226",
        "217.70.184.227"
    ],
    "vdi": [
        {
            "vdi_access": "read/write",
            "vdi_format": "ext4",
            "vdi_label": "testdisk11",
            "vdi_size": "10240"
        }
    ],
    "vif": [
        {
            "pna": [
                {
                    "pbn": {
                        "pbn_gateway": "92.243.31.254",
                        "pbn_network": "92.243.28.0/22"
                    },
                    "pna_address": "92.243.28.208"
                },
                {
                    "pbn": {
                        "pbn_gateway": "fe80::45",
                        "pbn_network": "2001:4b98:dc0:45::/64"
                    },
                    "pna_address": "2001:4b98:dc0:45:216:3eff:fe6c:4c40"
                }
            ],
            "vif_mac": "00:16:3e:6c:4c:40",
            "vif_number": 0
        }
    ],
    "vm_conf": {
        "ssh_key": "ssh-rsa AAAAB3uHyeruUQ== joe@bar",
        "password": "$6$hashofthepassword",
        "user": "kevin",
        "run": "wget -O /install https://mywebsite.tld/install && chmod +x install && /install",
    },
    "vm_hostname": "myvm",
    "vm_max_memory": 24576,
    "vm_memory": 1024
}

We never gave the ability to our customer to reconfigure their VM using our backend/agent configuration process. With this new setup process, the system reconfiguration could be enabled in VM start operation. We need to give the possibility to our customer by extending the API call.

The gandi-kernel service which started as a hack to ease the kernel migration when the VM rebooted is removed as the kernel module tree is already present in the swap space.

All virtual machines created on our 3 datacenters (Paris, Baltimore and Bissen) are using the new setup methods. All the existing virtual machines will not be impacted.

Benefits

As our backend does not need to connect to the fresh virtual machine to configure the system, the time of boot-to-usable to a new VM is lower than the previous method.

As a side effect we will soon enable a new feature: you will be able to choose the size of your main disk when creating your VM. The creation was previously forced to a 3 GB main disk.

Some other new features which should appear in a real near future:

  • creation of a virtual machine with only IPv6 networking and thus savings on the price of an IPv4,
  • creation of a virtual machine with only private networking in a defined Private VLAN.