chyves pre-announcement

This is a pre-announcement for the chyves project.

chyves manages bhyve guests using ZFS, nmdm, virtio, cu and optionally netmap, tmux and grub2-bhyve through the Bourne shell. chyves is a bhyve front end manager. chyves follows the lead set by iocage by storing guest parameters as ZFS user properties. chyves is a direct code descendent of iohyve with history maintained from where it was split at version 0.7.5, commit 2ff5b50. A nearly complete code rewrite was started in April 2016 and as of this post, the rewrite is on-going with code being written/committed nearly daily.


Earlier this year I started using bhyve, actually I started using iohyve. I wanted to starting using bhyve but did not fully understand how it all worked. I did not know what all the knobs, flags, and how they interacted with the tools it depended on. I am a big-picture type of person and sometimes that means working backwards to figure out how something works. I needed to see it working and then I needed to work backwards to understand every detail. So I started using iohyve because it seemed to be the simplest of the bhyve managers. There also seemed to be some automation happening behind the scenes. By that I mean, there was far less configuration needed, many of the other bhyve front-end managers seemed to parse an input file to bhyve. I also started using iohyve because something about storing guest properties in ZFS user properties is incredibly appealing to me. James May once described a fizzing feeling on national UK television, I would say utilizing ZFS user properties is nearly the same for me.

However one day I entered the command “iohyve delete pfSense” to delete my retired gold base image that was getting replaced with a newer version. But then all my VMs starting with “pfSense” were deleted. I was livid, mostly at myself for not backing up the config on pfSense from the day before. I lost a few hours of work and had that looming sense of dread from potentially forgetting something in the recreated firewall config. I checked out the iohyve code and saw the problem. The delete function was loosely written and guests sharing the same base name would all be deleted. I suspect this was done to delete the child datasets, my guess is the -r flag used with zfs destroy was not fully understood.

This incident generated enough angst that I submitted my first ever Pull Request (PR). That was my first public submission of code of any kind, I felt a little proud actually; a historic moment in that personal-meatspace-milestone-achievement type of way. Over the next couple of weeks I intentionally tried to get iohyve to break and reveal bugs. I found quiet a few issues and submitted PRs to address them. I decided to fork my own project because the rate my code was being reviewed and ingested was too slow for the number of changes I wanted to implement. I also wanted to make some huge changes and had already met resistance for smaller changes. At any rate, Trent pointed out the project was release under the BSD Clause-2 License so I did not need his permission but he gave his “okay” anyways.

I am incredibly grateful to Trent for creating iohyve and to everyone who has contributed to iohyve as well.

What is to come:

Here are just a few things coming with chyves. Keep in mind, this vague list is code that has already been written/committed. There is more to come but until I write it, I am not announcing it.

End user features:

Internal changes:

Developer targeted changes:

Project changes:

chyves logo version 1

Community effort

So I just mentioned community effort but then am keeping the repo private until the initial release. That is a total contradiction I admit, my thought is I want a solid base before opening up the code. I have also been making frequent changes to the Global properties and do not want to be tracking another point with all these massive changes to the code.


Intended release time frame is mid-August 2016.


The project website has demonstrations at