Ready to get started with creating Virtual Machine’s in SmartOS?

Not so fast, before we jump in and get started, its important to have a good understanding of some of the fundamental concepts surrounding how SmartOS works and the tools we use to manage the system. Ensuring that a solid understanding of the foundations of SmartOS is in place prior to creating vm’s will assist in making our SmartOS learning curve as short and enjoyable as possible.


Every Virtual Machine in SmartOS is in the form of a UUID, this includes both OS Virtual Machines (zones) and KVM Virtual Machines. The Universally Unique Identifier (UUID) is the ID of the VM and will be used to reference it for the rest of its lifecycle. A UUID is represented by 32 digits, displayed in 5 groups separated by hyphens. For example: one of my KVM FreeBSD vm’s running on SmartOS has the following UUID.


You may be wondering how on earth you are going to remember this long convoluted number, but rest assured there are other ways of identifying which Virtual Machine is which by assigning a friendly name or “Alias” or a “Hostname” to each. This UUID naming convention makes a lot of sense when you start managing thousands of VM’s. In SmartOS most commands you issue, operate on VMs by their UUID. In SmartOS UUID’s are supported with bash tab-completion so that you can tab-complete them out without having to type them out for each command.

VMADM – One tool to manage them all

I believe there is a lot of power in simplicity, and to me it seems that the same engineering influences that were at work to shape the “zfs” and the “zpool” commands, were the same influences that  brought simplicity to the creation and management of Virtual Machines under SmartOS.

This tool is called “vmadm”

In a nutshell, the vmadm tool allows you to interact with and manage virtual machines on a SmartOS system. We are not going to dive too deep into vmadm right now as we will be using it in a lot more detail when we actually get to the VM creation section, but suffice to say, if you want to start becoming a SmartOS Ninja, a good idea is to read the “manual” page for vmadm to get acquainted with the myriad options it supports. For now here is a simple “vmadm list” example: that shows some information on the Virtual Machines on my test system.

[root@00-15-17-ae-1f-d9 ~]# vmadm list -o uuid,type,ram,vcpus,nics.0.ip,state,alias

UUID                                 TYPE RAM VCPUS  NICS.0.IP  STATE   ALIAS
b05811a2-9909-4984-8fb8-33afc77e8991 OS   256  -  stopped mysmartos1
038484eb-17d5-49ad-9e05-4a70b544dd96 KVM  512  1  stopped fbsd9-master
2eb7e0f2-24e1-44b3-af75-0043e0527ca9 KVM  512  1  running plato
4fb96695-4cbe-4257-a194-343f0dc193bd KVM  512  1  stopped freebsd8.2
d152947b-f42a-40f5-9c1b-a1e1b99b0f0a KVM  512  1  running socrates
cb18400e-0df6-40a1-b6d8-f99d6f53e9b0 KVM 1024  1  running win2k3-master
f77b0731-1522-476b-8ff8-8078be995802 KVM 1024  1  stopped fbsd8.2-master

JSON – “No, he is not some dude you know!

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate.

SmartOS guests are defined in JSON. To create a vm in SmartOS we define the Virtual Machine properties in a JSON definition file in JSON format. We then pass this JSON file or payload to the “vmadm” tool to create our Virtual Machine. example:

[root@00-15-17-ae-1f-d9 ~]# vmadm create mynewvm.json
Successfully created c10e35b9-386c-4065-aec6-3167ee076d46

Below is the contents JSON file used to create the new KVM Virtual Machine.  example: mynewvm.json

"brand": "kvm",
"vcpus": 1,
"autoboot": false,
"ram": 512,
"hostname": "fbsd9.0-newvm",
"alias": "fbsd 9.0 newvm",
"resolvers": [
"disks": [
"boot": true,
"model": "ide",
"size": 40960
"nics": [
"nic_tag": "admin",
"model": "e1000",
"ip": "",
"netmask": "",
"gateway": "",
"primary": 1
] }

What I like to do is save a couple of different JSON template files on my desktop and use these files to quickly provision new virtual machines. I make basic changes to these saved JSON template files e.g (ip address, hostname, alias) and then use them to provision new Virtual Machines.

If you are like me and don’t like manually editing the JSON files as its easy to make an error by leaving out a comma or bracket, I suggest using a JSON gui based editor, which is a convenient and easy way of managing your JSON files and checks the syntax, preventing any errors. On my OSX macbook, I use a free program I found with the most unlikely name, “Jason”

Here a screenshot below of the sample “mynewvm.json” file in the editor.

NIC’s & Virtual NICS

As far as I can tell, on a SmartOS system the 1st network card configured when you first boot off the bootable SmartOS image gets tagged or configured as the management or  “admin” interface. The mac address of this interface becomes the SmartOS Server / Node hostname as shown below using the “dladm” command. In a large environment this interface should be used for management of your node, and you should probably setup an additional NIC’s for Virtual Machine traffic. In smaller test setups, its fine to run your Virtual Machine VNics over the “admin” physical nic interface

[root@00-15-17-ae-1f-d9 ~]# dladm show-phys -m
e1000g0 primary 0:15:17:ae:1f:d9 yes    e1000g0
e1000g1 primary 0:15:17:ae:1f:d8 no --

The configuration for this NIC is specified in a file: “/usbkey/config” ,  on my SmartOS box my file file looks as follows:




In my opinion one of the many benefits of SmartOS is the genius behind the design of a memory only Operating system, this means you can boot a SmartOS node image without any configuration, and as long as the admin interface gets an ip via DHCP you can manage the node. There is no configuration on the bootable image that is needed to run the virtual machines sitting in the “zones” pool. So if a new version of SmartOS is released you simply, power down the node vm’s, and reboot the server off a new SmartOS image and wallah, all back up and running. Think of the elegance and simplicity when you are running 10000 physical servers in a private cloud and booting the images via PXE boot.

Virtual Nics

On SmartOS every VM gets allocated its own VNIC (Virtual Nic) interface. You can see them listed for your vm’s in the running state with the following command:

[root@00-15-17-ae-1f-d9 ~]# dladm show-vnic

net0  e1000g0 0  b2:72:84:6f:50:78  fixed 0     2eb7e0f2-24e1-44b3-af75-0043e0527ca9
net0  e1000g0 0  b2:aa:ff:54:31:40  fixed 0     d152947b-f42a-40f5-9c1b-a1e1b99b0f0a
net0  e1000g0 0  b2:44:2a:a2:a6:3d  fixed 0     cb18400e-0df6-40a1-b6d8-f99d6f53e9b0

You will see from this that each VNIC is associated with a zone UUID, and they correspond with my 3 currently running Virtual Machines listed above shown via the “vmadm list” command in the “running state”.

We can confirm this by using the “vmadm get” command. This will return in JSON format the entire configuration for a specific Virtual machine. I have pasted below only the section pertinent to the VNIC. Please note the “nic_tag” corresponds to the admin interface, and the mac address corresponds to the output above shown with the “dladm show-vnic” command.

"alias": "plato",
"hostname": "plato",
"nics": [
"interface": "net0",
"mac": "b2:72:84:6f:50:78",
"nic_tag": "admin",
"ip": "",
"netmask": "",
"gateway": "",
"model": "e1000",
"primary": 1

Phew!, what a mouthful, we are almost done. One more thing that is very cool about SmartOS is that the ip and gateway settings configured in JSON can be extremely useful when we provision and run our Virtual Machines. The way it works is that a mini dhcp server instance is run locked to the zone the VM boots into, if you have your VM set for DHCP, when it boots it will be assigned via DHCP the ip specified in JSON above. This way you can provision a new VM and as long as you have specified ip settings in the JSON file you passed at VM creation time, your new VM will boot with a unique live ip without any additional configuration needed. Now thats pretty awesome! isn’t it?

Ok, we should now have a pretty good grasp of the fundamentals of SmartOS, in the next post we will start to provision both KVM and shared kernel, zone based virtual machines. We will cover deploying a cloned new virtual machine from the dataset of an existing VM and thereby consuming no additional disk space. We will cover making changes to vm’s like adding or removing Ram and CPU cores. We will also cover controlling VM resources and limits and a whole lot more….