I have a ipv6 tunnel isolated on a zone, but when I create the iptun the max possible mtu value is 1480 while the forwarding etherstub is 1500, which makes tls handshakes timeout. The workaround I found was to manually set the mtu to 1480 on the VMs connected to this tunnel, but would it be possible to update the max value on the tunnel link

itself?

Guest14: Here's what I use to create 6-in-4 tunnels: github.com/bahamat/smartos-ipv6-smf/blob/master/ipv6-tunnel

That's worked reliably for me for over 10 years.

thanks!

If you need to explicitly set the MTU (I never needed to) then you'd use `dladm set-linkprop` after `dladm create-iptun` and/or `ipadm set-ifprop` after `ipadm create-if`.

See the dladm and ipadm man pages for the exact syntax.

will take a look

But again, I never needed to, and the MTU on my running system is 1480.

For both dladm and ipadm

So you should be fine just using my script.

Is Hurricane Electric your tunnel broker?

it is

OK, yeah, this will work perfectly for you.

I've used it with HE for forever, and I have production systems using it today.

Start here: github.com/bahamat/smartos-ipv6-smf/tree/master

and go through the regular install.

the issue is that the VMs nics default to 1500, and it basically leads to tls handshake timeout. I had to manually set the mtu to 1480 inside the VMs themselves

yeah I'll take a look at that thanks again

You want to enable ipv6-addrconf, which needs no configuration

I hate web clients.

hello all, just a simple question, can a VM had the storage space (dataset) from two pool? current the VM storage space comes from zones/<vm_uuid>, is it possible to add one dataset from other pool to a VM? eg: a VM’s storage can be: zones/<vm_uuid> nvme/<vm_uuid> (nvme pool means the disk is nvme disk only), want to do this because want to run use NVMe SSD as the database log, any advice to do that? best wishes

tozhu, I think there is add_filesystems in vmadm for extra lofs mounts

not sure if there is one for delegated datasets

(you can add delegated datasets manually with zonecfg)

no idea if there is a performance penalty for a lofs compared to delegated dataset

_jesse: by that way, will it be lost when GZ reboot?

no

you just can't manage it with vmadm

I used to have a zone with 2-3 separate pools attached

the big gotcha is, when you delete the zone, it will destroy all delegated datasets

see vmadm how you can make undeletable dataset, it may be a good idea to do that manually to the added datasets

(basically, you'll need to un-delegate the extra datasets before destroying the zone if you don't want to lose the datasets)

nowadays I've moved to using lofs mounts instead of delegation, it's easier all around

(my extra pools are backup/archive pools, so performance is not really an issue for me. But accidentally deleting a dataset with a zone would be ;))

_jesse: Did you know that SmartOS now supports sharing volumes between zones? Similar to docker's volumes-from feature.

bahamat, I did not

Here's an example: github.com/bahamat/smartos-flair/blob/master/templates/vol_owner.json

that will create a zone with a volume, then other zones you set the source to the full path just like you normally would.

where is that volume created? in /zones/<vol_owner>/root?

It'll be /zones/:zone_uuid/volumes/:vol_uuid, and also mounted at the specified mountpoint within the zone.

So in my template, it's /vol1, but you can put it anywhere

that /zones/:zone_uuid/volumes/ was the part I was wondering

And the "owning" zone doesn't need to even be running

I like that better than just having random filesystems from the gz

yeah, placement of the data on GZ has been a headache

It is also on a separate zfs dataset, but now that I think about it, I've never tried reprovisioning a volume owner zone, so that might not work.

Not that you really need to at all.

I assume the volumes are mounted on GZ and lofs mounted to the volume zone and other zones?

ah, it even says that in the manifest, 'lofs'

Yeah. The volume is created under the zone root, but it's not delegated to the zone.

And IIRC, you can do add_filesystems with the source set to `create-volume` and it'll create a new volume in any existing zone.

...that would have been my next question=)

It was always intended that we'd add this as another volume type in Triton, but that work got backlogged and we haven't picked it up again yet.

I would have done the volume on zone level, though

so instead of /zones/:zone_uuid/volumes/:vol_uuid it data would have been in /zones/:vol_uuid/root

with no way of starting the zone

(would have made zone roots also mountable to other zones for buildah-style build-zone-in-a-zone workflows

Well the feature was already implemented for docker instances, so I just extended it to work with native zones as well.

ah

how dare you not re-invent the wheel!

still no fast mv between zfs datasets, I assume

will be fun migrating tens of terabytes of data from random dataset in GZ to volumes...

If they're already in zfs datasets you can just rename them.

true

but my todo-list has some 'split this and that datasets to more logical pieces' entries already

would be nice to have zfs mv dataset1/dir dataset2/

it's just some reference shuffling in the metadata, afaik=)

Well, technically yes, but it's not as straightforward as that makes it sound.

well, there's accounting here and there and edgecases when quota overflow etc=)

New SmartOS release!