Skip to end of metadata
Go to start of metadata

How to use the vmadm command in the latest (Dec 13, 2011) release of SmartOS.

Listing VMs

Default fields + sort:

Same, but change the field order and add some more:

Same, but sort by ram in DESCENDING order then by CPU shares in ascending order:

Same but only list those with type=OS and ram=1* (1024 or 128 in this example):

Creating a new VM

alternatively, with the same file we could just use:

Getting a VMs properties

Lookup a VM by IP

same thing, but get an array of json as results:

Looking up all 128M VMs with an alias that starts with 'a' or 'b':

same thing, but json array output:

Updating a VM

Quota for OS VMs updates live without needing a restart:

Set the quota back and adjust the cpu_shares:

You can also do an update from JSON:

Add a NIC to a VM then remove it

First list the nics so you can see what we start with:

Then add a nic:

Show it's there (we'd need to reboot the VM to actually use it though):

change the IP:

list again:

Remove the new NIC:

Back where we started:

Add a disk to a VM then remove it

First list the disks so you can see what we start with:

Then add a disk:

Show it's there (we'd need to reboot the VM to actually use it though):

Remove the new disk:

Back where we started:

Add a CDROM

You can do the same thing with CD-ROMs:

Stopping a VM

before:

then:

after:

Starting a VM

(see above for before)

after:

Rebooting a VM

Deleting a VM

before:

delete, then list again:

Moving a VM Between Servers

experimental
vmadm send and vmadm receive are currently experimental, undocumented-in-the-manpage features. Use at your own risk. They'll be documented once they are considered production-ready.

Migrate a VM to a new server (10.0.1.4)

Verify VM was transferred to the new server

Remove VM from original server

If the migration fails, you may need to manually destroy the ZFS dataset for the zone on the destination machine before you can try sending the VM again. The below error is a symptom of this:

Check to see if the ZFS dataset exists on the destination, then remove if it exists

Preserving snapshots

If you want to keep the snapshots for a VM when migrating, you may find this process useful.
First move the zfs datasets to the new server, where @last-snapshot is the last snapshot you want to keep. Every snapshot before @last-snapshot will be migrated. You will need to repeat this step for every disk.

Then you need to send the VM's metadata and create the VM. The JSON command updates the metadata so that vmadm doesn't attempt to create the ZFS datasets.

Changing the Virtual Hardware of a KVM Zone

See also

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 04, 2013

    xin

    I failed to change the ip of the vm, which is the only nic of my vm.Although the ip is updated shown in the "vmadm get <uuid>", but the new ip can not be used.   
    Shall I reboot the vm? Or whether take reboot by fifo or vmadm or the vm console.

  2. Jul 04, 2013

    LS

    How do you vmadm update a zone's resolvers attribute?  Can't seem to find in the documentation how to update an array type.

    # vmadm update 1df8074b-661a-45e4-b590-f2ac4de2aeeb resolvers="192.168.1.1"
    UNCAUGHT EXCEPTION: a7e75f91 <a TypeError>
    EXCEPTION MESSAGE: Object 192.168.1.1 has no method 'join'
    FROM:
    buildZonecfgUpdate (/usr/vm/node_modules/VM.js:6519:61)
    exports.update.async.series.VM.load.log (/usr/vm/node_modules/VM.js:11368:20)
    async.series.results (/usr/node/0.8/node_modules/async.js:540:21)
    _asyncMap (/usr/node/0.8/node_modules/async.js:225:13)
    async.eachSeries.iterate (/usr/node/0.8/node_modules/async.js:126:13)
    async.eachSeries.sync (/usr/node/0.8/node_modules/async.js:141:29)
    _asyncMap (/usr/node/0.8/node_modules/async.js:227:17)
    async.series.results (/usr/node/0.8/node_modules/async.js:545:34)
    exports.update.async.series.log.error.err (/usr/vm/node_modules/VM.js:11362:17)
    /usr/vm/node_modules/VM.js:4285:17
    Object.oncomplete (fs.js:297:15)
    Abort (core dumped)
    
    1. Aug 19, 2013

      Hi LS:

      I used full JSON form to update resolvers and it said it was successful, but didn't actually work:

      vmadm update 1df8074b-661a-45e4-b590-f2ac4de2aeeb '{resolvers:["192.168.1.1"]}'
      

      Not sure what to do here since this leads the zone to overwrite resolv.conf on reboot.

      1. Oct 02, 2013

        Hey LS and Alain:

        I've been in that situation and eventually I decided to hack the resolvers into /etc/zones/<uuid>.xml to make it persistent.

        <attr name="resolvers" type="string" value="192.168.3.1,194.109.6.66,194.109.9.99"/>