How to print ZFS filesystems ordered by space used

How to print ZFS filesystems ordered by space used

zfs get -o value,name -Hp used|sort -n

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": "mydomain.it",

  "brand": "kvm",

  "resolvers": [

    "192.168.0.2"

  ],

  "ram": "2048",

  "vcpus": "2",

  "nics": [

    {

      "nic_tag": "admin",

      "ip": "192.168.0.201",

      "netmask": "255.255.255.0",

      "gateway": "192.168.0.1",

      "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.

SmartOS: move (migrate) a VM to another Global Zone

To move a running virtual machine, either a zone or a KVM, from an hypervisor (Global Zone) to another, I usually follow these steps in an handicraft way.

In order to minimize downtime, there are 2 steps.
The first snapshot and transfer of the ZFS filesystem will be done without halting the VM.
In the second step we will shutdown the VM, take another snapshot, then we will send it using an incremental transfer, that is very fast.

First of all you need the UUID of the VM you want to move from a global zone to another GZ.

[root@gz1 /]#vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
561b686e-3119-4ab0-932e-20fc944fb001  KVM   512      running           vm1
e44f3c76-4acb-11e3-a536-a7cfa8b66838  OS    512      running           vm2
b803b5b9-bc86-4d0f-b450-16862e7bd7ed  OS    2048     running           vm3


Now we need the list of all the ZFS filesystem related to that VM.

[root@gz1 ~]# zfs list -o name | grep 561b686e-3119-4ab0-932e-20fc944fb001

zones/561b686e-3119-4ab0-932e-20fc944fb001
zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0
zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1
zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

Now we must create a snapshot of every ZFS.
Note: at this time the VM doesn't need to be stopped, you can leave it up and running, just to minimize downtime.

[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend
[root@gz1 ~]# zfs snapshot zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend

Now it is time to send these snapshots to the destination. It may require a lot of time.

[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0[root@gz1 ~]# zfs send zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend | ssh gz2.domain zfs receive -v zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1
[root@gz1 ~]# zfs send zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend | ssh gz2.domain zfs receive -v zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

After that, we have to stop the virtual machine.

[root@gz1 ~]# vmadm stop 561b686e-3119-4ab0-932e-20fc944fb001

And get additional snapshots of the ZFS filesystems, like before, giving them a different name. Now, these snapshots are potentially in a consistent state, since the operating system inside the virtual machine is not running.

[root@gz1 ~]# zfs snapshot zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend-last 
[root@gz1 ~]# zfs snapshot zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last


Finally, we have to send these ZFS snapshots using incremental send. It will take a little bit of time.

[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001
[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001-disk0
[root@gz1 ~]# zfs send -i zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1@tosend-last | ssh gz2.domain zfs receive -Fv zones/561b686e-3119-4ab0-932e-20fc944fb001-disk1

[root@gz1 ~]# zfs send -i zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend zones/cores/561b686e-3119-4ab0-932e-20fc944fb001@tosend-last | ssh gz2.domain zfs receive -v zones/cores/561b686e-3119-4ab0-932e-20fc944fb001

Some last operations.
Grab the line related to the VM from inside the /etc/zones/index in the source global zone, and paste it at the end of same file in the destination global zone.

[root@gz1 ~]# cat /etc/zones/index | grep 561b686e-3119-4ab0-932e-20fc944fb001


[root@gz2 ~]# echo "561b686e-3119-4ab0-932e-20fc944fb001:installed:/zones/561b686e-3119-4ab0-932e-20fc944fb001:561b686e-3119-4ab0-932e-20fc944fb001" >> /etc/zones/index

Finally, copy the xml configuration file from the source global zone, to the destination one.


[root@gz1 ~]#scp /etc/zones/561b686e-3119-4ab0-932e-20fc944fb001.xml gz2.domain:/etc/zones/561b686e-3119-4ab0-932e-20fc944fb001.xml 

At this point, you can boot the VM on the destination global zone, check if all is working as expected, then delete the old VM from the source global zone.

mass destroy zfs snapshots

Please pay attention...

zfs list -t snapshot|awk '{print $1}' > /tmp/zfstodestroy

Edit the file to delete the snapshots you don't want to delete!
Then:

while read uuid; do zfs destroy $uuid; done < <(cat /tmp/zfstodestroy)

ENOSPC, open '/zones...metadata.json'

SmartOS.

Issuing this command

vmadm update f7c4fbb0-aa35-41d4-9d21-614caba785c7 max_physical_memory=2048

I got an error like

ENOSPC, open '/zones/f7c4fbb0-aa35-41d4-9d21-614caba785c7/config/metadata.json'


I try to enter in the zone

zlogin f7c4fbb0-aa35-41d4-9d21-614caba785c7

but I got

[Connected to zone 'f7c4fbb0-aa35-41d4-9d21-614caba785c7' pts/12]
No utmpx entry. You must exec "login" from the lowest level "shell".

[Connection to zone 'f7c4fbb0-aa35-41d4-9d21-614caba785c7' pts/12 closed]


WTF?

The zone reached the zfs disk quota. Disk full.

But also
vmadm update f7c4fbb0-aa35-41d4-9d21-614caba785c7 quota=50
returns
ENOSPC, open '/zones/f7c4fbb0-aa35-41d4-9d21-614caba785c7/config/metadata.json'


So the solution is simple:

zfs set quota=40G zones/f7c4fbb0-aa35-41d4-9d21-614caba785c7

vmadm update f7c4fbb0-aa35-41d4-9d21-614caba785c7 max_physical_memory=2048
Successfully updated VM f7c4fbb0-aa35-41d4-9d21-614caba785c7