Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC 0012] Declarative virtual machines #12
Here is a proposition of a NixOS module to declaratively handle virtual machines.
Having started work on it quite a while ago (2017-02-25 acc. to my git history), I have something working that almost fits this RFC in a ~600 lines module file and a few additions of functions to the nixpkgs lib (for auto-generating the IPs, as they could be used elsewhere), so concerns like "this will be hard to implement" should not be too much of an issue :) (that's not saying I'd drop the support if things needed to change, I'm perfectly willing to rework it so that it fits the bill)
Hope this may help!
cc @Nadrieril, and thank you for review and harsh criticism whenever I did something wrong
Edit: Adding a link to the current state of the implementation: NixOS/nixpkgs@master...Ekleog:vms
changed the title from
[RFC 0012] Virtual machines
[RFC 0012] Declarative virtual machines
Apr 10, 2017
That's a really good point: we considered using
Now, abstracting also over containers would actually bring net value, by more or less merging the two modules together, and as they have different objectives (lightweight vs. heavyweight virtualization) it makes sense to have both.
However, I'm not sure the implementation could share much, exactly because the goals are different. I'll take the features described in the RFC and try to see how it could be merged with a
Besides, I just learned while writing this answer that imperative containers rely on the inner working of the containers module , so replacing the
Just to get an idea, I counted the lines of code in  that could be shared with
Obviously, this count is biased towards lower values: the current implementation does only the strict minimum and future additional features may be more factorizable than the current ones.
However, I think there is a wide enough gap between containers and VMs to make it maybe even harder to factor the two than to maintain a separate implementation for each. Do you see another place for factorization I missed?
Jumping to another subject while I'm at it: I brought this link to the ML .
From there two major points emerged.
First one, there are not enough tools to share code between different VM appliances. In my opinion, this one will be in a big part solved by
The second one was about the format for disk management and boot control. I will take elements back from . The basic requirement is that the host be able to control the guest's boot, mostly for upgrades and downgrades. This can be achieved in three ways:
There are drawbacks to all of these options:
Besides, options 1 and 2 would I think be made way easier by the presence of
As you will have understood, my current favorite is option 3, and after the coming of
Do you see another decision argument? Another scheme for handling upgrades and downgrades effectively? What would be your choice?
Hmm, you are right and this feature can be useful/needed (to take back the example you gave on IRC, for having multiple disks on multiple VMs for redundancy for openstack).
However, I think it is more important to have something agreed on on which we can later on build additional features, than trying to have something perfect from the beginning on -- the important point being that all features that are included in a RFC should have a very low probability of changing, as they will eventually enter a stable version and stable versions should be as backwards-compatible as possible.
So I think your point is a great one, and we should definitively investigate handling multiple disks, but maybe after the basics are agreed on? :)
Unless other people would want it right now, I'm putting this as an unresolved question for the time being. This way it will stay on the "future works" step after this RFC, so that choice of the correct interface doesn't slow down having a first working version.
Just throwing in my two cents concerning
I can't speak for others, but personally I've started just ignoring the existence of
Another data point from me: I had some bad experiences with
OK, so maybe I'm being biased, but it has been open for more than two months and has seen, as far as I can see, mostly positive support (with some propositions for refactoring that don't seem to have caught much traction).
Maybe it would be time to get to a final comments period (idea inspired from Rust's RFCs), where last comments could be raised and the decision would be announced after a given time if no game-changing comment turns up? (cc @zimbatm)
@Ekleog I am not sure what level of quality we are aiming for, but the "Use case" section would never ever be accepted under my watch in a project where I was in charge, because there is no substance. You should not take this personal, but your use case doesn't actually describe a use case; it just describes some qualities of a human (i.e. someone who cares about security). I didn't even read more of the proposal because of that.
Having said that, as long as you don't break anything pre existing, I am not against adding features, since such developments need to be used and refined over periods of years anyway. No first design is going to be great, unless someone has implemented the exact same thing already before, but given the ever changing technology space, that seems unlikely.
In short, my opinion is that we should basically go for a let's throw code at the wall system and see what sticks approach under the condition that the code is documented in the source code as well as in the manual with the understanding that it is always possible to create a new system based on whatever is learned. I.e., deprecation could happen at some time.
@0xABAB: Thanks for the comment!
For the “Use Case” section, given the summary section I don't really know how to make it more explicit that the described module is “like
I would like to see more in detail how the qemu VM gets passed to the VM. Potentially it could be a path so arbitrary VMs can be run, and leave the incremental NixOS updates for later.
Also one thing that comes to mind is, would it be possible to take the libvirt configuration options as an inspiration? My guess is that they already played the game of common denominator.
I have not looked at this RFC before because I have not had the need for it. There has been mostly positive feedback on the RFC and some negative on the underlying tool. I agree with an earlier comment that the motivation section may be improved by e.g. considering emulation. But that's just a minor improvement. Aside from that, I think we should proceed with this. As long as the new module has maintainers and does not break NixOS (it's just an addition) I see no reason of not including it.
Regarding the RFC process. As long as there has been a long enough period to give feedback, and there are no objections, I see no reason why it cannot be accepted. Not every maintainer/contributor needs to comment or approve although I suppose that is something for in #18. In any case, I'd say this has been long enough out here that it should go in. cc @zimbatm @domenkozar