OS-6789

Did some playing with vmadm send/recv with a single dataset joyent brand zone, on the receiving side the cores dataset did not get created.

Brian Bennett commented on 2018-05-20T11:02:48.573-0400:

Workaround:

After vmadm recv run

zfs create -o quota=1000m -o compression=gzip -o mountpoint=/zones/:zone_uuid/cores zones/cores/:zone_uuid

Former user commented on 2024-01-04T19:14:57.675-0500 (edited 2024-01-11T22:06:20.499-0500):

After digging into this recently, I figured out what’s going on. During zone creation the zone attach process, handled by zoneadm, creates the cores dataset as part of the brand scripts. But a recv’d zone is already attached an attached state so the attach script doesn’t run.

A workaround for this would be after vmadm recv you can:

zoneadm -z $zone_uuid detach
zoneadm -z $zone_uuid attach

So then, the proper fix for this is that vmadm should detach and re-attach the zone after receiving. I had previously considered always detaching before a send, but this would break compatibility with vms sent using an earlier PI. It’s better to consider the in-transit format to be attached, and to always perform detach/attach after the receive is completed. This way, sending form an older PI and receiving on a newer PI will always work.

Former user commented on 2024-01-04T22:03:15.620-0500 (edited 2024-01-26T22:45:48.704-0500):

I’ve tested this by hot patching VM.js and then:

1. vmadm create

2. vmadm send > test.zone

3. vmadm destroy

4. vmadm recv < test.zone

5. vmadm list (verify zone exists and is running)

6. zfs list (verify cores dataset exists)

7. mount | grep cores (verify cores dataset is mounted

I did this with a joyent brand zone. Everything was successful.

KVM and BHYVE aren’t supported for send/recv, so tests do not need to be conducted.