Chef Architecture for a Laptop Running Xen

Chef Infra (archive)
1

I would like to better manage my building of Debian 9.1 as dom0 for Xen Project hypervisor on a laptop with 500GB SSD and 16GB RAM.

This machine will be a workstation running multiple VMs for engineering, coding, and general purpose.

I have Xen up and running but have not had a successful VM created.

My biggest challenges are around networking. There is a built in wifi and a docking station Ethernet. While I often break Internet connectivity, lately I’ve been able to recover connectivity. Experimenting, I have broken this system unrecoverablly to my capabilities. So I have rebuilt it over 30 times. I have just learned about Chet, Puppet… So I am wondering how I might better manage the machine’s configuration.

I am wondering what are the architectural considerations on how to setup Chef. I have another laptop with Windows 10 that can be used (temporarily). My concerns are how functional Chef will be in keeping track of the host, keeping track of the VMs, being able to use config data to rebuild this same machine if necessary, the size of this foot print in dom0 for this laptop, and is it the right tools for configuration management of VMs.

I found there is a Chef-solo but it seems to have a large foot print (that’s only a guess).

Thank you in advance,
Ray

2

Ray,

We’ll start off covering the concerns you have:

"keeping track of the host"
This is the bread and butter of what config management does and Chef, similar to others embraces a notion of convergence (always move toward desired state) and idempotence (don’t do the same thing twice or unneeded work). Now this critically doesn’t mean it’s keep a diff of state each time (that’s not actually feasible or even useful) but that it will use the attributes and recipe logic to move toward the state you declare.

"keeping track of the VMs"
This one, from the host level, is no different than the above. You can have recipes ensure VMs are started or stopped but it’s important to remember that Chef is about declared state and moving toward it, less so one off actions though those are entirely possible as well.

"being able to use config data to rebuild this same machine if necessary"
This is squarely what any config management should do if leveraged properly. Mostly the same here as the first point.

"footprint"
This is incredibly relative to what you consider “large” - chef-client (which includes chef-solo, chef-client, knife) ~45MB for the installer and ~175MB on disk (/opt/chef).

"right tools for configuration management of VMs"
This again somewhat depends on what you want Chef to do in the course of managing VMs. Chef isn’t a VM management tool like Vagrant or Vmware et al though it can utilize any tooling inside a recipe. Chef is great for configuring bare metal, switches, VMs, or pretty much anything the client runs on so this is a broad question.

At this point in history chef-solo is just about indistinguishable from chef-client --local-mode, we keep the binary stub around for familiarity but you’re running pretty much the same chef-client codepath either way. The only difference being the normal chef-client operations presume a chef-server which is the distribution/storage mechanism for cookbooks, roles, and environments. Running via chef-solo/chef-client --local-mode means that it spins up a little in memory server so the client can do all the server operations without blowing up.

There aren’t really architectural considerations around running just the client, though there will be ones about running the chef-server as well as the design patterns you choose for cookbooks/recipes and the like. I encourage you to join us in Community Slack where folks can help you dive into the specifics a bit easier in realtime.

tl;dr Yes, Chef can help here

Cheers,