Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?

on the guest SmartOS VM

# note this is going to shut down the VM

on the global zone

# b996c578-c4fc-46ef-81cc-d2eb3489ebc6 is the UUID
# of the zone I want to snapshot and clone. `uuid`
# returns a new UUID.
zfs snapshot zones/b996c578-c4fc-46ef-81cc-d2eb3489ebc6@`uuid`

# we can see the snapshot we made
zfs list -t snapshot

# create a new UUID for the clone
export CLONE_UUID=`uuid`

# clone!

# the UUID after the `@` is the UUID for from our snapshot version
zfs send zones/b996c578-c4fc-46ef-81cc-d2eb3489ebc6@81e67092-cb63-11e1-b0f3-fbc4021003b3 | zfs recv zones/$CLONE_UUID

# now you should be able to use $CLONE_UUID as a "dataset_uuid" in a VM json spec.

Getting ssh access again

After stopping and running the prepare script on my machine, I was unable to log in via ssh again. I saw this ssh error:

Unable to negotiate a key exchange method

I fixed this by zlogin'ing back into the machine and running the following:

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
svcadm restart ssh

pgte commented Aug 14, 2013

Hi, I'm trying to recreate these steps, but I'm having some difficulty.
I'm using the latest SmartoOS distro, don't know if you can help me:

If I set the dataset_uuid attribute on the manifest.json file with the $CLONE_ID value, vmadm create complaints that that value is invalid.

Also, I tried putting the zfs id in the zfs_filesystem attribute on the manifest, but that didn't work.

Any clues?

[root@00-0c-29-aa-24-ba ~]# uname -a
SunOS 00-0c-29-aa-24-ba 5.11 joyent_20130629T040542Z i86pc i386 i86pc

@pgte This should be because the new image was not imported with imgadm. Look at /var/imgadm/images. Make a copy of a json file already there, rename it with your UUID and replace (at least) the UUID inside the file. Now it should work in vmadm. Think you can also do it with imgadm import but then you would need to export to a tarball before.

I don't have any idea if this is the correct way. Its just how I have done it.

also, theres no need for send+receive if you use the same machine. Just use zfs clone

i am not a big fan of running sm-prepare-image in the machine to clone beforehand, since it alters the machine state before cloning. a clone of a running machine should clone as is (meaning it would be similar to a hard shutoff), a clone of a stopped machine would be more benign of course. and the cloned machine should remain unaware of the cloning process.

so if sm-prepare-image is really required i would assume you could do it twice, first clone and import without, then run sm-prepare-image in the clone and start over ? why is prepare image required ? cant it be done via zfs directly (e.g. deleting files in the clone before importing it as a vm from the GZ as in /zones/clone-uuid/root/ ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment