11:42:08 hi guys, i hope you can help me with this, i'm using network overlays 11:42:24 when my overlay network enters in degraded state, i'm unable to recover it by fixing the error that caused the degraded state 11:42:39 i'm using "files" as search plugin and the error that causes the degraded state is typing any error in the json file 11:42:57 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 ? 14:39:21 psarria_: perhaps "svcadm restart varpd" in the global zone? 14:39:39 Tell me, does SMF report varpd is down when you have a typo? 14:39:48 `svcs -xv varpd` ? 14:40:45 danmcd, i tried restart varpd withous success, the varpd service itself is never down, i see no core files for varpd neither 14:41:46 Hmmm... Perhaps you need to flush out the overlay first? 14:41:54 svcadm disable -t varpd 14:42:13 dladm modify-overlay -f 14:42:17 svcadm enable varpd 14:42:23 It's varpd that loads from the file. 14:43:56 it seems it cannot flush, i suppose the overlay is degraded 14:44:00 [root@12lab ~]# dladm modify-overlay -f o123 14:44:00 dladm: failed to flush target cache for overlay o123: operation failed 14:44:35 When you say "degraded" do you mean w.r.t. fmadm(8)? 14:44:41 when varpd is reenabled the problem persist and the overlay remains degraded 14:44:56 [root@12lab ~]# dladm show-overlay -f 14:44:57 LINK STATUS DETAILS 14:44:57 o123 DEGRADED no varpd instance exists 14:45:07 "No varpd" ? 14:45:11 yes 14:45:14 pgrep varpd says? 14:45:24 And `svcs -xv varpd` ? 14:45:25 [root@12lab ~]# pgrep varpd 14:45:25 33522 14:45:32 varpd is running however 14:47:11 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 14:48:13 Use gist/pastebin/whatever, but please utter `fmadm faulty` so I can see the fmadm view of the faulty overlay? 14:49:50 ok, i must leave now but i get output of fmadm faulty in shortly 14:49:55 danmcd, thanks a lot 19:36:29 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. 19:49:36 jdt: Yes, but you have to be using the efi firmware. 19:50:41 jdt: Set bootrom=uefi on the vm and then stop/start it. 19:51:30 okay, I'll give that a go - thanks. 20:00:35 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. 20:00:59 You can set it on the image after you import it. 20:01:19 sweet, g2k 20:01:34 We've been debating whether we should add that to images by default, but it makes them incompatible with KVM if we do. 20:01:48 So for now we've left it as a post-import task. 20:02:44 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. 20:03:46 ...and I think the BSD images are still tied to KVM, aren't they? 20:04:13 testing with FreeBSD was the last time I think I saw "K" in my instance list. 20:37:58 bahamat, if you had not forced uefi-or-bios setting in vmadm, you could have had disk images with both uefi and mbr boots... 20:38:29 (as in, you can't have an image that can be set to uefi or bios depending what you want after creating the image) 20:39:19 unless it was fixed since I ran into it=) 20:40:14 jesse_: Currently produced images support both mbr and efi. 20:40:29 bahamat, sweet 20:40:30 Which is why you can choose on a per-instance basis. 20:40:46 By default it will be bios so that it's compatible with KVM. 20:40:47 ah, true, you did say that above 20:41:06 my thick head is too thick to ingest information this fast 20:41:15 If you want uefi (which if you're using bhyve, you almost certainly do), then you can set it. 20:41:50 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. 20:41:57 Which it's already listed there. 20:42:26 there used to be some setting that came from the image manifest that forced your hand, but that was apparently fixed 20:43:23 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. 20:43:46 But we don't set that in our image server so that if you want to use it with kvm you still can. 20:44:58 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. 21:04:38 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? 21:05:49 You can set it on the image after it's imported to imgapi, then all instances created with that image will use it automatically. 21:07:33 Like 'triton image update d89041d8 bootrom=uefi'? 21:08:00 no, not so much, I guess. 21:08:50 ssh into the headnode, then do `sdc-imgadm update requirements.bootrom=uefi requirements.brand=bhyve 21:09:25 thanks 23:01:15 jdt: are you booting/debugging a *nix/*bsd that has serial console support? that worked for me by default : 'vmadm console ' 23:07:21 aquamo4k: nice, yeah that works too. 23:29:59 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