Wednesday, February 10, 2016

SmartOS: how to clone a KVM machine

Get the disk0 filesystem of the VM to clone.

vmadm get uuid-originvm | json disks

    "path": "/dev/zvol/rdsk/zones/uuid-originvm-disk0",
    "boot": true,
    "model": "virtio",
    "media": "disk",
    "image_size": 10240,
    "image_uuid": "d8e65ea2-1f3e-11e5-8557-6b43e0a88b38",
    "zfs_filesystem": "zones/uuid-originvm-disk0",
    "zpool": "zones",
    "size": 10240,
    "compression": "off",
    "refreservation": 10240,
    "block_size": 8192

Take a snapshot

zfs snapshot zones/uuid-originvm-disk0@toclone

Create a json file in order to create the new VM.
vi targetvm.json
Please note: there are no disks.

  "alias": "targetvm",
  "hostname": "targetvm",
  "dns_domain": "",
  "brand": "kvm",
  "resolvers": [
  "ram": "2048",
  "vcpus": "2",
  "nics": [
      "nic_tag": "admin",
      "ip": "",
      "netmask": "",
      "gateway": "",
      "model": "virtio",
      "primary": true

vmadm create -f targetvm.json

Let's clone the filesystem of the origin VM.

zfs clone zones/uuid-originvm-disk0@toclone zones/uuid-targetvm-disk0

Create a json in order to add a disk to the new VM.
vi adddisk.json

   "add_disks": [
          "media": "disk",
          "model": "virtio",
          "boot": true,
          "nocreate": true,
          "size": 10240,
          "path": "/dev/zvol/rdsk/zones/435ca788-4935-ead3-f4e4-94e6eb7dd4b6-disk0"

Let's add the disk to the newly created VM.

vmadm stop uuid-targetvm -F

vmadm update uuid-targetvm -f adddisk.json

This is important.

zfs promote  zones/uuid-targetvm-disk0

From man zfs:

zfs promote clone-filesystem

    Promotes a clone file system to no longer be dependent on its "ori-
    gin" snapshot. This makes it possible to destroy  the  file  system
    that  the clone was created from. The clone parent-child dependency
    relationship is reversed, so that the origin file system becomes  a
    clone of the specified file system.

    The  snapshot  that  was cloned, and any snapshots previous to this
    snapshot, are now owned by the promoted clone. The space  they  use
    moves  from the origin file system to the promoted clone, so enough
    space must be available to  accommodate  these  snapshots.  No  new
    space  is  consumed  by this operation, but the space accounting is
    adjusted. The promoted clone must not have any conflicting snapshot
    names  of  its own. The rename subcommand can be used to rename any
    conflicting snapshots.