ok apparently smartos gets really mad if you start swapping usb sticks and disks from one machine to another. editing /usbkey/config and making sure the nic tag mac addresses are correct usually fixes this, and it did.

once i confirmed the machine was booting and instances are coming up, i powered it off again and added more memory to bring it from 32GB to 128GB, and it's failing to boot with...

b-rex: Sandalone SmartOS doesn't use the USB after boot time. A Triton headnode does read the config from the USB.

In either case, the config file needs to match the hardware you do actually have.

bahamat: so if i send it back to 32GB of ram it will boot again? the error i see is: svc:/system/filesystem/smartdc:default: Method "/lib/svc/method/fs-joyent" failed with status 95

and it goes into maintenance mode

i didn't think adding memory would cause this error

I think that one is because your dump device is too small now.

ah ok that makes sense because zfs? adding more ram made it angry

Well, I need to see the entire log to be sure.

i'll send this box back to 32GB and migrate the vm then reinstall smartos on these two hosts... i was hoping i could just swap the hardware between the two but apparently not. (this stuff isn't my full time job lol. i'm mostly dev)

But I know that in the past people have had to modify either swap or dump (or both?) when adding RAM.

I think nahamu has dealt with that before.

ok back to 32GB let's see if it boots up. i think it will. thanks bahamat. i love smartos but i'm just a dumb user when it comes to doing anything other than the basics of installing/setting up nics/running our workloads

Hey, everyone starts somewhere.

I asked a lot of dumb questions when I was starting out!

Hmm?

That does sound vaguely familiar.

Certainly if you don't increase swap then you can't utilize all of the DRAM you'd expect to be able to for VMs because of how we lock the memory pages.

I wouldn't be surprised if something wants the dump device to be bigger. Were we able to get the error message out of the SMF service?

nahamu: i didn't go that deep. removed memory until it was back to 32GB and it booted fine. now i'm sending the vms from it to another host so i can re-install smartos after bringing this host up to 128GB

I'm sure the reason is in the log.

That shouldn't be necessary.

for me it is because i'm a noob lol

Yeah, it's definitely fixable from rescue mode.

i know it's not necessary though

living dangerously using vmadm send ofc

And I'm pretty sure this is related to the size of the dump device.

Because we do `dumpadm -y -d <device>`, and I think that fails if the dump device is too small.

b-rex: Beware that vmadm send doesn't correctly create the cores dataset. You'll need to create that manually on the other side.

bahamat: yes i see that in the documentation. it has worked for me for smallish vms but not big ones. crossing fingers this instance goes through

They'll copy, but you'll be missing the cores dataset.

what are the current limitations on KVM instance specs regarding ram and cpu? over the weekend i created a vm with 114GB ram on a 128GB host and it caused the host to boot loop. i tried it on another host with identical specs and same thing

yep all good. cores dataset created. instance now running on another box

Well, with 114G, it's going to attempt to hard allocoate about 112G of RAM. If that's not enough for the rest of the system to function then that's where you're going to have issues. There's not a magic number that's explicitly safe.

But it should fail, not trigger a rebot.

*reboot

Anyone know if gitlab runner works in gz / zone ?

Pretty sure a friend cobbled up gitlab runners in a zone, but not sure if it was the official runner, or cubic zirconium