4 ms·

I've use this method recently. Our VM service is based on libvirt, which doesn't support QEMU socket type interface natively, so I need to add the following to

by ytch 3y ago

I've use this method recently. Our VM service is based on libvirt, which doesn't support QEMU socket type interface natively, so I need to add the following to the XML: <qemu:commandline> <qemu:arg value='-netdev'/> <qemu:arg value='socket,id=mynet0,listen=10.6.0.1:12200'/> <qemu:arg value='-device'/> <qemu:arg value='virtio-net-pci,netdev=mynet0,id=net1,mac=58:a4:c0:a8:bf:51,bus=pci.0,addr=0x3'/> </qemu:commandline> On the other endpoint, a Linux TAP tunnel daemon is responsible for encapsulating packet to the Length-Value data as the article said. In this way, I can create a L2 tunnel from remote site to the VM, also keep the VM untainted.

yrro 3y ago
After initially being keen on running qemu directly, I've really come to appreciate libvirt, even thought you do have to be willing to peer past all the XML...
- zer00eyz 3y ago
  >> willing to peer past all the XML Does xml suck. Meh yea it mostly does. Was it a crappy format for everything. Yes, XML over the wire, not so great. Would I rather have xml configs than yaml, or json... The more I think about it, yes, I would. 1. The dom sucks in a browser, it's gross when it gets huge. If your config files are THAT large then, we have OTHER problems. 2. Validation. It validates. Not only on a syntax level (is this document complete, does it have a final close tag). You can also run checks against a DTD, an xml schema and XSD(??? its been a while, I think this was a way). 3. XSLT: I have mixed feelings on this, but there was a way to merge, change and transform... IT was powerful and testable, way better than templated config files. Maybe I am looking at it wrong, maybe this is me having rose colored glasses for an ex. But I sure would like all those features BACK.
  - bbatha 3y ago
    All of these exist for json, and since yaml has the same object structure as json these tools can mostly be reused 1. Plain old hash maps and arrays. No special stuff required 2. JSON schema exists and works pretty well 3. JSON path and json patch cover this. Though because json follows a plain object model there just isn’t as much need. Contrary to xml having clean object structure and not having to worry about using nested data or props makes all of the above easier and require fewer special tools. Additionally in the qemu example you can see problems with xml right away look at this extra “qemu:” structures, yay more stuff to parse. Then the args come in as repeated elements, are those an array or not?
- sebazzz 3y ago
  Mostly because it is only partially documented, on a few RedHat pages. This is where GPT shines because it is able to make something better from the incomprehisible mess of RedHat.

by ytch 3y ago

yrro 3y ago

After initially being keen on running qemu directly, I've really come to appreciate libvirt, even thought you do have to be willing to peer past all the XML...

zer00eyz 3y ago
>> willing to peer past all the XML Does xml suck. Meh yea it mostly does. Was it a crappy format for everything. Yes, XML over the wire, not so great. Would I rather have xml configs than yaml, or json... The more I think about it, yes, I would. 1. The dom sucks in a browser, it's gross when it gets huge. If your config files are THAT large then, we have OTHER problems. 2. Validation. It validates. Not only on a syntax level (is this document complete, does it have a final close tag). You can also run checks against a DTD, an xml schema and XSD(??? its been a while, I think this was a way). 3. XSLT: I have mixed feelings on this, but there was a way to merge, change and transform... IT was powerful and testable, way better than templated config files. Maybe I am looking at it wrong, maybe this is me having rose colored glasses for an ex. But I sure would like all those features BACK.
- bbatha 3y ago
  All of these exist for json, and since yaml has the same object structure as json these tools can mostly be reused 1. Plain old hash maps and arrays. No special stuff required 2. JSON schema exists and works pretty well 3. JSON path and json patch cover this. Though because json follows a plain object model there just isn’t as much need. Contrary to xml having clean object structure and not having to worry about using nested data or props makes all of the above easier and require fewer special tools. Additionally in the qemu example you can see problems with xml right away look at this extra “qemu:” structures, yay more stuff to parse. Then the args come in as repeated elements, are those an array or not?
sebazzz 3y ago
Mostly because it is only partially documented, on a few RedHat pages. This is where GPT shines because it is able to make something better from the incomprehisible mess of RedHat.