One of the biggest features in the recent OpenNebula 5.8 Edge release is, no doubt, the support for Linux containers (LXD) – which we already covered in our blog.

If you are tempted to give it a try, go ahead, it’s really simple! You can start in AWS with the common Ubuntu 18.04 image and the whole setup from start to finish won’t take you more than a matter of minutes.

The minimal recommended size is perhaps t2.medium.  Just give it at least 25GB disk space and allow access to the 9869 TCP where the WebUI is running.

Then it comes to the simple deployment for which you can download miniONE


grant execution permission to the tool

chmod u+x minione

and deploy the OpenNebula with pre-configured LXD environment just by running

sudo minione --lxd

When it’s done, you can follow the MiniONE guide try-out section to launch your first containers. “miniONE” prepares one image and template for you – Centos7 – KVM, but no worries about the name as it works also for LXD. Also, the virtual network is exactly the same – no differences at all. The scheduler just checks what available hosts (hypervisors) there are and decides what to launch. And as we run miniONE with the –lxd parameter, the LXD host will be configured.

Follow along step-by-step in the following screencast video:

  OpenNebula 5.8 – Install with LXD containers in minutes using miniONE

Feel free to check other images from the OpenNebula Marketplace, or you can also create an additional Marketplace with backend which contains plenty of upstream LXD containers.

Give it a shot, and share your feedback!

This post is about a simple tool called miniONE, which allows you to easily install OpenNebula on a single host from the freshly deployed system to the ready-to-use OpenNebula installation just by a single command.

Let’s say that you just want to check out how OpenNebula looks like when starting evaluation or you want to see if something particular is done in v5.6. This might be the case when you can use miniONE.

So, just get it:

$ wget

and run it:

$ sudo bash minione

At first, there needs to be some checks done. You can see all of them by running with –verbose.

$ sudo bash minione --verbose

### Checks & detection
Checking distribution and version [CentOS 7] OK
Checking cpu virtualization capabilities OK
Check free disk space OK
Using local interface [ens3] OK
Checking directories from previous installation OK
Checking user from previous installation OK
Checking sshd service is running OK
Checking bridge-utils are installed SKIP will try to install
Checking minionebr interface is not present OK
Check given VN is not routed OK
Checking SELinux OK
Checking for present ssh key SKIP
Generating ssh keypair in /root/.ssh/id_rsa OK
Checking presence of the market app: "CentOS 7 - KVM" OK

Mainly you need to run it on a supported system — Centos 7 and recently Ubuntus so far. Then, you need CPU capable to perform virtualization, some free space to allocate the images and virtual machines itself, etc.

It may happen that you hit some non critical check to fail

### Checks & detection
Checking directories from previous installation FAILED

But you might try to force it using -f.

$ sudo bash minione -f

### Checks & detection
Checking directories from previous installation IGNORED will be deleted

Once you get through that, you may start the installation.

### Main deployment steps:
Purge previous installation
Configure bridge minionebr with IP
Enable NAT over ens3
Using ssh public key /root/.ssh/
Install OpenNebula version 5.6

Do you agree? [yes/no]:

### Installation
Install bridge-utils OK
Creating bridge interface minionebr OK
Restarting network OK
Enabling ipv4 forward OK
Configuring nat using iptables OK
Saving iptables changes OK
Installing DNSMasq OK
Starting DNSMasq OK
Configuring repositories OK
Installing epel OK
Installing OpenNebula packages OK
Installing ruby gems OK
Installing OpenNebula node packages OK

### Configuration
Switching onegate endpoint in oned.conf OK
Switching scheduler interval to 10sec OK
Setting initial password for current user and oneadmin OK
Starting opennebula services OK
Checking OpenNebula is working OK
Disabling ssh from virtual network OK
Adding localhost ssh key to known_hosts OK
Testing ssh connection to localhost OK
Add ssh key to oneadmin user OK
Updating datastores, TM_MAD=qcow2, SHARED=yes OK
Creating host OK
Creating virtual network OK
Exporting [CentOS 7 – KVM] from marketplace to local datastore OK
Updating template OK

What is happening? Apart from the installation itself, which simply adds the repositories and installs the OpenNebula packages, some configuration changes must be done. Above all, the networking needs be prepared to somehow allow you to connect to the virtual machines later.

For that purpose the bridge interface is created with dedicated network segment and NAT is configured on the installing host. Also, DNS server (DNSMasq) is started for the virtual machines.

miniONE comes with default parameter values for most cases. See them all in the Help:

$ bash minione --help
-h --help                           List of supported arguments
--version [5.6]                     Specify OpenNebula version
-f --force                          Skip non-fatal validation errors
                                    (e.g., traces of existing inst.)
-v --verbose                        Be verbose
--yes                               Don't ask
--password [random generated]       Initial password for oneadmin
--ssh-pubkey [~/.ssh/]    User ssh public key
--bridge-interface [minionebr]      Bridge interface for private networking
--nat-interface [first net device]  Interface to configure for NAT
--vnet-address []       Virtual Network address
--vnet-netmask []      Virtual Network netmask
--vnet-gateway []       Virtual Network gateway (i.e. bridge IP)
--vnet-ar-ip-start []   Virtual Network AR start IP
--vnet-ar-ip-count [100]            Virtual Network AR size
--marketapp-name [CentOS 7 - KVM]   Name of Marketplace appliance to import
--vm-password [opennebula]          Root password for virtual machine 

Before the installation finishes, it also bootstraps the OpenNebula to be ready to use. At first it enables KVM hypervisor on localhost and downloads one appliance from the market place. So, once that is complete, you may easily login using the printed credentials:

### Report
OpenNebula 5.6 was installed
Sunstone (the webui) is runninng on:
Use following to login:
  user: oneadmin
  password: o6ARsMAdGe

And that’s it! It won’t take us to Mars, but it might be handy, nonetheless.

Do you operate a small Cloud infrastructure and need to optimise the centre occupancy? Then FaSS, a Fair Share Scheduler for OpenNebula (ONE), will address your issues!

FaSS is a product of the INDIGO-DataCloud project and has been developed to boost small Cloud infrastructures, like those used for scientific computing, which often operate in a saturated regime: a condition that constrains the free auto-scaling of applications. In those cases, tenants typically pay a priori for a fraction of the overall resources and are assigned a fixed quota accordingly. Nevertheless, they might want to be able to exceed their quota and to profit from additional resources temporarily left unused by other tenants. Within this business model, one definitely needs an advanced scheduling strategy.

What FaSS does is to satisfy resource requests according to an algorithm that prioritises tasks according to

  • an initial weight;
  • the historical resource usage of the project.
Software design

The software was designed to be as little intrusive as possible in the ONE code, and interacts with ONE exclusively through its XML-RPC interface. Additionally, the native ONE scheduler is preserved for matching requests to available resources.

FaSS is composed of five functional components: the Priority Manager (PM), a set of fair-share algorithms, Terminator, the XML-RPC interface and the database.

  • The PM is the main module. It periodically requests the list of pending Virtual Machines (VMs) to ONE and re-calculates the priorities in the queue by interacting with an algorithm module of choice.
  • The default algorithm in FaSS v 1 is Slurm’s MultiFactor.
  • Terminator runs asynchronously with respect to the PM. It is responsible for removing from the queue VMs in pending state for too long, as well as terminating, suspending or powering-off running VMs after a configurable Time-to-Live.
  • The XML-RPC server of FaSS intercepts the calls from the First-In-First-Out scheduler of ONE and sends back the reordered VMs queue.
  • FaSS database is InfluxDB. It stores the initial and recalculated VM priorities and some additional information for accounting purposes. No information already present in the ONE DB is duplicated in FaSS.

How can I install FaSS?

Please find the detailed instructions in GitHub.

The only prerequisites are:

  • To install ONE (versions above 5.4 operate with FaSS above v1.2, if you run a previous version of ONE you need FaSS v1.1 or before);
  • To install InfluxDB and create fassdb.

All the other requested packages are installed automatically with the rpm.

You can then install FaSS as root user:
$ cd /tmp/
$ git clone
$ cd one-fass
$ cd rpms
$ yum localinstall one-fass-service-v1.3-1.3.x86_64.rpm

The last step is to adjust the configuration file of the ONE scheduler, to allow it to point at the FaSS endpoint instead in:
ONE_XMLRPC = "http://localhost:2633/RPC2"
ONE_XMLRPC = "http://localhost:2637/RPC2"

Is it difficult to use?

Not at all! A detailed usage description can be found in GitHub.

  1. Edit the initial shares for every user:
    $ cd /tmp/one-fass/etc
    and edit the file:
  1. Start FaSS:
    systemctl start fass

Now FaSS is ready and working!

Additional features

There are few additional features that allow you to keep your Cloud infrastructure clean:

  • You can set your VMs to be dynamic and be terminated after a specific Time-to-Live instantiating with:
    $ onetemplate instantiate <yourtemplateid> --raw static_vm=0
  • Instead of terminating your VMs they can be powered-off, suspended or rebooted changing the action to be performed in:
What’s next?

We are implementing several new features in FaSS, for example the possibility of setting the Time-to-Live per user. We are also planning to test several new algorithms. So stay tuned!

Managing resource usage in private or community clouds where the provisioning model is not pay-per-use oriented is often complicated. Resources are available to end users seemingly for free which means that one of the main motivators for responsible resource usage — a monthly bill — is missing. This can eventually lead to a situation in which the pool of available resources is depleted and a large portion of existing allocations is underused, unused, or entirely forgotten. For a resource provider interested in offering fixed amount of resources to the largest possible number of users, this issue needs to be addressed. Read more

A year ago OpenNebula Systems published the VMware Cloud Reference Architecture, a blueprint to guide IT architects, consultants, administrators and field practitioners in the design and deployment of public and private clouds based on OpenNebula on top of VMware vCenter. This reference architecture is intended for organizations with existing VMware environments or expertise who want to limit changes to their underlying VMware infrastructure, but see benefits in a common provisioning layer via OpenNebula to control compute workloads and want to take a step toward liberating their stack from vendor lock-in.

Many things have changed since that document was published. This is a brief summary of what’s new and ready for you:

  • OpenNebula now allows to upload, clone and delete VMDK files.
  • VM importing workflow has been greatly improved through Sunstone, making it easier to import your existing workload into OpenNebula.
  • Resource pools defined in vCenter are supported by OpenNebula so available memory and CPU can be partitioned. When launching a VM from OpenNebula, a resource pool can be selected automatically or the user can choose one.
  • When a VM is instantiated from a VM Template, the datastore associated can be chosen. If DRS is enabled, then vCenter will pick the optimal Datastore to deploy the VM.
  • New disks can be hot-plugged and OpenNebula can be informed from erasing the VM disks if a shutdown or cancel operation is applied to a VM, so users won’t lose data accidentally.
  • Support for vCenter customization specifications, as a complementary alternative to contextualization.
  • Multi vCenter cluster can be now defined in a single VM Template definition.
  • Control how disks are managed in vCenter, through the KEEPS_DISKS_ON_DONE template variable which will help you to protect users data against accidental deletions.
  • Datastores in a Storage DRS can be used as individual datastores by OpenNebula.
  • A bandwidth limit per VM network interface can be applied. VM’s network usage information is now gathered from vCenter.
  • It’s possible to access the OneGate server from vCenter VMs since the onegate token is passed through to the VM.
  • And last but not least, cool features added to Sunstone: a smoother vCenter’s resource import, the Cloud View functionality has been extended, new tags for resources.

This blueprint has been created from the collective information and experiences from hundreds of users and cloud client engagements so your feedback is extremely valuable.

More features are continuously being added, OpenNebula is a project in constant evolution, so stay tuned and do not forget to send us your feedback!



Date and Time: Mon, October 24, 2016 2:00 PM – 5:00 PM

OpenNebula Barcelona User Group is a gathering of our users in Barcelona area to share best practices, discuss technical questions, network, and learn from each other and enjoy. Direct Link

Taking advantage of the Opennebula conference in Barcelona, its user group in collaboration with the Opennebula project and CSUC organizes a free open cloud session to introduce the project, share new local developments and use cases with the community and any people interested in Open Cloud topics (Free Registration).

Agenda: (Free Registration -> Register here and reserve your seat)

14:00 Welcome/Bienvenida/Benvinguda
14:05 Opennebula Project: Open Cloud in essence – Dr. Ruben Santiago Montero (Chief Technical Officer & Co-Founder)
14:30 Cloud Bursting and VMware: New Opennebula VCLOUD driver  – Jordi Guijarro (Cloud & Security Manager – CSUC)
14:50 Barcelona Users Group
15:00 ACB League use case – Joaquin Villanueva (Director of Media Technology)
15:20 UPC Research Lab (RDLAB) use case – Gabriel Verdejo (IT Manager)
15:40 University of Valencia use case – Israel Ribot (System Administrator)
16:00 Coffee & Networking
16:30 EOF

Free Registration -> Register here and reserve your seat

ONEBCN Team in collaboration with CSUC

DRBD backed storage is now integrated into OpenNebula with the new DRBD Manage addon.

DRBD provides transparent, real-time replication of block devices without the need for specialty hardware. DRBD Manage is an administrative tool which facilitates easy Logical Volume Management (LVM) and configuration files for multi-node DRBD clusters.

With the DRBD Manage driver, create each new image for your virtual infrastructure as a DRBD volume. Volumes intelligently balance the load on your storage nodes. Alternatively, assign volumes to the specific nodes that you want in use. This is a simple scale-out storage solution, supporting the capability to add new nodes to your storage cluster at any time. This, combined with the flexibility of LVM, allows DRBD to keep up with your ever-increasing storage requirements.

DRBD 9 and DRBD Manage allow transferring Images to Virtualization hosts via the DRBD Transport protocol. This allows images to be available nearly instantly on host nodes without requiring them to have storage space available.

Below is a diagram showing a simple OpenNebula cluster using the DRBD Manage Driver. This cluster has a Front End, two storage nodes, and a single virtualization host. The host has two images attached to it via DRBD Transport. Both images are deployed to double redundancy and are being replicated in real time across both storage nodes. This means that the failure of a single storage node will not disrupt IO on the host. All nodes have a local copy of DRBD Manage’s control volume.



  • Data redundancy
  • Automatic fail-overs if a storage node fails
  • Database and high I/O application compatible
  • Transfers images over the network with DRBD Transport
  • Quickly attaches images to VMs
  • Fast image clones

One of the steps when preparing an OpenNebula installation is the creation of Virtual Machine images for base Operating Systems or appliances. Some of these images can be downloaded from the marketplace but you may need an OS that is not in the marketplace or the images must be customized in some other way.

I’m going to describe an automated way to customize the base images provided by the Linux distributions using the software libguestfs.

The software libguestfs comes with tools to create and modify Virtual Machine images in a number of formats that qemu understands. Some of these utilities let us add or delete files inside the images or execute scripts using the image filesystem as root.

The first step is getting an image from the distribution web page. I usually get these images as they are very small and don’t have extra software. For this example we will use CentOS 7. Head to and download the image CentOS-7-x86_64-GenericCloud.qcow2c.

One of the customizations we have to do to this image is uninstall the cloud-init package that comes by default with that image and install OpenNebula context package. The easiest way to install extra packages that are not in a repository is to add them into a CDROM that will provided to the customization tool. So head to and download the latest context package.

To create the CDROM image we can use genisoimage. Remember to add a label so it’s easier to mount. Here we are going to use the label PACKAGES:

  • Copy the packages to a directory, for example packages
  • Execute genisoimage to create the iso that contains those files:
$ genisoimage -o packages.iso -R -J -V PACKAGES packages/

Now we need to prepare a script with the customizations to be done in the image. For example:


# Install opennebula context package
rpm -Uvh /mnt/one-context*rpm

# Remove cloud-init and NetworkManager
yum remove -y NetworkManager cloud-init

# Install growpart and upgrade util-linux, used for filesystem resizing
yum install -y epel-release --nogpgcheck
yum install -y cloud-utils-growpart --nogpgcheck
yum upgrade -y util-linux --nogpgcheck

# Install ruby for onegate tool
yum install -y ruby

Instead of modifying the original image downloaded we can use a feature of qcow2 image that is creating a new image that is based on another one. This way we keep the original image in case we are not happy with the modifications or we want to create another image with different customizations.

$ qemu-img create -f qcow2 -b CentOS-7-x86_64-GenericCloud.qcow2c centos.qcow2

Now all is prepared to customize the image. The command we are going to use is virt-customize. It can do a lot of modifications to the image but we are only going to do two. Execute the previous script and disable root password, just in case. The command is this one:

$ virt-customize -v --attach packages.iso --format qcow2 ---attach centos.qcow2 ---run -root-password disabled

It attaches two images, the iso image with the packages and the OS hard disk, executes that we previously created and disables root password.

After the command is run the image centos.qcow2 contains the modifications we did to the original image. Now we can convert it to any other format we need (for example vmdk) or to a full qcow2 image, that it, does not depend on any other one. Here are the commands to convert it to qcow2 (compatible with old qemu versions) and vmdk:

$ qemu-img convert -f qcow2 -O qcow2 -o compat=0.10 centos.qcow2 centos-final.qcow2
$ qemu-img convert -f qcow2 -O vmdk centos.qcow2 centos-final.vmdk

There are other customizations you can do, for example set a fixed password with --root-password password:r00tp4ssw0rd. You can also use virt-sparsify to discard the blocks that are not used by the filesystem. Check the libguestfs web page to learn about all the possibilities.

You can also take a look at the presentation I gave about this topic in the CentOS dojo held in Barcelona this year:

Today I’m writing about the steps I’ve followed when creating a KVM VyOS image for OpenNebula that accepts some contextualization variables.

I hope this post helps users to extend the contextualization support and create your own VyOS appliances and share them in the marketplace, e.g why don’t you try to follow these steps to create an image for Xen and VMWare?

The first part of the post will help you to create a KVM image using Sunstone, the second part explains how we can add contextualization to our VyOS image.

Let’s begin!

First part – Creating a VyOS KVM image

This is easy for most of the users, however I think it’s always good to show these steps to newcomers. These are only my recommendations, they’re not mandatory, I’m just letting you know what works for me.

  1. First, download the latest stable image for virtual 64 bits (or 32 bits) from VyOS adding the ISO as a virtio CDROM image (vd prefix).
  2. Let’s create a 2GB Hard Disk image. I use a persistent, empty, datablock to create a VirtIO HDD. Once the HDD is created, remember to change the TYPE from DATABLOCK to OS.VyOS_HDD
  3. Once we have an ISO image and a HDD it’s time to create a template. In my case I add a network interface so I can later configure VyOS using SSH. Using the wizard these are the most important parts I configure:
    • General -> Memory. We’ll need at least 256 MB RAM (512 MB recommended).
    • General -> Hypervisor. KVM in my example :-D
    • Graphics -> VNC.
    • Network. When creating a NIC I use the advanced options and select virtio for the NIC Model.
    • OS Booting. Arch -> x86_64
    • OS Booting 1st Boot -> CDROM. It’s quite important to ensure the VM will boot the CD first unless you want a “AMD64 – No bootable device error” error.
    • OS Booting 2nd Boot -> HD
  4. After our template is ready let’s instantiate it!. If everything works fine we’ll have access to the console using VNC.VyOS_VNC
  5. Vyos default username and password are both vyos. Once we’re in, we can install VyOS in our HDD image using the following command:
    install image
  6. The installation wizard will ask some questions:
    • VyOS image to a local hard drive. Would you like to continue? (Yes/No) [Yes]:
    • Partition (Auto/Parted/Skip) [Auto]:
      I found the following drivers on your system:
      vda 2097MB
      vdb 247MB
      Install the image on? [vda]:
    • This will destroy all data on /dev/vda.

      Continue? (Yes/No) [No]: Yes

    • How big of a root partition should I create? (1000MB – 2097MB) [2097]MB:

      Creating filesystem on /dev/vda1: OK

    • What would you like to name this image? [1.1.5]
    • I found the following configuration files:…
      Which one should I copy to vda? [/config/config.boot]:
    • Enter password for user ‘vyos’:
    • Which drive should GRUB modify the boot partition on? [vda]:
  7. Once the system is installed we can run the poweroff command:
  8. The HDD is ready so we only have to update our template removing the CDROM and selecting HD as the 1st Boot device in the OS Booting tab. Then we can instantiate the VyOS template again.
  9. In the second part I’ll use SSH to run some commands so I first enable a NIC and start the SSH service using the following VyOS commands. In my example I’m using the IP address.
    set interfaces ethernet eth0 address
    set service ssh
  10. Now we have a VyOS image with SSH and we’re ready to start with part two.

Second part – Adding the contextualization script

VyOS is a fork of the Vyatta Community Edition. Vyatta’s forum was full of useful information and it helped me to find answers to “where should I start to add contextualization?”. Unfortunately, when Brocade acquired Vyatta, the forum dissapeared, so I don’t know really who should receive credit for the info I gathered… I only can say thanks to Vyatta’s community and wishing the best for the new VyOS community.

All right. Let’s try to explain the magic.

If we add to VyOS a script called vyatta-postconfig-bootup.script, VyOS will run any command in that script, once VyOS is ready and the configuration has been loaded. In this script we try to mount the OpenNebula’s CDROM containing the script which will load the contextualization environment variables (please see the official OpenNebula’s documentation) to get a deeper understanding of contextualization. In any case, VyOS will launch the bash script afterwards.

The (it can be renamed, of course) uses the vyatta-cfg-cmd-wrapper command to encapsulate VyOS commands that will alter the configuration. The wrapper commands must be declared between a begin, a commit and, of course, an end. Using one of the OpenNebula’s contextualization scripts as a template, I’ve added VyOS command that will be executed if some context variables are ready (e.g the IP and MASK…). I think this script it’s quite easy to follow but don’t hesitate to send your doubts and feedback to add a FAQ to this post.

Hands on.

  1. We’ll need two bash scripts that I’ve uploaded to my Github account. You can clone the repo:
    git clone
    cd vyos-onecontext
  2. Now we’ll scp the files to our VyOS VM using the vyos username and the vyos password (unless you’ve changed it during the installation). My VyOS router is listening on the address.
    scp vyos@
    scp vyatta-postconfig-bootup.script vyos@
  3. Using SSH and sudo we’ll move the scripts to the right directories:VyOS_SSH
    ssh vyos@
    sudo mv /tmp/vyatta-postconfig-bootup.script /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script
    sudo mv /tmp/ /opt/vyatta/sbin/
  4. In order to use the contextualization, we must first remove SSH service and the ethernet address and any changes we’ve made to VyOS config:
    delete service ssh
    delete interfaces ethernet eth0
  5. We can edit the file /boot/grub/grub.cfg (sudo vi /boot/grub/grub.cfg) and delete the following lines:
    serial --unit=0 --speed=9600
    terminal_output --append serial
    echo -n Press ESC to enter the Grub menu...
    if sleep --verbose --interruptible 5 ; then
    terminal_input console serial
    menuentry "VyOS 1.1.5 linux (Serial console)" {
    linux /boot/1.1.5/vmlinuz boot=live quiet vyatta-union=/boot/1.1.5 console=tty0 console=ttyS0,9600
    initrd /boot/1.1.5/initrd.img
    menuentry "VyOS 1.1.5 linux (USB console)" {
    linux /boot/1.1.5/vmlinuz boot=live quiet vyatta-union=/boot/1.1.5 console=tty0 console=ttyUSB0,9600
    initrd /boot/1.1.5/initrd.img
    menuentry "Lost password change 1.1.5 (Serial console)" {
    linux /boot/1.1.5/vmlinuz boot=live quiet vyatta-union=/boot/1.1.5 selinux=0 console=tty0 console=ttyS0,9600 init=/opt/vyatta/sbin/standalone_root_pw_reset
    initrd /boot/1.1.5/initrd.img
    menuentry "Lost password change 1.1.5 (USB console)" {
    linux /boot/1.1.5/vmlinuz boot=live quiet vyatta-union=/boot/1.1.5 selinux=0 console=tty0 console=ttyUSB0,9600 init=/opt/vyatta/sbin/standalone_root_pw_reset
    initrd /boot/1.1.5/initrd.img

    Removing the console, will help us to avoid the following error-> INIT: Id “TO” respawing too fast: disabled for 5 minutes. Thanks to this post!

  6. Unless we’ve added a KVM serial port we can delete the console:
    delete system console
  7. Finally we can delete the bash history, commit and save the changes:
    > /home/vyos/.bash_history

Please remember: Once you reboot your image, the contextualization script will try to autoconfigure your VyOS router, however no changes are saved unless you explicitly use the save command. If you use the save command you should stop using the contextualization scripts to avoid clashes between your saved configuration and the one from context… so execute:

sudo cat /dev/null > /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script

Phew!. It’s been a long post and it’s hard to include all the information without boring you. I hope you have understood how you can use some scripts to add context to your own VyOS image. Soon I’ll post here some more information about VyOS but in the while you can start improving your VyOS images.



Hello dear fellows!

Today I’d like to remind you of hurrying up with sending your proposals for the OpenNebula Conf. July 15th will be your last chance to submit your talk and to join us as a speaker on December 2nd – 4th this year in Berlin. The scrimpers of you should also know that July 15th is the last day early bird tickets are on sale.

We already have some confirmed speakers, too. If you have a look at the event website, you can admire the abstracts of the talks of  Armin Deliomini (Runtastic) and Stefan Kooman ( Alberto Zuin ( LTD) will follow soon.

Now ain’t that some good news?