DemiMarie
commented
3 years ago This was one of the harder parts of making OpenBSD work well in QubesOS. OpenBSD doesn’t expose Xen grants to userspace, so porting the QubesOS tools would require a custom kernel build. I managed to find most of the information needed in XenStore, but I was not able to find the netmask or gateway, so I wound up using static ARP entries and a fake gateway instead. This was made even more difficult because of an OpenBSD kernel bug which prevented the obvious approach from working. Patches sent to fix it were ignored.
marmarek
Osndok
The problem you're addressing (if any)
As mentioned in the qubes documentation, modern linux kernels are unable to make use of the DHCP server to configure their networking.
When setting up one-off guests, it may not be too difficult for experienced users to manually fetch & copy the details from dom0, but it would be a much better user experience if this could be done automatically from within the guest through means such as cloud-init, jeos-firstboot, or even custom-written scripts.
At present, it seems the only way to acquire this information from the guest would require communication over the qubes agent channel, which would effectively require qubes binaries, which others would understandably be reticent to package & maintain for such a niche.
On the other hand, if the network addresses were made available available via
xenstore, then this could be accomplished by just about any OS that supports living under xen, because they would all have the xenstore capability.Describe the solution you'd like
I would like to see the network addresses (ip, netmask, gateway, dns) made available via
xenstoreby any means that the maintainers of qubes see fit.It would be swell if it could be done in a way that a widely-supported provisioning mechanism would already recognize (such as that
xenstore-read vm-datajson blob), or created as an entirely fresh qubes specification (such asxenstore-read qubes/net/gateway).In the first case, it would "just work"... which would be terrific.
In the second case, it might only require the user to create a script or two such as:
Where is the value to a user, and who might that user be?
To the advanced qubes users, this would mean that they could create standalone HVMs that could be successfully cloned in an automatic fashion, or simply to avoid the nuisance of manually tweaking the network configuration each time.
To the maintainers of the provisioning mechanisms, it would be far more agreeable (and easy) to add an extra code path to support qubes if it only required testing for the presence of a xenstore variable, than to package, maintain, and bake-in the qubes agent/db binaries.
To the less-advanced qubes users, it might mean that more ISOs would "just work" going forward into the future.
To the qubes maintainers & community, it might mean marginally fewer "networking doesn't work" support requests, or a lessened "qubes is too hard" disposition.
Describe alternatives you've considered
Additional context
This came to light as I spent way too many hours trying to get an OS I was unfamiliar with (SUSE JeOS; since it has a xen image) to work as a qubes guest, 99% of the time was spent trying to manage the quirks of manually configuring networking without any of the usual nicities (being a super-lean distro).
Relevant documentation you've consulted
Related, non-duplicate issues
5605
6145