dumb question, someone posted a link to my.mnx.io the other day and i opened it, is that the open source interface for triton? is the open-source version feature-complete? i'm more of a ssh+vmadm guy :p

gonzosysadm[m]1: this is probably the customer end portal that is available for paid support subscriptions, but I'm just guessing

i yelled "hi mnx people" on my way down 75 yesterday

tsoome seems that in the latest smartos image things look better I see the nblocks property on the device but the install still fails termbin.com/owfvx

I compiled ipxe again but in omnios, and with a couple of changes smartos boots successfully using ipxe now I we just need to find out the disk issue

is the ipxe version or the new smartos image, but now it works in oracle cloud

Just checking to see if github issues, are the correct place for bug reports from the OSS community, I saw the last triton bug was opened by me in 2019.

barfield: They are usually opened in their respective repos. So like in TritonDataCenter/sdc-vmadm, not just in TritonDataCenter/triton.

That makes sense. So would I open an sdc-migrate issue under sdc-vmapi then? Or under tritondatacenter/sdc?

gonzosysadm[m]1: The only difference between open source Triton and paid support Triton is whether you're paying for support.

Yes, sdc-vmapi.

cool

barfield: With migration issues, I'll need exact reproducible steps. "something weird happened one time" isn't really something that can be diagnosed.

Any time a vm is altered outside of triton itself, it makes it an outlier and things can go wrong.

And by "outside of Triton", that is really more like outside of cloudapi. Calling the APIs directly can change a vm in a lot of ways that sdc-migrate might not expect.

Also stuff like "cn panic'd partway through and now it's wedged" isn't considered a bug, because that's what the rollback stuff is for.

This can be reproduced on a fresh VM provisioned from cloudapi

Ah, so that happens any time indestructable root is set?

yes sir

I've encountered this numerous times

So I finally decided to report it lol

Cool, that's a perfect example of a good bug with migration.

Do you need version info?

Nah.

So next Triton release is Feb 9. I'll try to get this in for that.

It should be fairly simple.

awesome! Thanks man

Yeah I kind of thought and in looking at the source I didn't see any functionality pertaining to the indestructible setting, so I didn't really think that this was currently version specific

So the migration works, but it leaves a mess on the source, right?

I'll look at it again, if I think I could fix easy enough I'll shoot over a PR unless you want me to leave it alone and let you guys handle

That is correct

And it also cannot start on the destination

Sorry

let me clarify

And because it leaves a mess, it considers that the finalization failed.

It does not start

right

Ok, yeah, that makes sense.

Does the new copy have deletion protection?

I didn't verify though, let me do this now, if it does set the boolean on the destination cn

LAMO

checking that now

It might inherit it from the zfs send.

I was wodnering since its just a snapshot basically

from my command history it appears to fail on the "switch" step

It does set the value to true on the destination node

Also oddly the error that I saw was "unable to `zfs set quota=0`" I didn't copy the error though so I am not sure where it was claiming that error to be true.

That seemed buggy as well, since zfs set quota=0 doesn't work, syntax is zfs set quota=none

Yeah, that sounds weird.

TRITON-2127

Sorry, TRITON-2127 is not public.

All good, I figured its your own jira

Well let's fix that.

Should I update those details in the github issue?

TRITON-2127

oh hell, thats an old bug haha

regression maybe?

So...yeah, your version info may be relevant here :-)

I see a fix appears to have been merged in

I'm only like 2 releases behind current

which is like June 2022 I think

There's fixes in both sdc-vmapi and cn-agent.

You need both for it to work.

Is jinni a user or is that like joybot haha

Do you know which Triton release those were in?

It's a bot

cool

9e1d678a-5686-474f-9b98-14c98626dc9c

release-20200521 and later

sorry

bahamat is there documentation on how to setup a netboot server for smartos? I need to test some changes in smartos and the only way to test them is through ipxe (is faster really)

I thought that sdcadm services is where versions were at

oh I found it `sdcadm insts`

release-20220825-20220825T003215Z-g6ac7d1c

This is a bhyve VM BTW

neirac: Mostly it's just clone the repo and run `tools/setup.sh`, though it makes some assumptions about our own deployment (e.g., cert names).

^release is vmapi

cn-agent 2.14.7

I'll update the issue with the rest of these details, I know you're probably slammed

I'm also on vacation right now :-)

so youre an addict or a masochist? haha

I'm on PTO too lol

Well, today is the SmartOS office hours, so I was checking in just on my own.

I had thought for a bit that maybe you were taking an IRC break and I wouldn't blame you a bit if you did

Mostly, yes.

Are the details that I added enough? I think that I got everything. Will stop bothering you. Hopefully you're near a beach and a beach-bar :)

okay done spamming you with github edits

danmcd: I saw something on the illumos developers list discussing kernel memory exaustion with i40e NIC when dladm generates VNIC's. I was actually hitting this issue on a compute node the other day that had 3 VM's provisioned and I think around 24G of free RSS on the compute node. the PI is from 202206, but I am wondering if anything has been updated in the driver since June to enhance memory

management, to determine if I should do some PI updates on Triton.

I haven't found anything specifically in release notes yet...thought you might be aware of something that I wasn't was all

using the triton repo for creating netboot server worked, thanks bahamat.