Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libvirt provider: firectl #52

Open
taqtiqa-mark opened this issue Mar 10, 2020 · 3 comments
Open

libvirt provider: firectl #52

taqtiqa-mark opened this issue Mar 10, 2020 · 3 comments

Comments

@taqtiqa-mark
Copy link

taqtiqa-mark commented Mar 10, 2020

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

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

taqtiqa-mark commented Mar 10, 2020

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

taqtiqa-mark commented Mar 11, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants