22:04:35 <jdt> bahamat: I did some experimenting, and that problem with the DNS servers being tied to the global zone configuration (8.8.8.8/8.8.4.4) does seem to be exlusive to the debian-12 image. The ubuntu-22.04 HVM image seems to resolve against my internal resolvers just fine. The base-64-lts zone does as well.
22:04:41 <jdt> In general, LX images aren't working well for me at the moment, so I can't really test that (lots of angry errors like: "netmgr/udp.c:1019:isc_nm_udpconnect(): fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS || result == ISC_R_NOTIMPLEMENTED) failed").
22:05:18 <jdt> I did try the debian-12 HVM image on both KVM and Bhyve and they both exhibit the same problem behavior.
22:15:33 <bahamat> jdt: I found the cause of the issue with the deb12 images. FWIW, it also affects deb11.
22:16:07 <bahamat> I'll be publishing new images soon (tomorrow, or early next week) that will address it.
22:16:39 <bahamat> What application are you running that's producing those errors? I'd like to dig more into that.
22:32:51 <jdt> just dig and nslookup
22:33:21 <jdt> here's a quick (multi-line) example:
22:33:27 <jdt> root@varnish-test:~# dig cnn.com
22:33:28 <jdt> netmgr/udp.c:1019:isc_nm_udpconnect(): fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS || result == ISC_R_NOTIMPLEMENTED) failed
22:33:28 <jdt> Aborted (core dumped)
22:33:28 <jdt> root@varnish-test:~# nslookup
22:33:28 <jdt> > cnn.com
22:33:29 <jdt> netmgr/udp.c:1019:isc_nm_udpconnect(): fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS || result == ISC_R_NOTIMPLEMENTED) failed
22:33:30 <jdt> Aborted (core dumped)
22:34:15 <bahamat> And that's the deb11/12 LX image?
22:34:31 <jdt> LX Instance (Debian GNU/Linux 12 (bookworm) 20230721)
22:36:31 <jdt> Fwiw, I couldn't get the latest void LX instance to provision at all. It tries to, spins for 5 minutes in "provisioning" and then fails.
22:39:33 <bahamat> Yeah, I've had some issues with the void image which is why I haven't published a new one recently.
22:39:58 <jdt> I figured that was probably a known issue.
22:50:11 <jdt> Random question - I'm thinking about adding another CN to my cluster and was thinking mayby Linux CN. Probably obvious, but I wouldn't be able to run SmartOS zones on that, right?
22:50:20 <jdt> *maybe
22:50:41 <bahamat> definitely not
22:51:12 <bahamat> Linux doesn't do illumos syscall translation in any form.
22:51:19 <jdt> Makes sense. I assume it does bhyve and kvm, though?
22:51:30 <bahamat> No.
22:51:36 <jdt> Oh, okay.
22:51:39 <bahamat> Currently it's LXC only.
22:51:45 <jdt> Got it.
22:52:02 <jdt> Thanks for the clarification.
22:52:24 <bahamat> Adding KVM is possible, and not even really that hard. But it would take some additional work in imgapi/imgadm and vmapi/vmadm.
22:52:35 <bahamat> It just remains to be done.
22:52:56 <bahamat> But we're not porting bhyve to Linux.
22:53:30 <jdt> Ah yeah, I see that now in the "Importing Supported Images".
22:54:06 <bahamat> A prerequisite to even considering bhyve on linux is someone from the linux and/or freebsd communit(y|ies) does that work first.
22:54:18 <bahamat> Until then, there's zero chance.
22:54:57 <bahamat> Odds of that even happening, I think are roughly zero.
22:55:04 <jdt> Still, LXC is useful in its own right.
22:55:26 <bahamat> It is. It's super useful in some cases.
22:57:56 <bahamat> Even getting KVM on Linux working with the rest of our stuff, whether we can use the same images as SmartOS remains to be seen.
22:58:42 <bahamat> LXC provides KVM images, and it uses a model similar to SmartOS where they run qemu inside a container.
22:59:30 <bahamat> So we could just get those, but those images probably wouldn't be usable on SmartOS, and the images we produce now probably wouldn't be usable by LXC.
23:04:14 <jdt> At some point the cost-benefit ratio has to be considered, I suppose. Do you think there's a desire to move toward Linux with the platform as a whole?
23:05:08 <jdt> Whether the strategy is "SmartOS for the future" or "Linux for the future" is probably the most important decision.
23:05:52 <bahamat> Well, SmartOS zones alone can fill the vast majority of needs. But we're not going to dictate that people use SmartOS zones if they don't want to. People have preferences, existing tooling, existing workflows, etc. It can be extremely disruptive to change all of that. And I get it.
23:06:51 <bahamat> LX also satisfies a huge set of use cases. There are some bugs and incompatibilities with it. Some of those are easier to address than others.
23:07:29 <bahamat> Where there are issues with LX, bhyve is almost always sufficient. Certainly at least as sufficient as any other VM platform from any other provider.
23:08:24 <bahamat> There's an extremely narrow set of cases where someone wants container level performance (i.e., a vm isn't good enough), but LX also won't work.
23:08:43 <bahamat> In those cases, LXC solves that.
23:08:47 <jdt> Personally, I like using SmartOS zones when I can, but I do find myself using Debian more frequently (mostly because the company I do the most work with prefers it and is currently using Ganeti to manage VMs - I'd love to move them to Triton at some point, though).
23:09:33 <bahamat> The use cases that I know of where LXC is definitely more suited are running a firewall/router/packet filter in a continer (i.e., you actually want iptables)
23:09:59 <bahamat> The other is like running Oracle DB (or something similar..maybe SAP?)
23:11:18 <jdt> Interesting: https://github.com/jack9603301/vyos-on-lxd - that's something to experiment with.
23:11:28 <jdt> (For me. :) )
23:11:50 <bahamat> Yeah, that's the kind of thing where LXC is the best place to run it.
23:12:29 <bahamat> We're never going to provide netfilter compatibility, and for something like that you want higher performance than you can get out of a VM.