41–50 of 113 posts
Libvirt is really nice. For linux, I also recommend reading the man page of Qemu directly to learn more about internals, it helped me understand a lot. Of course you have to take care networking, disk management on your own but it can be really simple. https://linux.die.net/man/1/qemu-kvm
virsh domxml-to-native qemu-argv myvm.xmlEarlier quoted context omitted.
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…
> JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Do this with libvirt please and report back how it went :)
If you fire up `virsh edit ` you get a live view of the resource which can be updated in place. This is great to comment out some things and uncomment things for quick and dirty modifications. (some require a VM restart though).
Earlier quoted context omitted.
I’ll start. Take an XML document. Validate it. Take all of the top level elements. Call getElementByID on each with the same value. Combine all the answers into an array, eliminating the nulls. You might expect that array to have length one or zero on all valid documents. You’d be wrong, and dangerously so for some XML schemas. You can use the same ID on every node and I don’t know of a parser that would balk at that…
If only you could specify in your schema that element must be unique. But wait a minute ! Actually, you can. That's what the unique attribute does. And here lies the main problem of XML. As a technology, it is better than its reputation. Sadly, next to no one knows how to use it properly.
Too bad it was initially envisioned as a text markup language, with tags sparsely strewn around the text, and not as a data representation format.
So, the syntax ended up both overly cumbersome (see closing tags) and festooned with logically unnecessary shorthands like node attributes. Then, the terror of entities.
XSLT is a brilliant language, I'd say the first pure functional language widely used outside academia (in 2000s), but, based on XML syntax, it's completely unfit for human consumption.
If only the authors of XML could get rid of the shackles of SGML compatibility, and went with a simple, uniform syntax, e.g. s-expressions, we could still be gladly using it. Now we reinvent the ecosystem instead, with JSON (sigh) and YAML.
Earlier quoted context omitted.
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…
This is exactly why TOML [0] is gaining traction as a simple configuration file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python is moving this way with (`pyproject.toml`). For more general data structures, remember that JSON is a true subset of YAML [1]: Switch to a YAML parser and you can start optionally adding comments to your files while still being compatible with legacy input. [0] http…
While I respect the job that libvirt does (it works — high praise for software), it’s unfortunate that it is also the answer to the question “how can I represent all these virtualized things using XML?”, which was in fashion when libvirt was created. It’s also a bit misleading to characterize cloud providers as building on libvirt. Libvirt is useful as an mostly hypervisor-agnostic wrapper, which is super useful for…
Not sure if you're claiming this or not, but it's worth clarifying:
Libvirt is a hypervisor-agnostic transport library; but it is not a hypervisor abstraction library.
That is, you can use libvirt to talk to KVM or VMWare or Xen or Hyper-V. But you cannot, in general, take a VM config from one hypervisor and use it on another hypervisor: there are too many details of the underlying hypervisor exposed to make this possible. And if you build a tool on top of libvirt for one hypervisor, you can't just flip a switch and have it work on another hypervisor -- all of the code that generates your XML configs for (say) KVM will need to be rewritten if you want to use Xen or VMWare or Hyper-V.
As an example, in the config you don't really say, "Give me a disk, and here's the disk image". You say, "Give me a virtio disk of this particular version with these particular properties." If your hypervisor doesn't provide virtio, the image simply can't be created. Which means the tool you're writing on top of libvirt needs to know the appropriate PV disk type for each different hypervisor and use the appropriate one.
(At least, this was the situation several years ago, when a team from oVirt came to a Xen hackathon to see if they could get oVirt working on Xen. It turned out to be more work than they thought.)
Earlier quoted context omitted.
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…
This is exactly why TOML [0] is gaining traction as a simple configuration file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python is moving this way with (`pyproject.toml`). For more general data structures, remember that JSON is a true subset of YAML [1]: Switch to a YAML parser and you can start optionally adding comments to your files while still being compatible with legacy input. [0] http…
> For more general data structures, remember that JSON is
> a true subset of YAML [1]
Libvirt is really nice. For linux, I also recommend reading the man page of Qemu directly to learn more about internals, it helped me understand a lot. Of course you have to take care networking, disk management on your own but it can be really simple. https://linux.die.net/man/1/qemu-kvm
There's a nice tool to get qemu command lines from libvirt xml: virsh domxml-to-native qemu-argv myvm.xml
While I respect the job that libvirt does (it works — high praise for software), it’s unfortunate that it is also the answer to the question “how can I represent all these virtualized things using XML?”, which was in fashion when libvirt was created. It’s also a bit misleading to characterize cloud providers as building on libvirt. Libvirt is useful as an mostly hypervisor-agnostic wrapper, which is super useful for…
And not least of all, libvirt provides critical layered security for QEMU processes (i.e. VMs) through Linux Namespaces, CGroups, sVirt ('Secure Virtualization', based SELinux), and more.
(Also see user bonzini's response here for some more detail — https://news.ycombinator.com/item?id=24372499)
Earlier quoted context omitted.
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…
INI only supports 2 levels of hierarchy? That is not equivalent.
Earlier quoted context omitted.
JSON is a bad configuration format simply for the fact that it doesn't support comments. Some parsers do but most don't. XML for all its verbosity and complexity at least has comments where I can quickly try out configuration changes without needing to save the old configuration somewhere else. Hell, even INI files had support for comments and were just as expressional as JSON. I wonder why we regressed in that regar…
This is exactly why TOML [0] is gaining traction as a simple configuration file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python is moving this way with (`pyproject.toml`). For more general data structures, remember that JSON is a true subset of YAML [1]: Switch to a YAML parser and you can start optionally adding comments to your files while still being compatible with legacy input. [0] http…
I see a lot of Rust programmers preferring RON over TOML because it is much less complex and doesn't have multiple ways to express the same thing https://crates.io/crates/ron