hi guys, i hope you can help me with this, i'm using network overlays

when my overlay network enters in degraded state, i'm unable to recover it by fixing the error that caused the degraded state

i'm using "files" as search plugin and the error that causes the degraded state is typing any error in the json file

afaik the only way to recover it is shuting down zones using that overlay, deleting the overlay and recreating it, do you know any way to repair the overlay without doing that ?

psarria_: perhaps "svcadm restart varpd" in the global zone?

Tell me, does SMF report varpd is down when you have a typo?

`svcs -xv varpd` ?

danmcd, i tried restart varpd withous success, the varpd service itself is never down, i see no core files for varpd neither

Hmmm... Perhaps you need to flush out the overlay first?

svcadm disable -t varpd

dladm modify-overlay -f <overlay-device-in-gz>

svcadm enable varpd

It's varpd that loads from the file.

it seems it cannot flush, i suppose the overlay is degraded

[root@12lab ~]# dladm modify-overlay -f o123

dladm: failed to flush target cache for overlay o123: operation failed

When you say "degraded" do you mean w.r.t. fmadm(8)?

when varpd is reenabled the problem persist and the overlay remains degraded

[root@12lab ~]# dladm show-overlay -f

LINK STATUS DETAILS

o123 DEGRADED no varpd instance exists

"No varpd" ?

yes

pgrep varpd says?

And `svcs -xv varpd` ?

[root@12lab ~]# pgrep varpd

33522

varpd is running however

when overlay enters in degraded state, fmadm faulty show an event about it but the problem persist when i tried fmadm commands as repaired o replace

Use gist/pastebin/whatever, but please utter `fmadm faulty` so I can see the fmadm view of the faulty overlay?

ok, i must leave now but i get output of fmadm faulty in shortly

danmcd, thanks a lot

does VNC work with bhyve zonesin Triton? I've never really used it and was trying to yesterday to debug a problem with my SSH key. I can seem to get a connection, but the display is always just a black screen.

jdt: Yes, but you have to be using the efi firmware.

jdt: Set bootrom=uefi on the vm and then stop/start it.

okay, I'll give that a go - thanks.

that did the trick. in retrospect, I'm not sure how useful it'll be (my problem yesterday was with my local SSH agent), but a good tool to have in the arsenal. thanks again.

You can set it on the image after you import it.

sweet, g2k

We've been debating whether we should add that to images by default, but it makes them incompatible with KVM if we do.

So for now we've left it as a post-import task.

makes sense. backwards compat is hard to manage. anecdotally, I'm not using KVM anywhere any more. but I'm sure lots of folks are.

...and I think the BSD images are still tied to KVM, aren't they?

testing with FreeBSD was the last time I think I saw "K" in my instance list.

bahamat, if you had not forced uefi-or-bios setting in vmadm, you could have had disk images with both uefi and mbr boots...

(as in, you can't have an image that can be set to uefi or bios depending what you want after creating the image)

unless it was fixed since I ran into it=)

jesse_: Currently produced images support both mbr and efi.

bahamat, sweet

Which is why you can choose on a per-instance basis.

By default it will be bios so that it's compatible with KVM.

ah, true, you did say that above

my thick head is too thick to ingest information this fast

If you want uefi (which if you're using bhyve, you almost certainly do), then you can set it.

But because the vm json comes from the end user, there's no way for us to even suggest or imply that you probably should, other than put it in the man page.

Which it's already listed there.

there used to be some setting that came from the image manifest that forced your hand, but that was apparently fixed

You can set requirements on an image. And if you, as the operator want all of your instances to be bhyve with uefi, you can set that on the image after you import it.

But we don't set that in our image server so that if you want to use it with kvm you still can.

The other least bad option is two identical images that differ only in the uuid and the brand/bootrom requirement. And that's not a very efficient use of space.

bahamat: can that be set in the VM interface in Triton somewhere (like via metadata)? Or is it only adjustable on the node using vmadm?

You can set it on the image after it's imported to imgapi, then all instances created with that image will use it automatically.

Like 'triton image update d89041d8 bootrom=uefi'?

no, not so much, I guess.

ssh into the headnode, then do `sdc-imgadm update <uuid> requirements.bootrom=uefi requirements.brand=bhyve

thanks

jdt: are you booting/debugging a *nix/*bsd that has serial console support? that worked for me by default : 'vmadm console <uuid>'

aquamo4k: nice, yeah that works too.

cool, i find using vnc cumbersome so always try to configure or have a serial console :-) hard to cut and paste console output from a vnc screen scraper