Skip to content

Instantly share code, notes, and snippets.

@reiddraper
Created July 11, 2012 14:39
Show Gist options
  • Star 12 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
  • Save reiddraper/3090799 to your computer and use it in GitHub Desktop.
Save reiddraper/3090799 to your computer and use it in GitHub Desktop.

on the guest SmartOS VM

pkg_add http://pkgsrc.joyent.com/sdc6/2012Q1/i386/All/smtools
# note this is going to shut down the VM
sm-prepare-image

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
Copy link

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

@tonistiigi
Copy link

@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

@matthiasg
Copy link

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