am I doing something very, very, very wrong, or do lx zones not support setting a default route?

# route add -6 default

SIOCADDRT: Operation not supported

not v6 specific btw

i got my v6 from addrconf, that should have also set the default gateway (normal zones have the same addrconf config, and they do)

i'm guessing that it didn't because it's actually not supported to set the route in the lx zone? in which case how am I supposed to get connectivity - won't do it from addrconf although it should, and cannot set it manually from the zone, says operation not supported. for good measure, gateways (vmadm zone json conf parameter) cannot take an ipv6 address

Is it possible to set it with the route command that's under `/native/sbin/` ?

i was just testing that, as i read just now that /native is mounted in the zone; and yes, that way it's possible

obvious question, shouldn't the image be doing that ? :p (debian-11 lx-dataset)

.. but i still can't get connectivity, i'm troubleshooting (doesn't make sense)

hmm, actually it's just dns that's not working

and yet the right nameserver is set in resolv.conf

yeah, it just seems like some very weird thing happens with anything to do with name resolution. i'm snooping eth0 from the gz, and i can see a ping attempt from the lx zone to the dns going out and being answered

but i try to use a hostname to make ping resolv it, and i don't even see a dns query on eth0

can the root pool be encrypted these days?

vs setting up delegated+encrypted filesystems in all relevant zones

triton only supports encrypting the entire zones pool

if you're trying to encrypted individual datasets, you're off on your own

unfortunately, there's nothing for standalone smartos

though

yeah i'm on standalone

it's easy enough to manage it individually per vm, but it's going to be brutal to manage. it would make more sense to encrypt the whole thing

if i can ever finish writing a tpm2.0 driver... with a bit of work, that could be used instead of a yubikey (unlike the 1.2 spec which was near worthless, 2.0 mandates some reasonable mechanisms, including the same ECC curves kbmd uses w/ yubikeys)

which would avoid some of the bootstrapping problems

(today w/ triton, an encrypted boot node sends a signed request to the head node for the pin protecting the zpool encryption key and uses that to unlock the pool)

for standalone, you'd need to add something -- prompt for the pin or something

well, asking for the decryption key at the console should be enough. like freebsd, linux or openbsd

jbk -- untested but a pool booting SmartOS has $BOOTPOOL/boot unencrypted. That dataset is essentially an on-disk USB key for most purposes.

BOOTPOOL being encrypted (save boot/) is untested.

Our advise for those with encrypted zones is "dedicated boot pool please".

Can I actually pass through PCI-E graphics card to Bhyve VM , USB keyboard, mouse, USB audio and use it as desktop? Same goes for Triton compute node?