search

firecracker-microvm / firectl

firectl is a command-line tool to run Firecracker microVMs
Apache License 2.0
472 stars 73 forks source link

libvirt provider: firectl #52

Open taqtiqa-mark opened 4 years ago

taqtiqa-mark commented 4 years ago

This question arose after reading issue #20:

If I understand firectl correctly it appears that firectl is more natural fit as a libvirt provider. Some benefit would come from that: Such as immediately being available to the world of applications using libvirt, one such sizeable group are Vagrant developers via the Vagrant libvirt provider.

Has libvirt been considered and rejected?

nmeyerhans commented 4 years ago

Hi @taqtiqa-mark. It hasn't been considered at all, as far as I'm aware. It's an interesting idea, and you may be right that it's a more natural fit for libvirt than standalone firecracker would be.

On the other hand, is it possible that Firecracker's changes to allow a MicroVM configuration to be passed via a configuration file will simplify libvirt integration without requiring firectl?

taqtiqa-mark commented 4 years ago

On the other hand, is it possible that Firecracker's changes to allow a MicroVM configuration to be passed via a configuration file will simplify libvirt integration without requiring firectl?

I don't know any of the firecracker team, but judging from the design of firecracker I'd guess libvirt is close to a nightmare for them ;)

For example the configuration by file is all XML - I'll spare everyone the rant.
It's also clear the libvirt scope if much larger than firecracker's.

Consequently, it is a non-trivial exercise and question to work out what is a firecracker configuration in terms of the libvirt model of VM's. To take an example, VM storage: it isn't immediately obvious what the firectl configuration for storage would be in terms of libvirt model.

Perhaps one possibility toward convergence is for firectl to consume/generate a YAML configuration file format that can be exported to libvirt's schema?

Example: libvirt's :

<domain type='kvm' id='1'>
  <name>MyGuest</name>
  <uuid>4dea22b3-1d52-d8f3-2516-782e98ab3fa0</uuid>
  <genid>43dc0cf8-809b-4adb-9bea-a9abb5f3d90e</genid>
  <title>A short description - title - of the domain</title>
  <description>Some human readable description</description>
  <metadata>

  </metadata>

YAML:

domain:
  name: MyGuest
  uuid: 4dea22b3-1d52-d8f3-2516-782e98ab3fa0
  genid: 43dc0cf8-809b-4adb-9bea-a9abb5f3d90e
  title: A short description - title - of the domain
  description: Some human readable description
  metadata: ''
  _type: kvm
  _id: '1'

A positive of this would be that firectl's configuration items, and documented meanings are already defined - that subset of libvirt. A negative of this would be that firectl's configuration items, and documented meanings are already defined - that subset of libvirt.

taqtiqa-mark commented 4 years ago

A word on context: I came across firectl when looking to see what would be the best way to add a Vagrant provider for firecracker. Initially I thought Ignite, but I'm now think that would not be sustainable. Firectl seemed like the next natural avenue.

On reflection I'm starting to think either wait for a firecracker provider for libvirt, or use firecracker directly.

Nonetheless, it would seem there is some long term benefit for firectl users if they know they can export libvirt compatible configurations.