4 ms·

Does this use libvirt? It doesn't look like it. Why not? libvirt already provides almost all the functionality you need, you just need to layer a distribution m

by catern 9y ago

Does this use libvirt? It doesn't look like it. Why not? libvirt already provides almost all the functionality you need, you just need to layer a distribution mechanism for configuration across multiple hosts on top.

floren 9y ago
Nope, no libvirt. One big reason for that is, unless I misremember, libvirt needs a daemon of its own. That adds yet another step to deploying minimega on a cluster; as it is, you just copy the minimega binary to every node and run it. If you're netbooting a cluster, adding libvirt is going to make that initrd fatter and make bootup slower. If you're running on a "borrowed" cluster, you may have to convince the owner to install libvirt for you. Basically, we try to avoid external dependencies when possible, to the point where we've even eliminated the two C libs we used to link in. Additional reasons: * We already had a lot of experience driving QEMU/KVM manually (before minimega, we'd write shell and python scripts to launch our big virtual environments) * If we want to do something QEMU supports but libvirt does not, we have to work around that. Since libvirt just wraps QEMU anyway, we avoid the middle-man. * There's XML in libvirt, and we don't like XML :)
- catern 9y ago
  But according to a sibling comment, you support containers too (like libvirt)... you must already have an abstraction layer between you and QEMU. libvirt exposes pretty much every QEMU feature in existence, anyway, and allows passing through raw command line arguments to QEMU if you need it. How does minimega run, if not with a daemon? You can certainly copy a libvirt binary + deps to a bunch of hosts and run it, nothing stopping that... My guess is that minimega just grew out of your bespoke internal tools, and you never seriously tried to get rid of those tools and replace them with a more standard tool, like libvirt. It's disappointing. We're never going to get a viable alternative to Openstack if people keep writing things from scratch instead of reusing existing tools.
  - mdekkers 9y ago
    My guess is that minimega just grew out of your bespoke internal tools, and you never seriously tried to get rid of those tools and replace them with a more standard tool, like libvirt. It's disappointing I must have missed the toolchain-police memo that you can only work on one toolchain. This stuff works for them, has a few cool features, and sounds interesting - I will be trying it out. Nothing wrong with growing out of your internal tools, and open sourcing them. By your reckoning, we'd all still be messing around with 386BSD or MINIX
    - catern 9y ago
      There's also nothing wrong with wanting tools to reuse existing platforms rather than reinvent the wheel. minimega looks neat, but I don't want to sacrifice all the other libvirt-based tooling that's out there. If minimega's virtualization abstraction for a single host was somehow superior to libvirt's, then I would be happy to see them forging ahead. But it's not.
      - mdekkers 9y ago
        minimega looks neat, but I don't want to sacrifice all the other libvirt-based tooling that's out there Great! So libvirt is a good fit for you, awesome. Maybe other people have other needs or wants, and now they have an alternative that might suit them better. Isn't Open Source neat? TBH, your argument is starting to sound very much like "libvirt is my tool of choice and I'm pissed that not every available person is working on the betterment of my preferred tool, instead choosing to work on something that is of no interest to me"
yjftsjthsd-h 9y ago
Monoculture is bad. Why create clang rather than use gcc? Why create Ubuntu when Debian exists? By all means create new things atop existing infrastructure, but don't forget that there is value in having options.

by catern 9y ago

floren 9y ago

Nope, no libvirt. One big reason for that is, unless I misremember, libvirt needs a daemon of its own. That adds yet another step to deploying minimega on a cluster; as it is, you just copy the minimega binary to every node and run it. If you're netbooting a cluster, adding libvirt is going to make that initrd fatter and make bootup slower. If you're running on a "borrowed" cluster, you may have to convince the owner to install libvirt for you. Basically, we try to avoid external dependencies when possible, to the point where we've even eliminated the two C libs we used to link in. Additional reasons: * We already had a lot of experience driving QEMU/KVM manually (before minimega, we'd write shell and python scripts to launch our big virtual environments) * If we want to do something QEMU supports but libvirt does not, we have to work around that. Since libvirt just wraps QEMU anyway, we avoid the middle-man. * There's XML in libvirt, and we don't like XML :)

catern 9y ago
But according to a sibling comment, you support containers too (like libvirt)... you must already have an abstraction layer between you and QEMU. libvirt exposes pretty much every QEMU feature in existence, anyway, and allows passing through raw command line arguments to QEMU if you need it. How does minimega run, if not with a daemon? You can certainly copy a libvirt binary + deps to a bunch of hosts and run it, nothing stopping that... My guess is that minimega just grew out of your bespoke internal tools, and you never seriously tried to get rid of those tools and replace them with a more standard tool, like libvirt. It's disappointing. We're never going to get a viable alternative to Openstack if people keep writing things from scratch instead of reusing existing tools.
- mdekkers 9y ago
  My guess is that minimega just grew out of your bespoke internal tools, and you never seriously tried to get rid of those tools and replace them with a more standard tool, like libvirt. It's disappointing I must have missed the toolchain-police memo that you can only work on one toolchain. This stuff works for them, has a few cool features, and sounds interesting - I will be trying it out. Nothing wrong with growing out of your internal tools, and open sourcing them. By your reckoning, we'd all still be messing around with 386BSD or MINIX
  - catern 9y ago
    There's also nothing wrong with wanting tools to reuse existing platforms rather than reinvent the wheel. minimega looks neat, but I don't want to sacrifice all the other libvirt-based tooling that's out there. If minimega's virtualization abstraction for a single host was somehow superior to libvirt's, then I would be happy to see them forging ahead. But it's not.
    - mdekkers 9y ago
      minimega looks neat, but I don't want to sacrifice all the other libvirt-based tooling that's out there Great! So libvirt is a good fit for you, awesome. Maybe other people have other needs or wants, and now they have an alternative that might suit them better. Isn't Open Source neat? TBH, your argument is starting to sound very much like "libvirt is my tool of choice and I'm pissed that not every available person is working on the betterment of my preferred tool, instead choosing to work on something that is of no interest to me"

yjftsjthsd-h 9y ago

Monoculture is bad. Why create clang rather than use gcc? Why create Ubuntu when Debian exists? By all means create new things atop existing infrastructure, but don't forget that there is value in having options.