Using SUSE Cloud to setup a practice environment

In this article, I would like to give a brief description what should be considered if you want to setup a test environment in SUSE Cloud 5 for different users and/or tenants. The scenario could be something like this:

You have someone who wants to or needs to practice server installation and network administration. How do you enable that without putting your productive network into danger? A cloud, of course! You can create projects (also called tenants) for every purpose and grant access to them for specific users and let them practice network administration and everything else. These are the required steps to enable a practice environment:

  • Create a project
  • Create a user
  • Upload an image
  • Create/edit security group rules
  • Create a network
  • Run an instance!

These steps are described from the cloud admin perspective, a user guide how to create and manage instances can be found here.

Create tenant

To create projects and user accounts you have to be logged in as a user with admin rights. Create a new project in the Identity Panel in the Horizon Dashboard. Details on how to manage projects and users can be found here.

Create user

Create a user in the Identity Panel. Choose the previously created project as default project for that user.

Upload image

Either you upload an image exclusively for the practice project or – which is what I recommend – you upload it as a public image, so it will be available for all projects, but this depends on your requirements, of course.

Creating and uploading a bootable image can be the first barrier, especially if you need to work with /boot residing on a BTRFS-based file system (I had my share of trouble getting a SLES12-based image to boot up as an instance, whereas the same image booted nicely in a plain Xen enviroment). This is to blame on pygrub’s inability to boot from a btrfs file system, but that’s what Cloud 5 uses as the default boot loader on Xen-based compute nodes.
So there are different ways to enable that image. Either you modify an existing image with linux tools and create a /boot partition with ext3 or ext4 file system, the root partition can remain btrfs. Or you use a single file system for the installation, which should also be ext3 or ext4, of course.
Read this for details on how to convert VMware multipart images into a single raw image for xen.
In my case, when creating a new SLES12 VM via virt-manager, I decided on changing the file system type to ext4 for the single default partition.
If you already have an image with SLES12 installed you want to upload to the cloud, you would have to change the partitioning in the existing image to create a /boot partition based on ext3 or ext4.

Security groups and rules

Depending on the settings within your existing default security group, you may need to remember to add additional services or to provide a new group, created from scratch. Else your users may face the situation that some of the services provided on your new instances seem unreachable, although properly configured within the VM. By default, even typical services (SSH on TCP port 22, HTTP on 80 or HTTPS on 443) aren’t permitted by the Cloud.
Unfortunately, there is no current easy way to transfer security groups from one project to another, so you’ll have to create/edit the groups and rules for every project manually.

Create a network

One of the big advantages of Cloud computing is the ability for each project to set up seemingly identical networks, while still preserving independence between projects. So no matter if only for practice or for complex testbed scenarios, within each project you may set up identical network configurations, using the same IP addresses, without influencing other users.

Run an instance

After completing previous steps your users should be able to work in your SUSE Cloud 5, e.g. managing instances, networks, images etc.

This entry was posted in SUSE Cloud and tagged , , , , . Bookmark the permalink.

Leave a Reply