Re: [smartos-discuss] problem with mixed up mount points

[Gareth Howell]

Thanks, Daniel
Importing with alternative mount points can be done if you are importing
manually, however it can’t be done if you are booting normally. All the
problem datasets have the mountpoint set to “legacy”.
If I change the mountpoints in zznew to avoid a clash, I get a kernel panic
when the system boots.


Gareth

On 7 February 2018 at 20:46:18, Daniel Carosone (daniel.caros...@gmail.com)
wrote:

> Those datasets have explicit mountpoint properties, with the same values
> as your live pool, and have been imported/mounted first, before the ones
> you wanted.
>
> You should import the inactive pool with -R, or in recovery mode import
> them both with different roots.
>
> On 8 Feb. 2018 02:00, "Gareth Howell"  wrote:
>
>> This is really a continuation of my previous post on migrating to a new
>> pool configuration, but it deserves a new thread.
>> 
>> After the “send/recv, destroy/create, swap names” dance, I have a single
>> disk `zones` pool with all the data on it and a new raidz1 pool called
>> `zznew` that will become the new `zones` after I have synced it. However,
>> something odd has happened somewhere.
>> 
>> Prior to creating `zznew` I just had the single disk `zones` pool. When I
>> booted, the kernel panicked and the system reset. After examining the pool
>> in recovery mode, all seemed well but I couldn’t get anywhere because I can
>> only use the console and the error messages zoom past too fast to read. (It
>> did try to save a dump log but that failed as well).
>> 
>> To make progress, I removed the single disk pool and did a clean install
>> using a newly created raidz1 pool. I could then import the bad pool, but
>> again I could see no problems.
>> 
>> I was moving towards having to do a reverse copy from the imported zone
>> to the running zone but before I did so, I tried swapping the pool names.
>>  a single disk `zones` and a “runnable” raidz1 `zznew` pool. The system
>> booted to my surprise.
>> 
>> Looking at the mount points etc showed the following
>> 
>> root@deneb ~ $ zfs list
>> NAME   USED  AVAIL  REFER
>> MOUNTPOINT
>> zones 2.67T   863G   588K
>> /zones
>> zones/archive  152K   863G88K
>> none
>> …
>> zones/config   468K   863G   196K
>> legacy
>> zones/cores250M   863G88K
>> none
>> …
>> zones/cores/global 152K  10.0G88K
>> /zones/global/cores
>> …
>> zones/dump 260K   863G   140K  -
>> …
>> zones/opt 2.50T   863G  1.20G
>> legacy
>> …
>> zones/swap33.2G   896G   246M  -
>> zones/usbkey   196K   863G   132K
>> legacy
>> zones/var 1.05G   863G  1.03G
>> legacy
>> zznew 37.6G  3.47T  1018K
>> /zznew
>> zznew/archive  117K  3.47T   117K
>> /zznew/archive
>> zznew/config   139K  3.47T   139K
>> legacy
>> zznew/cores234K  3.47T   117K
>> none
>> zznew/cores/global 117K  10.0G   117K
>> /zznew/global/cores
>> zznew/dump1.84G  3.47T  1.84G  -
>> zznew/opt 2.88G  3.47T  2.88G
>> legacy
>> zznew/swap32.9G  3.50T  74.6K  -
>> zznew/usbkey   261K  3.47T   261K
>> legacy
>> zznew/var 3.91M  3.47T  3.91M
>> /zznew/var
>> 
>> root@deneb ~ $ zfs mount
>> zones   /zones
>> …
>> zznew   /zznew
>> zznew/archive   /zznew/archive
>> zznew/cores/global  /zznew/global/cores
>> zznew/var   /zznew/var
>> zznew/config/etc/zones
>> zznew/opt   /opt
>> zznew/usbkey/usbkey
>> 
>> I deleted some irrelevant bits and highlighted the problems. The system
>> is mounting some datasets from zznew as if they are from zones.
>> 
>> Any ideas on how to correct this so that /etc/zones, /opt and /usbkey
>> mount from zones rather than zznew?
>> 
>> Gareth
>> 
>> *smartos-discuss* | Archives
> 
>  |
> Modify
> 
> Your Subscription 
>



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your 

Re: [smartos-discuss] Create network overlays after boot

[Dan McDonald]

I'm so glad to see you're using the built-in illumos IPsec features for your 
overlay improvements.  If you don't already know, we're working on IKEv2 for 
illumos-via-SmartOS.  As we move along with it, it would be interesting to have 
your feedback on it.

Thanks for this update, and the documentation links.  I'll need to give them 
(esp. the IPsec-specific bits) a bit of a deeper read.

Thanks!
Dan



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Re: [smartos-discuss] Create network overlays after boot

[Daniel Kontsek]

Hi Robert, Cody et al.

Finally, we have released a version of Danube Cloud that is able to use network 
overlays. And together with IPSec there is now a way to control “remote nodes” 
in other physical datacenters (without the need of a dedicated L2 link). We are 
using the file search plugin and Danube Cloud makes sure the “arp table files” 
are correctly distributed across nodes.

I have to say that overlay networking is a very nice piece of technology. 
Especially, I like the possibility of having different search plugins. Thank 
you for that.

For overlays to work, we've made the decision to include a new service into the 
platform - network/virtual, which took over some responsibilities from 
network/physical. It can create overlay rules, overlays, etherstubs and vNICs. 
The idea and the usbkey/config syntax for overlays is explained in the method 
comments: 
https://github.com/erigones/esdc-erigonos-overlay/blob/master/lib/svc/method/net-virtual#L30
 

We’ve tried to implement it in a backward compatible way. Currently the service 
is able to create newly configured vNICs via SMF refresh (without reboot). We 
didn’t change nictagadm, although it would be probably the next logical step.
We think that SmartOS users would benefit from a unified network configuration 
of overlays, etherstubs, and vNICs; What would it take to get it into vanilla 
SmartOS?

For SmartOS users we wrote some basic documentation about overlays and IPSec:
https://github.com/erigones/esdc-ce/wiki/SmartOS-Overlays 

https://github.com/erigones/esdc-ce/wiki/Enabling-IPSec-on-SmartOS 


There is even more documentation in our user guide, e.g.: 
https://docs.danubecloud.org/user-guide/network/overlays.html 
 The IPSec 
troubleshooting guide 
https://docs.danubecloud.org/user-guide/network/debug-ipsec.html 
 is also 
something that a SmartOS user can make use of.

Daniel

> On 29 Nov 2017, at 01:18, Robert Mustacchi  wrote:
> 
> On 10/31/17 2:16 , Daniel Kontsek wrote:
>> Hi,
>> 
>> This post can be considered as continuation of
>> https://www.mail-archive.com/smartos-discuss@lists.smartos.org/msg04922.html 
>> 
>> 
>> Overlay networking in SmartOS is great but the inability to configure them 
>> automatically after boot is a real PITA. We have a proposal of 
>> implementation of overlays persistence using the config file. But before  we 
>> implement it, I want to ask the community - maybe there's already some other 
>> way planned for overlay persistence.
> 
> Hi Daniel,
> 
> Thanks for putting this together. Sorry it's taken a while to get back
> around to this. When I put together the overlay stuff originally I
> wasn't sure how we wanted to expose it and have it make sense.
> 
>> The proposal is described here: 
>> https://github.com/erigones/esdc-factory/issues/85#issuecomment-340701358 
>> 
>> 
>> Basically, the `overlay_="”` from usbkey/config will 
>> be transformed into a valid json in 
>> /var/run/smartdc/networking/overlay_rules.json by network/physical SVC.
> 
> One thing that we've been trying to do with the nic tags and really this
> is just another form of it is to have this be managed by nictagadm. I
> think the config logic is probably alright, but I'd want to make sure
> that we're able to manage it that way and have using nictagadm really be
> the interface for this rather than having folks continue using the tag.
> 
> Cody, what do you think here?
> 
> Robert
> 


signature.asc
Description: Message signed with OpenPGP




---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] Disk size & UFS/FFS VMs

[Jeremy]

I am trying to find the correct docs for this, but when I create FreeBSD or
OpenBSD VMS based on the images from smartos, the HD size does not seem to
grow to what I have provisioned at the time of creation.

The Linux VMs seemed to adjust automatically, but not FreeBSD and OpenBSD.

[ A second question:  Are there any FreeBSD images with ZFS rather than
UFS?  I realize I can use an iso to install it manually, but thought I
would ask ]



---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

[smartos-discuss] problem with mixed up mount points

[Gareth Howell]

This is really a continuation of my previous post on migrating to a new pool 
configuration, but it deserves a new thread.

After the “send/recv, destroy/create, swap names” dance, I have a single disk 
`zones` pool with all the data on it and a new raidz1 pool called `zznew` that 
will become the new `zones` after I have synced it. However, something odd has 
happened somewhere.

Prior to creating `zznew` I just had the single disk `zones` pool. When I 
booted, the kernel panicked and the system reset. After examining the pool in 
recovery mode, all seemed well but I couldn’t get anywhere because I can only 
use the console and the error messages zoom past too fast to read. (It did try 
to save a dump log but that failed as well).

To make progress, I removed the single disk pool and did a clean install using 
a newly created raidz1 pool. I could then import the bad pool, but again I 
could see no problems.

I was moving towards having to do a reverse copy from the imported zone to the 
running zone but before I did so, I tried swapping the pool names. i.e. a 
single disk `zones` and a “runnable” raidz1 `zznew` pool. The system booted to 
my surprise.

Looking at the mount points etc showed the following

root@deneb ~ $ zfs list
NAME   USED  AVAIL  REFER  
MOUNTPOINT
zones 2.67T   863G   588K  /zones
zones/archive  152K   863G88K  none
…
zones/config   468K   863G   196K  legacy
zones/cores250M   863G88K  none
…
zones/cores/global 152K  10.0G88K  
/zones/global/cores
…
zones/dump 260K   863G   140K  -
…
zones/opt 2.50T   863G  1.20G  legacy
…
zones/swap33.2G   896G   246M  -
zones/usbkey   196K   863G   132K  legacy
zones/var 1.05G   863G  1.03G  legacy
zznew 37.6G  3.47T  1018K  /zznew
zznew/archive  117K  3.47T   117K  
/zznew/archive
zznew/config   139K  3.47T   139K  legacy
zznew/cores234K  3.47T   117K  none
zznew/cores/global 117K  10.0G   117K  
/zznew/global/cores
zznew/dump1.84G  3.47T  1.84G  -
zznew/opt 2.88G  3.47T  2.88G  legacy
zznew/swap32.9G  3.50T  74.6K  -
zznew/usbkey   261K  3.47T   261K  legacy
zznew/var 3.91M  3.47T  3.91M  
/zznew/var

root@deneb ~ $ zfs mount
zones   /zones
…
zznew   /zznew
zznew/archive   /zznew/archive
zznew/cores/global  /zznew/global/cores
zznew/var   /zznew/var
zznew/config/etc/zones
zznew/opt   /opt
zznew/usbkey/usbkey

I deleted some irrelevant bits and highlighted the problems. The system is 
mounting some datasets from zznew as if they are from zones.

Any ideas on how to correct this so that /etc/zones, /opt and /usbkey mount 
from zones rather than zznew?

Gareth


signature.asc
Description: Message signed with OpenPGP




---
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com