[OmniOS-discuss] ANNOUNCEMENT omnios-discuss is moving to topicbox

[Tobias Oetiker]

Dear OmniOS Friends

It's been 18 months now since we started the OmniOS Community Edition and with 
the third stable release under our belt we are finalising the transfer of the 
remaining services from OmniTI.

To that end, the existing OmniOS mailing lists (including this one) will be 
closed down at the end of December.

With thanks to Topicbox and the illumos project, we have a new omnios-discuss 
list which can be found at:

https://illumos.topicbox.com/groups/omnios-discuss

Subscriptions to this list will NOT be transferred automatically so please head 
over there to subscribe.

We also have a new Newsletter mailing list for keeping up to date with the 
latest news; you can subscribe to that at:

http://eepurl.com/dL1z7k

cheers
tobi

-- 
Tobi Oetiker
t...@omniosce.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOSce r151028 with production ready Bhyve hypervisor released.

[Tobias Oetiker]

OmniOSce - r151028 - released
=

New Features


The OmniOSce team and the illumos community have been very active in creating 
new features and improving existing ones over the last 6 months. Highlights of 
this new release include:

* Production-ready Bhyve hypervisor. For years, OmniOS has provided a linux kvm 
based hypervisor. With this release, we are adding a second option. The bhyve 
hypervisor from the BSD world has been made a first class illumos component 
through the combined efforts of Pluribus networks and Joyent with extra help 
from the FreeBSD community. It provides massively faster disk and network io 
than the kvm hypervisor as it does not rely on qemu emulation for these 
services but comes with a super optimised native driver implementation.

* Branded zones for bhyve and KVM virtual machines. Running a virtual machine 
inside a zone provides an additional layer of security as any success in 
breaking out of the virtual machine container will only result in access to the 
branded zone which itself guarantees strong isolation from the global zone. On 
top of added security, zones also provide protection against hyper-threading 
attacks such as L1TF and Portsmash, and allow strict resource controls for cpu, 
disk and network access. Our website contains documentation 
(https://omniosce.org/info/bhyve_kvm_brand) on how to make use of these new 
zone types.

* ZFS support for mounting filesystems in parallel. This significantly improves 
boot time for systems with many filesystems.

* All userland tools are now compiled with gcc7 and several 32-bit only 
packages have been moved to 64-bit only.

* Many packages have been updated to newer releases like Python 3.5, Perl 5.28, 
OpenSSL 1.1. And developers can now start using gcc 8 on OmniOS.


New Hardware Support


* Emulex 31000/32000-based Fibrechannel cards.
* ATTO Celerity FC-162E Gen 5 and Celerity FC-162P Gen 6 Fibrechannel cards.
* QLogic 16Gb/s Gen5/6 fibrechannel cards.
* QLogic QL41000/45000 series devices.
* NVMe 1.3 devices.
* SMB access to some HP scanner models.

OmniOSce Newsletter
---

Since the start of OmniOS Community Edition project, we have predominantly 
announced our new releases via twitter. With r151028 we are now also offering a 
newsletter with announcements of updates, bug fixes and new releases. You can 
subscribe here http://eepurl.com/dL1z7k

Release Notes and Upgrade Instructions
--

This is only a small selection of the new features, and bug fixes in the new 
release; review the release notes at https://omniosce.org/releasenotes for full 
details and find upgrade instructions at https://omniosce.org/upgrade

Commercial Support
---

Have you ever wondered how OmniOS development gets financed? You may have 
noticed that there is no big company bankrolling it all. The way we keep afloat 
is by the companies who rely on OmniOS powered servers taking out support 
contracts for their hardware. How about you? Visit https://omniosce.org/support 
for more details and to generate a quote. If you aren’t in a position to take a 
support contract, please consider becoming an OmniOS patron to help secure its 
future - https://omniosce.org/patron.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Slow NFS writes in 151026

[Tobias Oetiker]

Hi All,

Lee has opened a issue here 
https://github.com/omniosorg/illumos-omnios/issues/256
it might be a good place to discuss this.

I have also posted a very simple tests script (not sure if it is enough to 
reproduce the problem, but it would at least give a common baseline as to what 
we are talking about).

cheers
tobi

- On Aug 24, 2018, at 10:07 AM, Adam Feigin fei...@iis.ee.ethz.ch wrote:

> Hi Lee:
> 
> 
> I've been experiencing something very similar. I recently (several
> months ago) moved a ~30T pool from a "old" OpenIndiana 151a9 system ,
> where it had been working flawlessly for several years, to a "new"
> OmniOSce 151022 installation (zpool export on old, zpool import on new).
> 
> 
> Now, I have extremely poor NFS write speeds on the new system. I've even
> swapped the cards (LSI SAS, 10G Ethernet) from the OI system to the
> OmniOS system, to eliminate some hardware discrepancies, but this had no
> effect whatsoever. Its not a network problem. I can happily get near
> line-rate on the 10G network between the server and various 10G
> connected hosts. Its not a ZIL/L2ARC problem either, removing them
> (they're on SSDs, as yours) had minimal effect.
> 
> 
> The new hardware is signifcantly more performant, with nearly 10x more
> memory (240G vs 32G), more cores and faster CPUs; I never expected
> performance to get worse.
> 
> 
> I'm not convinced its a "pure" NFS problem either, as I've noticed some
> other strange performance degradation on the new system. The pool used
> to take somewhere between 40 - 60 hours to run a scrub on the OI system.
> Recent scrubs were taking 400+ hours. After a recent pkg update and
> reboot, the last scrub took ~159 hours. During the scrub, I noticed that
> the scanning speed, while starting out relatively fast, pretty much
> monotonically decreased in speed as time when on, going from 50 M/s near
> the beginning to 17M/s at the end. I have to see what happens at the
> next monthly scrub of the pool.
> 
> 
> Have you looked at your scrub performance ?
> 
> What else is different between the 2 machines ?
> 
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS CE Support Contracts - Quotes

[Tobias Oetiker]

Hi All 

As mentioned last week, the OmniOS CE association is now offering a Support 
Package for organizations using OmniOS on their servers. 

Since many institutions need to get a quote first, in order to initiate 
payments, we have enhanced our invoice generator with a new 'quote' function. 

https://omniosce.org/invoice 

according to our statistics, we have now at least 500 servers running under 
omniosce which are downloading regular updates from our repos. 
if a decent number of them got a support package, this would go a long way in 
making omnios ce long-term viable also from a financial standpoint. 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS New Homepage https://www.omniosce.org

[Tobias Oetiker]

If you want to explain to someone why OmniOSce is cool ... 

Now you CAN point them to our homepage without further confusing them :-) 

They might actually understand ... https://www.omniosce.org 

cheers 
tobi 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Finally - OmniOSce Commercial Support

[Tobias Oetiker]

After getting the release process up and running smoothly, the OmniOSce 
Association is finally ready to start that long awaited Commercial Support 
offering: 

Are you running your Servers on OmniOS Community Edition? Would you like to 
ensure you are not left alone if you run into trouble with the devices? Would 
you like to ensure the continued maintenance and development of your favorite 
OS? 

Go to our website and request an invoice to get your Organisation started on a 
new OmniOS support contract: 

https://www.omniosce.org/invoice 

cheers 
tobi oetiker 

OmniOSce Association 
Aarweg 17, 4600 Olten, Switzerland 

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: Re: Investing into the Future of OmniOS Community Edition

[Tobias Oetiker]

Hi All

Over the last few days we got several suggestions on the income front.
These are the things we are looking into at the moment:

* Invoice generator: To create a downloadable invoice
  for a OmniOS CE voluntary License (ideas for a good name welcome)
  You will be able to specify your address and the invoice amount

* Gold/Silver/Bronce Sponsorship contracts where your logo will be shown
  on our the website.

* Genuine Support Contracts where we will help you with your OmniOS issues.

details to come.

cheers
tobi 

- On Nov 28, 2017, at 2:20 PM, Johan Kragsterman 
johan.kragster...@capvert.se wrote:

> Hi!
> 
> 
> I believe that is a good way to go, to offer marketing space and perhaps other
> marketing possibilities for the sponsors.
> 
> That is a much preferred option than cutting off the community from certain
> publishers, or other "cut offs", because that would only cause bad blood.
> 
> 
> Best regards from/Med vänliga hälsningar från
> 
> Johan Kragsterman
> 
> Capvert
> 
> 
> 
> -"OmniOS-discuss" <omnios-discuss-boun...@lists.omniti.com> skrev: -
> Till: omnios-discuss@lists.omniti.com
> Från: Guenther Alka
> Sänt av: "OmniOS-discuss"
> Datum: 2017-11-28 14:00
> Ärende: Re: [OmniOS-discuss] Investing into the Future of OmniOS Community
> Edition
> 
> hello Tobias
> 
> During a contact with a storage systemhouse that intends to offer OmniOS
> as an additional storage OS, I asked about sponsoring of OmniOS ce and I
> was asked if there would be an option of something like a
> gold/silver/bronce patron to bepublished on the patron page.
> 
> 
> Gea
> 
> 
> Am 27.11.2017 um 13:52 schrieb Tobias Oetiker:
>> Hi Stephan, Hi Guenther
>>
>> the proforma invoice, yes we will look into that ... what we also discussed 
>> is
>> offering some repo with pre compiled packages for a fee. but we are not there
>> yet. still trusting that users realize that omnios does not create itself out
>> of thin air. applying some business logic and risk analysis should make this
>> abundantly clear to most people with business responsibilities.
>>
>> cheers
>> tobi
>>
>> - On Nov 27, 2017, at 10:52 AM, Stephan Budach stephan.bud...@jvm.de 
>> wrote:
>>
>>> +1
>>>
>>> Cheers,
>>> Stephan
>>>
>>> - Ursprüngliche Mail -
>>>> Von: "Guenther Alka" <a...@hfg-gmuend.de>
>>>> An: "omnios-discuss" <omnios-discuss@lists.omniti.com>
>>>> Gesendet: Montag, 27. November 2017 10:15:47
>>>> Betreff: Re: [OmniOS-discuss] Investing into the Future of OmniOS Community
>>>> Edition
>>>>
>>>> hello Tobias
>>>>
>>>> A pure donation modell (pay for something that is available for free)
>>>> is
>>>> only ok for small amounts from private persons.
>>>>
>>>> Can this be extended by
>>>> - a function to request a quotation with a given amount together with
>>>> a
>>>> (pro forma) invoice online what makes institutional/edu payments
>>>> possible
>>>> (to accept this quotation, pay the amount until..)
>>>>
>>>> - with some sort of an extra offer over the free offerings
>>>> maybe a Pro subscription to beta/ bloody releases, a knowledgebase or
>>>> a
>>>> plus repository
>>>>
>>>> Gea
>>>>
>>>>
>>>> Am 26.11.2017 um 23:31 schrieb Tobias Oetiker:
>>>>> Hi All
>>>>>
>>>>> tl;tr? head over to https://omniosce.org/patron and support your
>>>>> favorite OS with a regular donation.
>>>>>
>>>>> Since the OmniOS Community Edition Association has taken over
>>>>> maintenance and care of OmniOSce, things have been moving at a
>>>>> brisk pace.
>>>>>
>>>>> * Upstream changes from Illumos and Joyent are integrated weekly
>>>>> into our github repo.
>>>>>
>>>>> * Security fixes are normally available within hours.
>>>>>
>>>>> * We have committed to an elaborate long term release plan.
>>>>>
>>>>> * In early November we have released OmniOS r24 on schedule with
>>>>> many enhancements.
>>>>>
>>>>> * Our new website has a lot of new content on feeding and care
>>>>> of your OmniOS instance.
>>>>>
>>>>> Judging f

Re: [OmniOS-discuss] Investing into the Future of OmniOS Community Edition

[Tobias Oetiker]

Hi Stephan, Hi Guenther

the proforma invoice, yes we will look into that ... what we also discussed is 
offering some repo with pre compiled packages for a fee. but we are not there 
yet. still trusting that users realize that omnios does not create itself out 
of thin air. applying some business logic and risk analysis should make this 
abundantly clear to most people with business responsibilities.

cheers
tobi

- On Nov 27, 2017, at 10:52 AM, Stephan Budach stephan.bud...@jvm.de wrote:

> +1
> 
> Cheers,
> Stephan
> 
> - Ursprüngliche Mail -
>> Von: "Guenther Alka" <a...@hfg-gmuend.de>
>> An: "omnios-discuss" <omnios-discuss@lists.omniti.com>
>> Gesendet: Montag, 27. November 2017 10:15:47
>> Betreff: Re: [OmniOS-discuss] Investing into the Future of OmniOS Community
>>  Edition
>> 
>> hello Tobias
>> 
>> A pure donation modell (pay for something that is available for free)
>> is
>> only ok for small amounts from private persons.
>> 
>> Can this be extended by
>> - a function to request a quotation with a given amount together with
>> a
>> (pro forma) invoice online what makes institutional/edu payments
>> possible
>> (to accept this quotation, pay the amount until..)
>> 
>> - with some sort of an extra offer over the free offerings
>> maybe a Pro subscription to beta/ bloody releases, a knowledgebase or
>> a
>> plus repository
>> 
>> Gea
>> 
>> 
>> Am 26.11.2017 um 23:31 schrieb Tobias Oetiker:
>> > Hi All
>> >
>> > tl;tr? head over to https://omniosce.org/patron and support your
>> > favorite OS with a regular donation.
>> >
>> > Since the OmniOS Community Edition Association has taken over
>> > maintenance and care of OmniOSce, things have been moving at a
>> > brisk pace.
>> >
>> >* Upstream changes from Illumos and Joyent are integrated weekly
>> >into our github repo.
>> >
>> >* Security fixes are normally available within hours.
>> >
>> >* We have committed to an elaborate long term release plan.
>> >
>> >* In early November we have released OmniOS r24 on schedule with
>> >many enhancements.
>> >
>> >* Our new website has a lot of new content on feeding and care
>> >of your OmniOS instance.
>> >
>> > Judging from the 566 systems that have been switched over to our
>> > new repos, downloading regular updates, we think there is ample
>> > interest in OmniOS. Not even taking into account all those who
>> > have not yet upgraded.
>> >
>> > With the release of OmniOSce r24 we have created the OmniOS Patron
>> > Page where you can set up regular contribution or a one time
>> > donation to the project.
>> >
>> > Unfortunately only very few people have yet made the step of
>> > actually pledging funds. According to the straw poll conducted in
>> > spring, there should be at least 80k USD per year available to
>> > those who maintain and release updates for  OmniOS.
>> >
>> > At the moment we are getting about 25 USD per month from 4
>> > individuals. This is pretty bleak and does not even begin to cover
>> > the cost of running the show and certainly does not allow us to
>> > plan for the future.
>> >
>> > Head over to https://omniosce.org/patron and let us know how much
>> > you value OmniOS and our work. If everybody spent just 20 dollar
>> > per system and month things would be looking much brighter
>> > already.
>> >
>> > To put this into perspective: a single O365 Enterprise license
>> > costs 35 USD/month. Most individuals pay a similar amount every
>> > month for the internet connection or mobile phone contract.
>> >
>> > Andy Fiddaman
>> > Dominik Hassler
>> > Tobi Oetiker
>> >
>> > --
>> > OmniOS Community Edition Association
>> > Aarweg 17, 4600 Olten, Switzerland
>> > www.omniosce.org
>> > i...@omniosce.org
>> 
>> --
>> H  f   G
>> Hochschule für Gestaltung
>> university of design
>> 
>> Schwäbisch Gmünd
>> Rektor-Klaus Str. 100
>> 73525 Schwäbisch Gmünd
>> 
>> Guenther Alka, Dipl.-Ing. (FH)
>> Leiter des Rechenzentrums
>> head of computer center
>> 
>> Tel 07171 602 627
>> Fax 07171 69259
>> guenther.a...@hfg-gmuend.de
>> http://rz.hfg-gmuend.de
>> 
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Investing into the Future of OmniOS Community Edition

[Tobias Oetiker]

Hi Alexander,

thanks you for the idea ... I have updated the webpage

IBAN CH22 0900  6188 9767 7
BIC POFICHBEXX
Verein OmniOS Community Edition

If there are other requirements, like us sending invoices or some such,
please let us know. We are trying something new here ...

cheers
tobi


- On Nov 27, 2017, at 12:16 AM, Alexander Lesle gro...@tierarzt-mueller.de 
wrote:

> Guten Abend Tobias Oetiker,
> 
> at https://omniosce.org/patron are no information about the
> payment methods.
> Can you offer for the Europeans your account informations
> IBAN and BIC on this page please.
> 
> --
> Best Regards
> Alexander
> November, 27 2017

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Investing into the Future of OmniOS Community Edition

[Tobias Oetiker]

Hi All

tl;tr? head over to https://omniosce.org/patron and support your favorite OS 
with a regular donation.

Since the OmniOS Community Edition Association has taken over maintenance and 
care of OmniOSce, things have been moving at a brisk pace.

  * Upstream changes from Illumos and Joyent are integrated weekly into our 
github repo.

  * Security fixes are normally available within hours. 

  * We have committed to an elaborate long term release plan. 

  * In early November we have released OmniOS r24 on schedule with many 
enhancements. 

  * Our new website has a lot of new content on feeding and care of your OmniOS 
instance.

Judging from the 566 systems that have been switched over to our new repos, 
downloading regular updates, we think there is ample interest in OmniOS. Not 
even taking into account all those who have not yet upgraded.

With the release of OmniOSce r24 we have created the OmniOS Patron Page where 
you can set up regular contribution or a one time donation to the project.

Unfortunately only very few people have yet made the step of actually pledging 
funds. According to the straw poll conducted in spring, there should be at 
least 80k USD per year available to those who maintain and release updates for  
OmniOS.

At the moment we are getting about 25 USD per month from 4 individuals. This is 
pretty bleak and does not even begin to cover the cost of running the show and 
certainly does not allow us to plan for the future.

Head over to https://omniosce.org/patron and let us know how much you value 
OmniOS and our work. If everybody spent just 20 dollar per system and month 
things would be looking much brighter already. 

To put this into perspective: a single O365 Enterprise license costs 35 
USD/month. Most individuals pay a similar amount every month for the internet 
connection or mobile phone contract.

Andy Fiddaman
Dominik Hassler
Tobi Oetiker

--
OmniOS Community Edition Association
Aarweg 17, 4600 Olten, Switzerland
www.omniosce.org
i...@omniosce.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT: OmniOS Community Edition r151024

[Tobias Oetiker]

OmniOS Community Edition R151024


After 4 months of intense development, the OmniOS Community Edition Association 
is proud to announce the availability of the first Community release of OmniOS; 
version r151024. The release is on schedule (https://www.omniosce.org/schedule) 
coming 6 months after the final OmniTI release of OmniOS back in May.

This new release adds several key improvements to the lx-zones facility 
allowing for lightweight virtualization of GNU/Linux in an illumos environment, 
better zone resource management, new hardware support and all the latest 
updates from upstream illumos; userland packages have also been brought right 
up-to-date. The underlying build system for OmniOS has been enhanced to make 
builds and ongoing maintenance easier; for example the total build time has 
been more than halved, and the addition of automated testing minimises the 
chance for regressions due to updates.

Release notes for the new update are can be found at 
https://omniosce.org/releasenotes and upgrade instructions are at 
https://omniosce.org/upgrade

The web site for OmniOS Community Edition has been updated with all the latest 
information, including new information for deployment, operation and 
development of OmniOS systems.

OmniOS is an enterprise level operating system with long-term support and large 
release overlaps to allow for validation prior to deployment of new releases.

Many organizations rely on OmniOS driven servers for their core storage and 
virtualization environments. As such they want to ensure the continued 
development and support of the OmniOS illumos distribution. It is now possible 
to support the work that goes into maintaining the OS by becoming an OmniOS 
patron, either with a recurring donation or a one time payment 
(https://omniosce.org/patron)

About OmniOS - OmniOS is an Enterprise level illumos-based Operating System 
with superb lightweight virtualization support through zones as well as full 
hardware virtualization via integrated kvm support. Native ZFS support provides 
highly reliable storage options of nearly unlimited capacity. With dtrace it is 
possible to instrument virtually any part of the OS to provide highly precise 
debugging information to resolve performance issues and software failures.

About OmniOS Community Edition Association - The OmniOS Community Edition 
Association has taken up development and care of OmniOS since Summer 2017 after 
OmniTI announced their withdrawal from the project.

OmniOSce Association 
Aarweg 17, 4600 Olten, Switzerland
i...@omniosce.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT OmniOS 151022s (Security Update)

[Tobias Oetiker]

Release Notes for OmniOSce 151022s
--

Early weekly release for w/c 25th of September 2017, uname -a shows 
omnios-r151022-eb9d5cb557 

Since this release contains security fixes we urge people to upgrade as soon as 
possible.

** This update requires a reboot. **

* Security updates for in-kernel CIFS client & server 

  * 8662 SMB server ioctls should be appropriately sized 
  * 8663 SMB client assumes serialized ioctls 

* Perl fixes: 

  * CVE-2017-12837
  * CVE-2017-12883

* Other changes 

  * 8651 loader: fix problem where No rootfs module provided, aborting could 
appear on some systems. 
  * IPsec observability improvements. 


Instructions for updating from OmniTI OmniOS r151022 are available on our web 
site 
http://www.omniosce.org/setup/switch

Full Release Notes
https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md

Due to the fix to the loader, new release media will be built for this release 
and will be available tomorrow.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT - OmniOS r151022o - Security Update!

[Tobias Oetiker]

OmniOS Community Edition is releasing OmniOS r151022o with a bunch of security 
fixes: 

libxml2 fixes for: 

* CVE-2016-4658 
* CVE-2016-5131 
* CVE-2017-0663 
* CVE-2017-5969 
* CVE-2017-9047 
* CVE-2017-9048 
* CVE-2017-9049 
* CVE-2017-9050 

bzip2 fix for (we have announced this one separately already): 

* CVE-2016-3189 

This release also contains an update for java to to OpenJDK 1.7.0_141-b02 

This release does NOT require a reboot. 

Full release notes can be found at 

https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md 

cheers 
tobi 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT: OmniOSce Release Schedule

[Tobias Oetiker]

In response to our call for someone to step up to take over responsibility to 
maintain OmniOS LTS releases we received a number of detailed responses, but 
only from people interested in using the product and none who wanted to help 
maintain it. 

After careful consideration of all the input, the OmniOSce Association has 
decided to continue maintaining LTS releases of OmniOSce. LTS releases will be 
supported for three years with intervening stable releases being supported for 
one year. LTS releases will therefore overlap for a year to allow time for 
validation and upgrade even in complex environments. Regular stable releases 
will overlap for six months. 

This results in the following release schedule with r151024 being targeted for 
the first week of November 2017. 


cheers tobi 
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT - OmniOS r151022m - Security Update!

[Tobias Oetiker]

OmniOS Community Edition is releasing OmniOS r151022m three days early as this 
is an urgent security release. The release contains new versions of git and hg 
to fix

CVE-2017-1000117
CVE-2017-1000116
CVE-2017-1000115

see http://blog.recurity-labs.com/2017-08-10/scm-vulns for details 
on the vulnerabilities.

This release does NOT require a reboot.

Full release notes can be found at 

https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md

To upgrade, utter:

$ pkg update -r

You can also just upgrade the packages

$ pkg update -r git mercurial

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT OmniOSce r151022l

[Tobias Oetiker]

Dear All 

This is the weekly update for w/c 7th of August 2017 and contains NO security 
updates but several bugfixes from upstream illumos and joyent lx. For this 
update, a reboot is required. 

We are aware that system reboots pose a problem for many sites, so we are 
investigating ways to reduce the requirements of reboots associated with update 
releases of OmniOSce. More on this next week. 

Any problems or questions, please get in touch via the Lobby at 

https://gitter.im/omniosorg/Lobby 

Full release notes can be found at 

https://github.com/omniosorg/omnios-build/blob/r151022/doc/ReleaseNotes.md 

To upgrade, utter: 

pkg update -r --be-name=r151022l 

cheers 
tobi 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS CE question: will there be a LTS stable release?

[Tobias Oetiker]

Hi Chris,

we have discussed this in the core team and found that no one of us has been
using LTS until now and no one is planning to do so in the future ... 

What we intend, is to support the current and previous release with an emphasis
on the current release going forward from r151022. 

That said, maybe someone will step up and take up the LTS mantel.
The build process for r151022 is in better shape than ever, now that Andy and
Dominik have lavished all that love on it.

SO if this is of interest to you, we will be glad to hear your ideas and also
help out if someone wants to step up. Let's discuss in 
https://gitter.im/omniosorg/Lobby

cheers
tobi

- On Jul 25, 2017, at 11:59 PM, Chris Siebenmann c...@cs.toronto.edu wrote:

> The OmniOS CE release announcement here on the mailing list covered
> the broad plans for the (non-Bloody) release schedule:
> 
>   The intention is for new stable releases to continue to come
>   out every 26 weeks. Interim, "weekly" updates to stable follow a
>   fixed schedule denoted by letters, one per week. Weekly releases
>   are made as needed, so there may not be a release each week. [...]
> 
> My assumption is that normally, each regular stable release only
> receives updates until the next regular stable release comes out; when
> the next stable release comes out, you are expected to update to it and
> then start tracking the interim weekly updates to the new stable.  This
> raises two closely related questions:
> 
> First, is this understanding of updates to stable releases accurate?
> 
> Second, if it is, are there any plans for a 'LTS' stable release with
> an extended period of at least security updates for that LTS release?
> Is this in fact the current r151022 release, which I've seen some CE
> messages describe as 'OmniOS r151022 LTS' (eg in the announcement of
> r151022i)?
> 
> Thanks in advance, and my apologies if I've overlooked a discussion
> of this on the mailing list (or a mention of this on the OmniOS CE
> website).
> 
>   - cks
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT First OmniOSce Bloody Update

[Tobias Oetiker]

OmniOSce Bloody 

With the urgent security updates and bug fixes for r151022 out of the way we 
have spent the last week concentrating on getting bloody updated, including new 
ISO, USB and PXE images. In addition to bringing us up-to-date with the latest 
from illumos, we have also bumped many of the userland packages to their latest 
released versions. They’ve passed initial regression testing, but we could use 
your help in putting them through their paces a bit more, so if you have some 
spare cycles please grab the ISO and set up a bloody system for testing. 
Downloads can be found at https://downloads.omniosce.org/media/bloody/ 

We have also started enabling test suites for userland packages where one is 
available in the hope of catching more regressions early and automatically. 
This release also contains the first core bugfix in OmniOSce history. We got a 
report to our issue tracker that both lx and native zones were not shutting 
down properly. Andy quickly identified the likely culprit and backed out the 
offending commit and published an updated within hours. 

If you have not visited our website at http://www.omniosce.org/ lately, it 
looks much better now than a few days ago and it comes with much more content. 
We already integrated two contributions from Rich Murphey @rich-murphey (thank 
you). If you would also like to contribute, please send us your pull requests 
... the source of the website btw is on 

https://github.com/omniosorg/omniosorg.github.com

bloody update 20170721: 

uname -v shows omnios-master-fab442e53b 

Updated packages: 

iso-codes 3.74 -> 3.75 
sqlite 3.3.18 -> 3.19.3 
automake 1.15.0 -> 1.15.1 
git 2.13.0 -> 2.13.3 
mercurial 4.1.3 -> 4.2.2 
vim 8.0.567 -> 8.0.586 
expat 2.2.0 -> 2.2.2 
nghttp2 1.21.1 -> 1.24.0 
pcre 8.40 -> 8.41 
openssl 1.0.2k -> 1.0.2l 
bind 9.10.4P8 -> 9.10.5P3 
openssh 7.4p1 -> 7.5p1 
sudo 1.8.7 -> 8.20.2 
pipe-viewer 1.6.0 -> 1.6.6 
dbus 1.11.12 -> 1.11.14 
ipmitool 1.8.16 -> 1.8.18 
pciutils 3.5.4 -> 3.5.5 
screen 4.5.1 -> 4.6.1 
tmux 2.3 -> 2.5 
gnu-diffutils 3.5 -> 3.6 

cheers 
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h

[Tobias Oetiker]

# OmniOS Community Edition 

On April 21st 2017, OmniTI announced that they would suspend active development 
of OmniOS and support contracts would not be renewed. 

While this announcement left many users stunned, others focused more on the 
fact that OmniTI in their announcement also expressed the hope that "the 
community" would take up further development of the OS. 14 weeks later, OmniOS 
Community Edition is a reality. 

Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and Dominik 
Hassler have spent some quality time setting up the systems and procedures 
allowing us to take over maintenance and development of OmniOS. In this 
endeavour we were supported by many. Special thanks to Stefan Husch 
(www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and Theo 
Schlossnagle (www.circonus.com). 

We have forked the OmniOS repos and pulled in bugfixes and security fixes that 
have been published since the release of OmniOS r151022. After setting up our 
own package repository and updating the build infrastructure, we are finally 
ready to go public. We are following the established OmniOS release naming 
scheme by releasing 


## OmniOSce r151022h, 12th July 2017

The new release contains the following fixes: 

- expat updated to version 2.2.1 (fixes CVE-2017-9233) 
- openssl updated to version 1.0.2l 
- curl updated to version 7.54.1 
- bind updated to version 9.10.5-P3 
- p7zip updated to fix CVE-2016-9296 
- web/ca-bundle updated to include OmniOSce Certificate Authority certificate 

`uname -a` shows omnios-r151022-f9693432c2 (no change in this release) 

Our work does not stop here though. First we are committed to quickly releasing 
updates for r151022 as the need arises. We are also working towards releasing 
r151024 on schedule. To that end, we have already updated the bloody 
environment with all the latest goodies from upstream illumos and joyent-lx 
repositories. 

OmniOS community edition hosts its sources on https://github.com/omniosorg/ and 
if you want to get in touch, you can find us on 
https://gitter.im/omniosorg/Lobby 


## Release Schedule 

The intention is for new stable releases to continue to come out every 26 
weeks. Interim, "weekly" updates to stable follow a fixed schedule denoted by 
letters, one per week. Weekly releases are made as needed, so there may not be 
a release each week. The first release of a new stable version is synonymous 
with weekly release "a", though the letter is not used. 

During the intervals between stable releases, Bloody moves forward rapidly, 
picking up changes from upstream illumos-gate and illumos-joyent as well as 
updating various userland packages. In general, upstream merges will be 
performed on a Thursday/Friday each week and weekly releases will be published 
on a Monday. 

Bloody releases will be published on an ad-hoc basis but may be as frequent as 
every week. 

Security fixes are excluded from the schedule and handled with priority as they 
occur. 


## How to Upgrade 

All OmniOS packages are signed and the pkg installer is configured to only 
allow trusted sources for the core packages. In order to upgrade to the new 
OmniOS community edition, you have to let your box know that the updates will 
be coming from a new trusted source. This means you will have to import our CA 
certificate into your system. 

1. Get a copy of the new certificate 

```
# /usr/bin/wget -P /etc/ssl/pkg \
https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem 
```

2. Check the certificate fingerprint 

```
# /usr/bin/openssl x509 -fingerprint \
-in /etc/ssl/pkg/omniosce-ca.cert.pem -noout 
```

`8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D`


3. Change the publisher to our new repo 

```
# /usr/bin/pkg set-publisher -P \
   -G https://pkg.omniti.com/omnios/r151022/ \
   -g https://pkg.omniosce.org/r151022/core/ omnios 
```

4. For each native zone (if you have any), run 

```
# /usr/bin/pkg -R  set-publisher -P \
   -G https://pkg.omniti.com/omnios/r151022/ \
   -g https://pkg.omniosce.org/r151022/core/ omnios 
```

(get a list of all your zones by running `zoneadm list -cv` for the 
``, add `/root` to the PATH given in the list.) 


5. Install the new ca-bundle containing our new CA 

```
# /usr/bin/pkg update -rv web/ca-bundle 
```

6. Remove the CA file imported by hand 

```
# rm /etc/ssl/pkg/omniosce-ca.cert.pem 
```

7. Finally update as usual 

```
# /usr/bin/pkg update -rv 
```


## About OmniOS Community Edition Association 

OmniOS Community Edition Association (OmniOSce) is a Swiss association, 
dedicated to the continued support and release of OmniOS for the benefit of all 
parties involved. The board of OmniOSce controls access to the OmniOS CA. 
Current board members are: Tobias Oetiker (President), Andy Fiddaman 
(Development), Dominik Hassler (Treasurer). 


## About Citrus-IT 

Citrus IT is a UK company that provides a managed email service platform 

Re: [OmniOS-discuss] Questions about - End the uncertainty -

[Tobias Oetiker]

Hi Aurélien, 

- On Jul 7, 2017, at 7:55 AM, Aurélien Larcher <aurelien.larc...@gmail.com> 
wrote: 

> On Fri, Jul 7, 2017 at 7:21 AM, Tobias Oetiker < [ mailto:t...@oetiker.ch |
> t...@oetiker.ch ] > wrote:

>> Hi Aurélien

>> the motivation behind OmniOSce is that we have come to love the the stability
>> and
>> tight focus of OmniOS. Many of us are running large servers that form 
>> critical
>> pieces of our infrastructure. Loosing OmniOS was simply not an option for us.
>> Since OmniTI gave up on this we were forced start doing the work on our own.

> Your answer makes me think I was not clear enough or that we are discussing 
> two
> different things ...
> My point was about collaboration not about losing what you like.

nothing against collaboration, on the contrary ... when looking at omnios now 
(with the focus of it being a server os) 
what do you see that is missing which oi folks could contribute, or which we 
could 
pull from oi ? 

>> we are happy for anyone to join us in our effort, for example also in 
>> providing
>> a more end user focussed repo that goes along with omnios, providing a 
>> desktop
>> environment for those who want to use the os in that capacity.

> If we want another general-purpose distro with 2 maintainers and 10 users 
> that's
> certainly the way to go ;)

we are not general purpose in that sense. 

cheers 
tobi 

>> [ http://www.omniosce.org/ | www.omniosce.org ]
>> [ http://gitter.im/omniosorg/Lobby | gitter.im/omniosorg/Lobby ]

>> Tobias Oetiker

>> On 7 Jul 2017, at 01:47, Aurélien Larcher < [ 
>> mailto:aurelien.larc...@gmail.com
>> | aurelien.larc...@gmail.com ] > wrote:

>>>> Gea,

>>>> the king is dead, long live the king

>>>> [ https://gitter.im/omniosorg/Lobby | https://gitter.im/omniosorg/Lobby ]

>>>> [ http://www.omniosce.org/ | www.omniosce.org ]

>>>> the story continues ...

>>> It is good news, but I would engage you to discuss about reducing the
>>> fragmentation in the illumos community.
>>> We have a few distros maintained by 1-3 guys without any or much momentum 
>>> and
>>> much duplication of efforts (Debian has 1000+ devs working together and we 
>>> are
>>> barely able to have more than 10).

>>> We should join our efforts like, as I suggested, basing on common tools and
>>> userland.
>>> I do not see how wasting energy in duplicate efforts will help us keep/gain
>>> momentum.
>>> I mentioned earlier the possibility of a virtuous circle with OI as the 
>>> rolling
>>> testing and OmniOS the stable: to be honest I see very little sense in
>>> maintaining two "testing" with such a small manpower. In the long term this
>>> does not seem sustainable.

>>> At least some degree of collaboration should be maintained on documentation,
>>> pkg(5) and updates of Python/Perl/GCC with the same source repository.

>>> Of course this is not "right now", as you need to maintain continuity, but 
>>> we
>>> should plan the next 6 month cycle to decide on common requirements and 
>>> make it
>>> happen.
>>> I saw Peter has built illumos-omnios on Tribblix, I think we should do the 
>>> same
>>> on OpenIndiana: the issue is not about doing it once (I did it last year) 
>>> but
>>> having a person commited to maintain it.

>>> Convergence is necessary, at least to some extent, discussion is open. :)

>>> Kind regards

>>> Aurélien

>>>> cheers
>>>> tobi

>>>> - On Jul 5, 2017, at 4:05 PM, Guenther Alka < [ 
>>>> mailto:a...@hfg-gmuend.de |
>>>> a...@hfg-gmuend.de ] > wrote:

>>>>> about OmniOS and the silence for weeks

>>>>> For my own future, I have already decided to switch back to OpenIndiana, 
>>>>> the
>>>>> community based sister project of OmniOS. But like many users, I have yet
>>>>> OmniOS installations running perfectly. For them, it is essential to ask 
>>>>> about
>>>>> the future for the next months or year and needed next steps (can wait 
>>>>> some
>>>>> time or switch as soon as possible).

>>>>> @ OmniTi
>>>>> The end of OmniOS@OmniTi seems final.

>>>>> - How long will the website and the repo remain online?

>>>>> - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for
>>>>> a limited time like 1 year or at least end of the year?

>&g

Re: [OmniOS-discuss] Questions about - End the uncertainty -

[Tobias Oetiker]

Gea, 

the king is dead, long live the king 

https://gitter.im/omniosorg/Lobby 

www.omniosce.org 

the story continues ... 

cheers 
tobi 

- On Jul 5, 2017, at 4:05 PM, Guenther Alka  wrote: 

> about OmniOS and the silence for weeks

> For my own future, I have already decided to switch back to OpenIndiana, the
> community based sister project of OmniOS. But like many users, I have yet
> OmniOS installations running perfectly. For them, it is essential to ask about
> the future for the next months or year and needed next steps (can wait some
> time or switch as soon as possible).

> @ OmniTi
> The end of OmniOS@OmniTi seems final.

> - How long will the website and the repo remain online?

> - Is there an option to fix serious bugs or problems in OmniOS @OmniTi for
> a limited time like 1 year or at least end of the year?

> - Are you willing to transfer the website/name either to a new OmniOS 
> community
> project (I cannot see this as an option regarding the silence about) or to the
> OpenIndiana community to use it as a name for a possible stable like
> OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is
> willing to go that route but the request or offer must come from OmniTi or
> OmniOS people).

> OmniOS has a very strong reputation regarding production quality and 
> stability,
> so such a step would help both if OpenIndiana and OmniOS would cooperate in a
> common project. Seems a pity if the name would die or remain as a name for a
> failed project.

> @OmniOS developers (current or former - you have done a very good job!)

> - Is there an option to fix serious bugs or problems in OmniOS for a limited
> time like 1 year or at least end of the year? This would help until a sucessor
> (less likely OmniOS 151024 , maybe next OpenIndiana snap with a stable subset)
> is available. LX would then remain an OmniOS option in the meantime (I would
> not dare to ask about an upstream).

> @all
> comments?

> Gea
> @napp-it.org

> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

[Tobias Oetiker]

- On Jul 2, 2017, at 12:09 PM, Andy Fiddaman omn...@citrus-it.net wrote:

> On Thu, 29 Jun 2017, Guenther Alka wrote:
> 
> ; Unless there are news regarding OmniOS my stance is
> ;
> ; - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the
> ; most stable and feature rich free Illumos general use server distribution 
> with
> ; the addition LX zones. As there is no repo and development outside OmniTi it
> ; is freezed. There are no signs from OmniTi to add any fixes. As packages are
> ; signed it does not work outside OmniTi. As OmniOS 151023 is identical 
> without
> ; signed packages a community based repo based on it with possible fixes as
> ; 151022ce (community edition) is a suggestion (but sadly I am not an OS
> ; developer).
> 
> Momentum does appear to be lacking unfortunately. Here at Citrus we have
> forked the OmniOS repositories and are continuing to maintain them for
> internal use while we consider options.
> 
> We have kept omnios-build packages up-to-date where there are security
> fixes (two Bind updates, 7-zip CVE patch, OpenSSL [IIRC]) and backported a
> handful of illumos changes that are relevant to us. We can keep going like
> this for a good while and I still hope that a community OmniOS will get
> going (we've offered to contribute engineering resource as have others)
> and we can make the switch.
> 
> Since we use LX zones to an extent, SmartOS is the other route we are
> evaluating at the moment.
> 


not to join forces seem to be a pitty ... how about hosting that fork on
https://github.com/omniosorg and starting to accept PRs there

at least from what I can see there is a total lack of communication from omniti
regarding how they envision that transition of omnios to community 
maintainership

so I guess we have to take the initiative.

I have had a look at smartos, for kvm and lx it would be great but it seems 
that serving smb, nfs and iscsi
is not a focus on joyents side (but maybe I have just not looked correctly).

there is a gitter chat associated with the github omniosorg repo
https://gitter.im/omniosorg/Lobby



cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Loosing NFS shares

[Tobias Oetiker]

Oliver, 

are you running rcapd ? we found that (at least of the box) this thing wrecks 
havoc to both 
nfs and iscsi sharing ... 

cheers 
tobi 

- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann 
 wrote: 

> Hi,

> we are using OmniOS for a few months now and have big trouble with stability. 
> We
> mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS
> datastores and VMs stopped running. I noticed that even though zfs get 
> sharenfs
> shows folders as shared they become inaccessible. Setting sharenfs to off and
> sharing again solves the issue. I have no clue where to start. I’m fairly new
> to OmniOS.

> Any help would be highly appreciated.

> Thanks and Best Regards,

> Oliver

> Oliver Weinmann
> Senior Unix VMWare, Storage Engineer

> Telespazio VEGA Deutschland GmbH
> Europaplatz 5 - 64293 Darmstadt - Germany
> Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
> [ mailto:oliver.weinm...@telespazio-vega.de | 
> oliver.weinm...@telespazio-vega.de
> ]
> [ http://www.telespazio-vega.de/ | http://www.telespazio-vega.de ]

> Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt,
> HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] how about https://github.com/omniosorg

[Tobias Oetiker]

since omnios is already taken  how about 

https://github.com/omniosorg 

cheers 
tobi 


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] To the OmniOS Community

[Tobias Oetiker]

- On May 15, 2017, at 11:20 PM, Michael Rasmussen m...@miras.org wrote:

> On Mon, 15 May 2017 22:46:10 +0200
> Michael Rasmussen  wrote:
> 
>> On Mon, 15 May 2017 07:37:35 +0200
>> Michael Rasmussen  wrote:
>> 
>> > To follow example I will commit myself to maintain the wiki and any
>> > other web based infrastructure the project may need and choose to have.
>> >   
>> I have found out that Omniti holds the domain name omnios.org. Will
>> Omniti consider handing over omnios.org to the community?
>> 
> BTW. speaking of wiki, online infrastructure etc.
> Any thoughts or wishes?
> What about hosting? (the important parts are: wiki and/or web site,
> mail list and/or forum, repository, bug tracker)
> This also means deciding which software to use for the above.

I would strongly urge to keep source, issues, pull requests, wiki on github.

it is perfectly integrated, works very well, and we have one less thing to 
worry about.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] How much would a professionally maintained OmniOS be worth to you ? (was: Re: The Future of OmniOS)

[Tobias Oetiker]

Folks,

so if you would rather have someone maintain omnios fulltime than relying on
'the community' todo it for free, now is the time to come forward. Write down
a line in our straw poll spreadsheet ... 

https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0

then we will see quickly in which direction this can go ... 

And when you write down that number, just think about how much time you save
by just going `pkg update` and be done with it ... haven't you grown to love 
that ?


cheers
tobi

- On Apr 25, 2017, at 6:11 PM, Linda Kateley lkate...@kateley.com wrote:

> Robert,
> 
> After reading everything I can in the last few days.. I have a couple
> questions which I hope you can answer honestly.
> 
> This announcement on the heals of a massive change in the freenas
> community make me wonder if there is any "backroom" pressure coming to
> companies supporting zfs?
> 
> The other is ... Is your hosted environment divesting from omnios? If so
> what os are you going to?
> 
> As a consultant and supporter of all things openzfs just want to know
> where the best safest places for my customers.
> 
> And one short comment.. I have have been watching following you guys for
> awhile now, and I never knew your hope or wish was for the community to
> pick up omnios. This surprises me. I am sure they would have if they had
> known.
> 
> Thanks for everything you have done for this community
> 
> Linda K
> 
> 
> On 4/23/17 3:13 PM, Robert Treat wrote:
>> Security updates are a little bit trickier than just pulling in
>> general upstream changes, but I think the ideal scenario would be to
>> form a group of interested people around the "secur...@omnios.org"
>> label which would collaborate on fielding and producing security fixes
>> for the project. Given we also have critical production systems
>> running OmniOS (more than most I suspect), we will need to deal with
>> security and bug fixes regardless, so we're happy to use those efforts
>> to bootstrap things.
>>
>> Robert Treat
>>
>> On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson  wrote:
>>> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at
>>> my day job, I'd first like to thank you guys for putting together a great
>>> operating system that has served me well over the years and I hope will
>>> continue to do so.
>>>
>>> However, I would like to clarify your stance when you say you are
>>> "suspending active development" and that r151022 will be the "final
>>> release". Per your historical release cycle:
>>>
>>> https://omnios.omniti.com/wiki.php/ReleaseCycle
>>>
>>> r151022 was to be an LTS release with security/bug fix support through H1
>>> 2020. While there will be no further releases of OmniOS from OmniTI, will
>>> you continue to back port fixes and fix issues in r151022 through that
>>> timeline, or will it be released as is and then be up to the as yet
>>> undeveloped community to do so? We currently have critical production
>>> systems deployed, systems whose deployment was only approved by management
>>> due to the availability of commercial support (the wisdom of such a
>>> perspective we will not discuss), and this sudden development is potentially
>>> going to leave us in quite a pickle. While I certainly can't dictate to you
>>> how to run your business, it would have been much easier on your customers
>>> had you made this announcement with the release of r151022, and coincided
>>> the end of your support offering with the end of life of this last release.
>>> Which also ideally would have provided time for an omnios community to have
>>> developed and started producing their own releases before the last
>>> officially supported omniti version reached sunset.
>>>
 -Original Message-
 From: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com]
 On Behalf Of Robert Treat
 Sent: Friday, April 21, 2017 7:07 AM
 To: omnios-discuss 
 Subject: [OmniOS-discuss] The Future of OmniOS

 Five years ago, when we first launched OmniOS, we did it out of a
 direct need to push forward the OpenSolaris ecosystem that we had
 built into the core of several parts of our business. At the time, the
 illumos community was still rather new and taking direct control of
 our path forward was a solid next step; we had already built many of
 the pieces in-house that we needed to produce a complete operating
 system distribution, and our experiences with open sourcing software
 we worked on had been generally very good.

 While we didn't know quite what the reaction would be, there were two
 things internally that guided us as long term factors in our decision.
 First, as we have done for other open source software, we thought it
 made sense to offer commercial support for OmniOS, but there was no
 desire to "pivot" OmniTI to be an operating system vendor. We like 

Re: [OmniOS-discuss] The Future of OmniOS

[Tobias Oetiker]

So, there you have it ... software is not free, and for something as complex
and slick as OmniOS, there is serious money involved in keeping it at its
current level. 

It seems that OmniTI has not managed to get this message
across to the many organizations relying on OmniOS to run their
Servers.

Robert has suggested that he hopes that 'the community' will take up
the maintenance of omnios in the future ... but I wonder ... now that we know
what is going to happen. Do you think your organisation would be prepared
to spend some 'real bucks' on keeping OmniOS maintained professionally?

I think we would be looking at something like ~500k USD per year.

For 1-2 People to continue running the show.

I have setup a chat on Gitter ...


   https://gitter.im/PostOmniOS/Lobby

lets meet there and discuss.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: network configuration script

[Tobias Oetiker]

maybe a page on the omnios wiki with pointers would be all that is needed

cheers
tobi


- On Apr 3, 2017, at 8:46 AM, Johan Kragsterman 
johan.kragster...@capvert.se wrote:

> Hi Michael and all!
> 
> 
> I think this is a good idea, thanks, Michael, but that is not the most 
> important
> reason I respond this mail:
> 
> 
> I have been thinking for a while about all the nice scripts for different
> solutions people have been presenting here, both bash, py, perl, DTrace, etc.
> The people that have been creating them keep them in different places, and 
> some
> of them are public, some are not.
> 
> It would be nice to have a "script-market", placed somewhere where OmniOS
> users/developers could easily reach them, and with some description about 
> their
> use, perhaps categorized. I don't know the right place for something like 
> that,
> perhaps git? With links from the OmniOS website.
> 
> What do you people think about that?
> 
> Regards Johan
> 
> 
> 
> 
> -"OmniOS-discuss"  skrev: -
> Till: "omnios-discuss@lists.omniti.com" 
> Från: Michael Rasmussen
> Sänt av: "OmniOS-discuss"
> Datum: 2017-04-02 23:33
> Ärende: [OmniOS-discuss] network configuration script
> 
> Hi all,
> 
> I think it is not very easy for new users coming to Omnios from various
> other distros to make the initial network configuration so I have
> written a small tool in Python to remedy this obstacle. The script runs
> on all Omnios as of r151014. I have tested on r151014 and bloody
> (r151021)
> 
> The script is not ment to be the swiss army knife for configuring
> networks on Omnios so there is no support for vnic, vlan, and
> aggregates. It will only support configuring a single nic given the
> user the option for dhcp and static setup. The user is also asked
> whether to configure dns in which case the user is asked for an IP.
> 
> Currently it will only handle ethernet but IPoIB is on my todo list. I
> have attached the script here but if the file is to large it can also
> be downloaded here: http://git.datanom.net/netconf.git/
> 
> PS. If I want to have it included in Omnios what license should I use?
> 
> --
> Hilsen/Regards
> Michael Rasmussen
> 
> Get my public GnuPG keys:
> michael  rasmussen  cc
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
> mir  datanom  net
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
> mir  miras  org
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
> --
> /usr/games/fortune -es says:
> It's illegal in Wilbur, Washington, to ride an ugly horse.
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> 
> [bilagan "netconf" borttagen av Johan Kragsterman/Capvert]
> [bilagan "att0uq4e.dat" borttagen av Johan Kragsterman/Capvert]
> 
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] KVMs locking up for seconds at a time...

[Tobias Oetiker]

- On Mar 17, 2017, at 3:02 PM, Dan McDonald dan...@omniti.com wrote:

>> On Mar 17, 2017, at 9:42 AM, Tobias Oetiker <t...@oetiker.ch> wrote:
>> 
>> We found the cause of the problem:
>> 
>>  svc:/system/rcap:default
>> 
>> enable it and enjoy the behaviour detailed below plus random hangs on nfs and
>> iscsi export
>> 
>> disable it and things are as before
> 
> Wow!  Just... wow!
> 
> Okay, thank you, and sorry I couldn't help you arrive here sooner,

the problem was found by my brother: Manuel Oetiker man...@oetiker.ch btw :)

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] KVMs locking up for seconds at a time...

[Tobias Oetiker]

We found the cause of the problem:

  svc:/system/rcap:default

enable it and enjoy the behaviour detailed below plus random hangs on nfs and 
iscsi export

disable it and things are as before


cheers
tobi


- On Mar 13, 2017, at 6:15 PM, Dan McDonald dan...@omniti.com wrote:

> Hello!
> 
> I'm including Tobias in this, as he reported this to me in OmniOS r151020
> (released November of 2016).  He can correct any mistake I make in reporting
> this.
> 
> His KVM instances are experiencing, "Random short freezes".  Let me quote him:
> 
>> We are running kvm instances on omni r20 and are experiencing random short
>> freezes.
>> I wrote the following short test script to see how frequent the freezing
>> occurres
>> 
>> perl -e 'use Time::HiRes qw(time usleep); my $now = time; while(1){usleep
>> 20; my $next = time; my $diff = $next - $now; $now=$next; if ($diff >
>> 0.22){ print "".localtime(time)." ".$diff,"\n"}}'
>> 
>> the output looks like this
>> 
>> Thu Mar  9 15:26:12 2017 0.224979877471924
>> Thu Mar  9 15:26:23 2017 0.273133993148804
>> Thu Mar  9 15:27:54 2017 1.17526292800903
>> Thu Mar  9 15:28:59 2017 2.04209899902344
>> Thu Mar  9 15:30:31 2017 1.0813729763031
>> Thu Mar  9 15:30:44 2017 0.600342988967896
>> Thu Mar  9 15:31:47 2017 1.43648099899292
>> Thu Mar  9 15:32:25 2017 0.897988796234131
>> Thu Mar  9 15:33:28 2017 0.998631000518799
>> Thu Mar  9 15:34:10 2017 4.89306116104126
>> Thu Mar  9 15:36:15 2017 1.22311997413635
>> Thu Mar  9 15:38:57 2017 1.64742302894592
>> Thu Mar  9 15:39:21 2017 1.36228013038635
>> Thu Mar  9 15:40:08 2017 1.62232208251953
>> Thu Mar  9 15:40:32 2017 1.37291598320007
>> Thu Mar  9 15:42:30 2017 0.211127996444702
>> 
>> as you can see there are quite frequent short freezes ...
> 
> So his KVM guest sees freezes.  And he ran that perl in the OmniOS global zone
> w/o noticing any slowdowns.
> 
> I asked him to pstack(1) the qemu process.  It's attached below as pstack.zip.
> 
> He further noticed a manifestation in the global zone:
> 
>> What I found while looking up process numbers on the problematic box, is that
>> 
>>   time cat /proc/*/psinfo > /dev/null
>> 
>> Takes anywhere between 0.01s and 4s if called repeatedly, whereas on a 
>> machine
>> another host where there are no sever kvm hangs this command always takes 
>> about
>> 0.02 secons.
> 
> So he can find slowness that's likely KVM-induced in the global zone.  With 
> that
> in mind, I told him, and he responded:
> 
>>> lockstat(1M) may be helpful here:
>>> 
>>> lockstat -o  cat /proc/*/psinfo > /dev/null
>>> 
>>> I'll want to see that output from .  ESPECIALLY if it's a "takes 
>>> way
>>> too long" sort of result.
> 
> 
> He included three lockstat outputs, also attached below.
> 
> The longer-running ones had this lock:
> 
> 11423  73%  73% 0.00 3403 0xfea4320ef020
> gfn_to_memslot_unaliased+0x1f
> 
> being hammered more in the long-running ones than in the short-running ones.
> Now I don't know KVM internals all that well, but  it looks like the lock in
> question protects a linear-array-search of memory slots.  It appears it just
> runs through and stops when the requested address is in the range of one of 
> the
> hits.
> 
> I've not asked Tobias yet to dig into kmdb to see how many memory slots are in
> this kvm, but let me do that too:
> 
> Tobias:  Try this:
> 
>   dtrace -n 'gfn_to_memslot_unaliased:entry { printf("\nKVM 0x%p, number 
> of
>   memslots: %d\n", arg0, ((struct kvm_memslots *)((struct kvm
>   *)arg0)->memslots)->nmemslots); stack(); exit(0);}'
> 
> If your system is still running the same KVM instances, check for
> 0xfea4320ef000 as the KVM pointer.
> 
> Everyone else ===> Any idea if memslots would cause KVM instances to misbehave
> per above?  If not, any other clues so I don't keep chasing red herrings?  If
> so, should we perhaps spend some time making memslots more efficient?  Or are
> there operational considerations not being accounted for?
> 
> Thanks,
> Dan

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] kvm instances random short freeze

[Tobias Oetiker]

Hi 

We are running kvm instances on omni r20 and are experiencing random short 
freezes. 
I wrote the following short test script to see how frequent the freezing 
occurres 

perl -e 'use Time::HiRes qw(time usleep); my $now = time; while(1){usleep 
20; my $next = time; my $diff = $next - $now; $now=$next; if ($diff > 
0.22){ print "".localtime(time)." ".$diff,"\n"}}' 

the output looks like this 

Thu Mar 9 15:26:12 2017 0.224979877471924 
Thu Mar 9 15:26:23 2017 0.273133993148804 
Thu Mar 9 15:27:54 2017 1.17526292800903 
Thu Mar 9 15:28:59 2017 2.04209899902344 
Thu Mar 9 15:30:31 2017 1.0813729763031 
Thu Mar 9 15:30:44 2017 0.600342988967896 
Thu Mar 9 15:31:47 2017 1.43648099899292 
Thu Mar 9 15:32:25 2017 0.897988796234131 
Thu Mar 9 15:33:28 2017 0.998631000518799 
Thu Mar 9 15:34:10 2017 4.89306116104126 
Thu Mar 9 15:36:15 2017 1.22311997413635 
Thu Mar 9 15:38:57 2017 1.64742302894592 
Thu Mar 9 15:39:21 2017 1.36228013038635 
Thu Mar 9 15:40:08 2017 1.62232208251953 
Thu Mar 9 15:40:32 2017 1.37291598320007 
Thu Mar 9 15:42:30 2017 0.211127996444702 

as you can see there are quite frequent short freezes ... 

I am running the same script in the omnios global zone there is no freezing 
over 0.02s 

any ideas ? 

cheers 
tobi 
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] what about zfs-io-priority

[Tobias Oetiker]

Hi Dan

you imported the change in r14 and the article from the joyent wiki
is from Sep 21, 2011

so I guess if anything, you have something newer than what is
described in the joyent wiki, but the question is what ...

cheers
tobi


Today Dan McDonald wrote:

>
> > On Mar 3, 2017, at 5:32 AM, Tobias Oetiker <t...@oetiker.ch> wrote:
> >
> > Did zfs-io-priority for zones ever make it into omnios ?
> >
> >   https://omnios.omniti.com/ticket.php/13 suggests it did
> >
> > but the notes on configuring it from
> >
> >   https://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle
> >
> > don't seem to apply.
> >
> > anyone ?
>
> I think an early version was ported in, and nobody kept up with any 
> subsequent changes from Joyent afterwards.
>
> If that wiki has older revs, see if they apply instead.
>
> Dan
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] what about zfs-io-priority

[Tobias Oetiker]

Did zfs-io-priority for zones ever make it into omnios ? 

https://omnios.omniti.com/ticket.php/13 suggests it did 

but the notes on configuring it from 
https://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle 

don't seem to apply. 

anyone ? 

cheers 
tobi 

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland 
www.oetiker.ch t...@oetiker.ch +41 62 775 9902 
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LX zones: configurations

[Tobias Oetiker]

On 11 Jan, 2017, at 00:03, Dan McDonald dan...@omniti.com wrote:

> Given how encompassing the 022 work is, don't hold your breath.  If there are
> real, provable show-stoppers in LX, fixes may get backported.

We have setup ThinLinc (www.cendio.com) in an ubuntu 16.04 lx zone ... 

ThinLinc is a sunray like environment with very fast vnc based 
software-thin-clients ... 
the setup works great on lx and is VERY fast, compared to
doing the same thing in kvm ... 

the only 'show-stopper' for us is that chrome (and chromium) crash pretty
much instantly after launch ...

so I would be quite interesting on how to report lx issues ... (and yes we do 
have a omniti support contract).

cheers
tobi
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] using proxmox, after upgrade KVM does not start

[Tobias Oetiker]

Robert,

Today Robert.fantini wrote:

> Hello
>
> My issue may have nothing to do with the omnios upgrade. It could be due to a 
> mistake I made somewhere else.
>
> After upgrading to :
> OmniOS 5.11 omnios-cac2b76 October 2016
> SunOS sys4 5.11 omnios-cac2b76 i86pc i386 i86pc
>
> our KVM's using iscsi will not start.
> kvm: -drive 
> file=iscsi://10.2.2.41/iqn.2010-09.org.napp-it:1459891666/2,if=none,id=drive-virtio0,format=raw,cache=none,aio=native,detect-zeroes=on:
>
> iSCSI: Failed to connect to LUN : iscsi_service failed with : 
> iscsi_service_reconnect_if_loggedin. Can not reconnect right now.
>
>
> Has anyone seen that?
>
> Or suggest iscsi debugging/testing commands to get more information?

we found that after the upgrade a few of our luns had disaperaed
... since onone else reported this on the list we thought that we
may have made a mistake ... but maybe there is something more

just recreate the missing luns ... (we had to pick new lun numbers
since omni complained that the old luns were already in use)

then rescan iscsi on the proxmox host and all should be well.

cheers
tobi
>
>
> thanks , Robert Fantini

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LDAP external auth for CIFS service

[Tobias Oetiker]

- On 18 Aug, 2016, at 17:15, Dan McDonald dan...@omniti.com wrote:

>> On Aug 18, 2016, at 11:04 AM, Mick Burns  wrote:
>> 
>> *bump*
>> anyone ?
> 
> I'm going to forward your note to someone I know who works on CIFS.  He's not 
> on
> this list.

looking forward to the answer ... :) I have always used an AD for this but 
openldap would be so much cooler.

cheers
tobi
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Znapzend installation

[Tobias Oetiker]

Hi Lawrence,

if you install something from source, NEVER unpack the source in
the installation directory ...

unpack in /scratch or /tmp ... install to /opt/package-version

cheers
tobi

Today Lawrence Giam wrote:

> Hi All,
>
> I am trying to test Znapzend on OmniOS R151014 but getting errors on the
> installation. This is the errors:
>
> root@sgtestnas02:/opt/znapzend# ./configure --prefix=/opt/znapzend
> --enable-svcinstall=/var/svc/manifest/site
> checking in to see how you are doing... keep fighting man!
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... conftools/install-sh -c -d
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether UID '0' is supported by ustar format... yes
> checking whether GID '0' is supported by ustar format... yes
> checking how to create a ustar tar archive... gnutar
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking whether make supports nested variables... (cached) yes
> checking for perl... /usr/bin/perl
> checking for curl... /usr/bin/curl
> checking for wget... /usr/bin/wget
> checking for pod2man... no
> checking for perl version greater than or equal to 5.10.1... ok
> checking is perl reasonably complete... yes. ExtUtils::MakeMaker is
> available
> checking if require a c compiler to get perl modules compiled... yes
> checking for gcc... /usr/bin/gcc
> checking is perls favorite c compiler (gcc) available... yes
> checking for grep that handles long lines and -e... /usr/bin/ggrep
> checking for gnumake... no
> checking for gmake... /usr/bin/gmake
> checking for gnu make availablility... /usr/bin/gmake is GNU make
> checking the price for bergulian eckels... way to expensive!
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating thirdparty/Makefile
> config.status: creating lib/Makefile
> config.status: creating init/znapzend.xml
> config.status: WARNING:  'init/znapzend.xml.in' seems to ignore the
> --datarootdir setting
>
> ** CONFIGURE DONE **
>
> Settings:
>
>   PERL5LIB = not set
>   PERL = /usr/bin/perl
>   SVCINSTALLDIR = /var/svc/manifest/site
>
> The Makefiles use GNU make functionality.
> Continue installation with
>
>   /usr/bin/gmake install
>
> root@sgtestnas02:/opt/znapzend# /usr/bin/gmake install
> Making install in thirdparty
> gmake[1]: Entering directory `/opt/znapzend-0.15.7/thirdparty'
>   GEN  touch
> Successfully installed IO-Socket-IP-0.37
> Successfully installed Mojolicious-6.46
> Successfully installed Scalar-List-Utils-1.45 (upgraded from 1.25)
> Successfully installed Exporter-5.72 (upgraded from 5.66)
> Successfully installed IO-Pipely-0.005
> Successfully installed Mojo-IOLoop-ForkCall-0.17
> Successfully installed Test-Harness-3.36 (upgraded from 3.23)
> 7 distributions installed
>   GEN  touch
> gmake[2]: Entering directory `/opt/znapzend-0.15.7/thirdparty'
> gmake[2]: Nothing to be done for `install-exec-am'.
> gmake[2]: Nothing to be done for `install-data-am'.
> gmake[2]: Leaving directory `/opt/znapzend-0.15.7/thirdparty'
> gmake[1]: Leaving directory `/opt/znapzend-0.15.7/thirdparty'
> Making install in lib
> gmake[1]: Entering directory `/opt/znapzend-0.15.7/lib'
> gmake[2]: Entering directory `/opt/znapzend-0.15.7/lib'
> gmake[2]: Nothing to be done for `install-exec-am'.
>  ../conftools/install-sh -c -d '/opt/znapzend/lib'
>  /usr/bin/install -c -m 644  ./ZnapZend.pm '/opt/znapzend/lib/.'
> /usr/bin/install: './ZnapZend.pm' and '/opt/znapzend/lib/./ZnapZend.pm' are
> the same file
> gmake[2]: *** [install-nobase_dataDATA] Error 1
> gmake[2]: Leaving directory `/opt/znapzend-0.15.7/lib'
> gmake[1]: *** [install-am] Error 2
> gmake[1]: Leaving directory `/opt/znapzend-0.15.7/lib'
> gmake: *** [install-recursive] Error 1
> root@sgtestnas02:/opt/znapzend#
>
> Don't know what is missing, any help here?
>
> Thanks & Regards.
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] need help with znapzendzetup

[Tobias Oetiker]

Hi Robert

znapzend is "push-only"

cheers
tobi

Today Robert Fantini wrote:

> Hello,
>
> I've got znapzend working on omnios.  that can remote send to linux using a
> napp-it  job .
>
> Next I want to run znapzend on linux and pull from omnios .
>
> this does not work ,
> znapzendzetup create \
>   --tsformat='%Y-%m-%d-%H%M%S'  \
>   --mbuffer=/usr/bin/mbuffer \
>   SRC  '7d=>1h,3w=>1d'   root@10.2.2.21:data/vm-111-disk-1  \
>   DST  '7d=>1h,3m=>1d'   tank/znapzend/pro4-kvm
>
> *** backup plan: root@10.2.2.21:data/vm-111-disk-1 ***
> dst_0   = tank/znapzend/pro4-kvm
> dst_0_plan  = 7days=>1hour,3months=>1day
> enabled = on
> mbuffer = /usr/bin/mbuffer
> mbuffer_size= 1G
> post_znap_cmd   = off
> pre_znap_cmd= off
> recursive   = off
> src = root@10.2.2.21:data/vm-111-disk-1
> src_plan= 7days=>1hour,3weeks=>1day
> tsformat= %Y-%m-%d-%H%M%S
>
> Do you want to save this backup set [y/N]?
>  y
> cannot open 'root@10.2.2.21:data/vm-111-disk-1': invalid dataset name
> cannot open 'root@10.2.2.21:data/vm-111-disk-1': invalid dataset name
> ERROR: could not set property dst_0_plan on root@10.2.2.21:
> data/vm-111-disk-1
>
>
> The SRC zfs exists:
> ssh 10.2.2.21 zfs list data/vm-111-disk-1
> NAME USED  AVAIL  REFER  MOUNTPOINT
> data/vm-111-disk-1  16.5G  1.17T  16.1G  -
>
>
> Any clues on what I am doing wrong?
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Samsung SM863

[Tobias Oetiker]

Just found that samsung now has an ssd with  power loss protection

http://www.storagereview.com/samsung_sm863_ssd_review

what do you think ?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] considering an SSD pool ... which SSD

[Tobias Oetiker]

We are looking into the possibility of setting up our first SSD
based pool ... any recommendations for SSDs to use ?

Our System Integrator recommends the use of Intel SSDs as opposed
to Samsung since Samsung would be changing their lineup every few
weeks and thus make it difficult to source replacement disks, in
case one should fail.

any thoughts ?

cheers
tobi





-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] allocation throttle

[Tobias Oetiker]

I am just watching OpenZFS Conference Videos. George Wilson just
showed off his allocation throttle work ... is this in omnios
already ?

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] 014 and X540 on intel s2600

[Tobias Oetiker]

Friday Tobias Oetiker wrote:

 We are trying to get an intel 10G network interface x540 to work
 on omnios r014. We do see the interface with

 $ dladm show-phys

 but it does not show any reaction when we plug an ethernet cable
 leading to a 1Gb switch port. It stays 'down'

to resolve this ... it turnes out the customer had neglected to
plug the network cable in ...  and had steadfastly claimed that
everything was plugged propperly when we called him. Only today
when we called again and another member of staff went to check, he
found that no cable was connected to the port ...

To to recap ... x540 10 Gigabit Copper Ethernet ports work on
omnios r014 out of the box. IF the cable is plugged in.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] 014 and X540 on intel s2600

[Tobias Oetiker]

We are trying to get an intel 10G network interface x540 to work
on omnios r014. We do see the interface with

$ dladm show-phys

but it does not show any reaction when we plug an ethernet cable
leading to a 1Gb switch port. It stays 'down'


any ideas ?

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [smartos-discuss] kvm network performance survey

[Tobias Oetiker]

Michael,

Today Michael Rasmussen wrote:

 On Mon, 13 Apr 2015 16:25:42 +
 John Barfield john.barfi...@bissinc.com wrote:

 
  I?ll try to pull some numbers but the truth is that debian based guest
  versions perform WAY better than CentOS guests.
 
 Are the kernels identical in Debian and CentOS?

We don't have measurements from Centos in the list yet, but various
ubuntu versions and kernels, and you can see there that between
different kernel versions, there can well be a factor of 2 or 3 in
performance ... that is also interesting ...

   http://goo.gl/Vr1tC6

BUT what worries me, is that between omnios r10 and r14 (r12
actually) there is a factor of 1000 or more !!!

cheers
tobi




-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] kvm crashing while running replication send/receive

[Tobias Oetiker]

I got these bunch of new disks when for our (r12 omnios) server and
userd repication send / receive to transfer an existing pool to the
new disks.  While doing so, we found that the kvm instances running
on that machine had a rather pronounced tendency to become
unresponsive. Killing the kvm process and starting it again helped ...

Neither the sending nor the receiving pool were the ones where the
kvm volumes where hosted ...

Any ideas how this can happen ?

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] incomplete recursive snapshots

[Tobias Oetiker]

I got a bunch of new disks on one of our systems and wanted to
transfer an existing pool over to them so what I did was this:

zfs snapshot -r old-pool@replicaton
zfs send -R old-pool@replication | mbuffer -m 1G  | zfs receive -F -d  
new-pool

but then halfway through the operation, I got warnings from send,
that old-pool/some/fileset@replication would not exist ...

when I went to investigate, I found indeed that zfs snapshot -r had
neglected to create a snapshot on old-pool/some/fileset. So I
ran

zfs list -r -o name old-pool | xargs -n1 perl -e 'system 
zfs,list,$ARGV[0].q{@replication}'

and found that there were about 10% of the filesets which were
lacking this snapshot ...

I then proceeded to create the missing snapshot individually, and
it worked fine.

I have since repeated the experiment and found the same problem
again ...

any idea how this can be ?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] incomplete recursive snapshots

[Tobias Oetiker]

Hi Dan,

Today Dan McDonald wrote:

 Only recently fixed snapshot bug I could find was Illumos 5150 
 http://www.illumos.org/issues/5150

 Also, could you share the precise warnings?  It'll help finding who's doing 
 the complaining.

*blush* it was my bad ...

see
http://serverfault.com/questions/675185/incomplete-recursive-snapshots-on-zfs

cheers
tobi


 Dan

 Sent from my iPhone (typos, autocorrect, and all)

  On Mar 13, 2015, at 3:25 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
  I got a bunch of new disks on one of our systems and wanted to
  transfer an existing pool over to them so what I did was this:
 
 zfs snapshot -r old-pool@replicaton
 zfs send -R old-pool@replication | mbuffer -m 1G  | zfs receive -F -d  
  new-pool
 
  but then halfway through the operation, I got warnings from send,
  that old-pool/some/fileset@replication would not exist ...
 
  when I went to investigate, I found indeed that zfs snapshot -r had
  neglected to create a snapshot on old-pool/some/fileset. So I
  ran
 
 zfs list -r -o name old-pool | xargs -n1 perl -e 'system 
  zfs,list,$ARGV[0].q{@replication}'
 
  and found that there were about 10% of the filesets which were
  lacking this snapshot ...
 
  I then proceeded to create the missing snapshot individually, and
  it worked fine.
 
  I have since repeated the experiment and found the same problem
  again ...
 
  any idea how this can be ?
 
  cheers
  tobi
 
 
  --
  Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
  www.oetiker.ch t...@oetiker.ch +41 62 775 9902
 
  ___
  OmniOS-discuss mailing list
  OmniOS-discuss@lists.omniti.com
  http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] 5296 Support for more than 16 groups with AUTH_SYS

[Tobias Oetiker]

Is

https://github.com/illumos/illumos-gate/commit/89621fe174cf95ae903df6ceab605bf24d696ac3

in 14 ?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] About P19

[Tobias Oetiker]

Dan,

you mentioned in an earlier post that you had not heard anything
good about P19 ... this seems to prompt people to consider
downgreading to P18 ...

Did you mean to say that you had heared something BAD about P19 or
just nothing at all. Because I like my firmware best when it just
does what it is suposed todo and noone even thinks about it.

We are running P19 currently on one of our boxes, and it works ok.

(It did not solve the problem that prompted us to upgrade, which is
that we are seeing disks going offline for a few seconds every few
weeks causing zfs to mark them as faulted. But it did not make it
worse either, so we are looking at the disk firmware now ... )

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] HGST 7K6000 for a RAIDZ2 pool

[Tobias Oetiker]

Today Tobias Oetiker wrote:

 Hi Marts,

 Yesterday Warren Marts wrote:

  At some point sourcing true 512 B/sector disks will get more difficult and
  expensive - unless you knew this filesystem is likely to see lots of small
  writes and performance or space efficiency are critical I'd lean to the 4KB
  sector disks.

 Amazingly, the new He6 drives from HGST only seem to exist in an
 512n variant ... while the also new He8 drives only come in 4Kn and
 512e types ...

also while on the subject, there is

https://github.com/zfsonlinux/zfs/issues/548
https://github.com/zfsonlinux/zfs/issues/1807

which would indicate that using 512n is probably a better choice in
an environment where we are using zvol a lot

cheers
tobi




  On Wed, Feb 25, 2015 at 4:39 PM, Richard Elling 
  richard.ell...@richardelling.com wrote:
 
  
On Feb 25, 2015, at 3:17 PM, Tobias Oetiker t...@oetiker.ch wrote:
   
experts!
   
If you were to buy 6TB disks for a RAIDZ2 Pool, would you go for
512n like in the olden days, or use the new 4Kn.
   
I know ZFS can deal with both ...
   
So what would be your choice, and WHY?
  
   Better yet, what would be your requirements, then your choice, then why?
-- richard
  
   
cheers
tobi
   
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
   
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
  
   ___
   OmniOS-discuss mailing list
   OmniOS-discuss@lists.omniti.com
   http://lists.omniti.com/mailman/listinfo/omnios-discuss
  
 



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] HGST 7K6000 for a RAIDZ2 pool

[Tobias Oetiker]

experts!

If you were to buy 6TB disks for a RAIDZ2 Pool, would you go for
512n like in the olden days, or use the new 4Kn.

I know ZFS can deal with both ...

So what would be your choice, and WHY?

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] recovering a faulted disk

[Tobias Oetiker]

If zfs sees too many errors on a disk, it will 'FAULT'
the disk, replace it with a spare disk and start resilvering.

We have one system where this keeps happening ... as explained in

http://lists.omniti.com/pipermail/omnios-discuss/2014-March/002413.html

We have since replaced the firmware on the controllers, and
increassed the fan speed, to make sure the contollers are not hot.

The disk, in any event seem to be ok, since they do not exhibit any
problem when testing afterwards.

So my question is, can I somehow convince ZFS that the disk it just
FAULTED is actually OK, and it should just fixup the bits that have
changed since it abandoned the particular disk ?

The reason I am asking this is that resilvering takes quite a lot
of time with the stuff we have on these drives, a few days at least
... and just a few hours ago, the scond drive in our RAIDZ2 got
faulted ...


cheers
tobi
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] UPCOMING: End of Support Life approaching for OmniOS r151010

[Tobias Oetiker]

Hi Dan,

Today Dan McDonald wrote:

 Sometime during Q2CY2015 (no earlier than April 1st), OmniOS
 r151014 will be released.  At that time, support for r151010
 (previous stable) will be discontinued.  This is in accordance
 with the OmniOS release cycle:

   http://omnios.omniti.com/wiki.php/ReleaseCycle

 If you can, please upgrade to r151012.  We *should* be able to
 allow a jump from r151010 to r151014, as we must support a jump
 from r151012 to 014 AND from 006 to 014 (because r151014 will
 also be the next Long-Term Support release).

 As I mentioned the last time, beadm(1M) is your friend.  Creating
 backup BEs in case of mistakes is easy.

I do not have a spare machine to test this, but if the dramatic
network io performance regression for kvm present in r151012 has
not been fixed in r151014 then we will be stranded on r151010.

Judging from the echo on the ML, not many people seem to see this
problem, or care about it.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] in.tftpd not working and how to fix it

[Tobias Oetiker]

caveat: due to the kvm performance problem I am still running 010
... but maybe this is also a problem on more recent versions ...

so here goes:

after upgrading to 010 the tftp service on our omnios box stopped
working properly ... it served a few bytes of the request and then
timed out ...

we investigated for a bit and then moved our tftp service to linux.

Today I ran into the problem again and found the solution:

on http://omnios.omniti.com/wiki.php/Installation there is:

 Activate TFTP server by adding the following line to
 /etc/inetd.conf and running the inetconv command. This will
 create an SMF service, network/tftp/udp6. Don't worry about the
 udp6 bit-- it listens for both IPv4 and IPv6 connections.

well as it turnes out, you actually SHOULD worry and use 'udp'
instead ... then all will work nicely (on ip4 at least).

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] kvm io 10 times slower after r151010 - r151012 upgrade

[Tobias Oetiker]

Hi Michael,

so your tests wer now exectued on a bloody host ?

indicating that the performance went back up in bloody ?

cheers
tobi

Today Michael Mounteney wrote:

 Sorry to take so long to get back to you Tobias and I hope this is
 still relevant.  As described elsewhere in this list, I had temporarily
 to downgrade ssh to achieve interoperability between the OmniOS (bloody)
 host and the Gentoo Linux guests.

 First, ssh imposes some overhead:

 mounty@pantry ~ $ time ssh people exit

 real  0m0.724s
 user  0m0.032s
 sys   0m0.012s

 that real figure averages around the 0.750s mark.  So I decided to
 perform much bigger transfers to minimise its effect:

 mounty@pantry ~ $ dd if=/dev/zero bs=1M count=2000 | ssh people dd 
 of=/dev/null
 2000+0 records in
 2000+0 records out
 2097152000 bytes (2.1 GB) copied, 138.436 s, 15.1 MB/s
 4096000+0 records in
 4096000+0 records out
 2097152000 bytes transferred in 137.657582 secs (15234555 bytes/sec)

 mounty@pantry ~ $ ssh people dd if=/dev/zero bs=1M count=2000 | dd 
 of=/dev/null
 2000+0 records in
 2000+0 records out
 2097152000 bytes transferred in 51.692313 secs (40569901 bytes/sec)
 4096000+0 records in
 4096000+0 records out
 2097152000 bytes (2.1 GB) copied, 52.4503 s, 40.0 MB/s

 It is puzzling that the in and out figures are so different but I did
 perform each test three times and the results were approximately the
 same each time.  On the read-off-disk test, here are all three runs:

 pantry ~ # dd if=/dev/vda of=/dev/zero bs=1M count=1000
 1000+0 records in
 1000+0 records out
 1048576000 bytes (1.0 GB) copied, 65.3406 s, 16.0 MB/s
 pantry ~ # dd if=/dev/vda of=/dev/zero bs=1M count=1000
 1000+0 records in
 1000+0 records out
 1048576000 bytes (1.0 GB) copied, 1.19789 s, 875 MB/s
 pantry ~ # dd if=/dev/vda of=/dev/zero bs=1M count=1000
 1000+0 records in
 1000+0 records out
 1048576000 bytes (1.0 GB) copied, 1.85877 s, 564 MB/s

 which I've quoted to show that the disk must be cached.  So I tried
 again with more data to eliminate that effect:

 pantry ~ # dd if=/dev/vda of=/dev/zero bs=1M count=10240
 10240+0 records in
 10240+0 records out
 10737418240 bytes (11 GB) copied, 710.215 s, 15.1 MB/s

 I hope that's helpful.

 Michael.
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm issues

[Tobias Oetiker]

Today Theo Schlossnagle wrote:

 I think you have to have an addrconf ipv6 first, then you can add the
 static one.

 ipadm create-addr -T addrconf mplon0/v6a
 ipadm create-addr -T static -a 2001:2620:102d::cb/64 mplon0/v6static

oh ... I did that ... sorry ... not mentioned ... same problem ...
ipadm only accepts the setting with the -t switch

cheers
tobi


 On Wed, Dec 17, 2014 at 2:54 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
  I seem to run into trouble with ipadm ...
 
  here is the latest
 
   root@simplon:~# ipadm  show-addr
   ADDROBJ   TYPE STATEADDR
   lo0/v4static   ok   127.0.0.1/8
   mplon0/v4static static   ok   118.124.138.203/28
   mplon0/v4intern static   ok   192.168.1.4/24
   lo0/v6static   ok   ::1/128
   mplon0/v6   addrconf disabled ::
   mplon0/v6a  static   disabled 2001:2620:102d::cb/64
   root@mplon:~# ipadm  enable-addr -t mplon0/v6
   ipadm: could not enable address: Object not found
   root@mplon:~# ipadm  enable-addr -t mplon0/v6a
   ipadm: could not enable address: Object not found
 
  I was able to solve this to an extent by removing the ip6 stuff
  from /etc/ipadm.conf, and then running ipdam again but it would not
  let me add permanent config:
 
   root@mplon:~# ipadm create-addr -T static -a 2001:2620:102d::cb/64
  mplon0/v6a
   ipadm: Could not create address: Persistent operation on temporary object
 
  At least adding a temporary address worked:
 
   ipadm create-addr -t -T static -a 2001:2620:102d::cb/64 mplon0/v6a
 
  how to make ipadm see the light ?
 
  cheers
  tobi
 
  --
  Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
  www.oetiker.ch t...@oetiker.ch +41 62 775 9902
 
  ___
  OmniOS-discuss mailing list
  OmniOS-discuss@lists.omniti.com
  http://lists.omniti.com/mailman/listinfo/omnios-discuss
 




-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ipadm issues

[Tobias Oetiker]

Hi Dan,

Yesterday Dan McDonald wrote:


  On Dec 17, 2014, at 10:47 AM, Dan McDonald dan...@omniti.com wrote:
 
 
  On Dec 17, 2014, at 2:54 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
  I seem to run into trouble with ipadm ...
 
  here is the latest
 
  Silly question -- what does ipadm show-if say?

 Also, I noticed this:

 mplon0/v6   addrconf disabled ::

 Try this:

   ipadm enable-if mplon0/v6

I tried enable-addr ... maybe that was the problem ...
since I have now setup the temporary interface ... I can't test
this ...

on another note though ...

as I setup addr conf, I got both the linklocal address as well as a
selfassigned global address ... how can I tell ipadm NOT todo that
and to be happy with the linklocal address, since I am assigning a
fixed address by hand

cheers
tobi


 Dan



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] live lsi firmware upgrade P17-P19

[Tobias Oetiker]

I am looking at upgrading the firmware of our LSI HBAs to P19 since
we suspect that our use of P17 is the cause for disk timeouts we
are seeing every few weeks.

I am wondering, is it save to flash the HBAs from a running omnios system,
and if so, has anyone written some notes down on the process and
tools to use?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] kvm io 10 times slower after r151010 - r151012 upgrade

[Tobias Oetiker]

Hi Michael,

Today Michael Mounteney wrote:

 On Wed, 10 Dec 2014 06:14:56 +0100 (CET)
 Tobias Oetiker t...@oetiker.ch wrote:

  This leads me to suspect, that either only very few people are
  using omnios as a kvm server OR it is also a hardware dependent
  problem.

 I think it must be.  I'm running KVM (Gentoo Linux guests) and have
 just gone from 151010 to 151012.  I haven't carried-out any
 quantitative assessment, but didn't notice any slowdown.  For the
 record, my KVM invocation is:

 /usr/bin/qemu-system-x86_64 \
 -name Gentoo $WHAT \
 -cpu host \
 -boot order=d \
 -enable-kvm \
 -vnc cortex:$VNC \
 -smp 1,maxcpus=1,cores=2 \
 -m 1024 \
 -no-hpet \
 -localtime \
 -kernel 
 /gentoo/kernel-source/linux-3.17.4-gentoo-vbox/arch/x86/boot/bzImage \
 -append root=/dev/vda1 init=/usr/lib/systemd/systemd quiet \
 -drive 
 file=/dev/zvol/dsk/rpool/vol/Gentoo-KVM-${WHAT},cache=none,if=virtio,index=0 \
 -drive 
 file=/dev/zvol/dsk/rpool/vol/Linuswap-${WHAT},cache=none,if=virtio,index=1 \
 -net nic,vlan=0,macaddr=$mac,model=virtio,name=ncard1 \
 -net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac \
 -monitor telnet:127.0.0.1:${monitor},server,nowait \
 -vga std \
 -daemonize

 where ${WHAT} is either KDE or XFCE.  Machine is a Supermicro 5017C-LF with 1 
 x Intel Xeon E3-1240V2 3.40 GHz.4 Cores , 4 Threads,8Mb cache and 8 GiB RAM.

 If you are interested in any performance figures, let me know any tar or dd 
 etc. commands you'd like me to run.

yes, a very simple test:

guest$ dd if=/dev/zero bs=1M count=20 | ssh host dd of=/dev/null
guest$ ssh host dd if=/dev/zero bs=1M count=20 | dd of=/dev/null

and since I suspect that the disk io suffers too but due to
caching, maybe reading just a bit off the disk device might be an
interesting test:

  dd if=/dev/vda of=/dev/zero bs=1M count=1000

cheers
tobi


 Michael.
 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] kvm io 10 times slower after r151010 - r151012 upgrade

[Tobias Oetiker]

So tonight, we finally took the plunge and upgraded our zfs/kvm
server to r151012 ... the results were terrible. The kvm booted
very slowly and all networking felt really slow ... so I did a
little test:

  ubutu-14.04-guest$ dd if=/dev/zero bs=1M count=20 | ssh omnios-r151012-host 
dd of=/dev/null
  20971520 bytes (21 MB) copied, 6.27333 s, 3.3 MB/s

  ubutu-14.04-guest$ ssh omnios-r151012-host dd if=/dev/zero bs=1M count=20 | 
dd of=/dev/null
  20971520 bytes transferred in 8.010208 secs (2618099 bytes/sec)

These numbers were obtained using virtio net drivers but switching
to e1000 did not significantly change things.

So we booted back into r151010 again ... the difference was
immediately apparent ... but there are also number to back this up.

  ubutu-14.04-guest$ dd if=/dev/zero bs=1M count=20 | ssh omnios-r151010-host 
dd of=/dev/null
  20971520 bytes (21 MB) copied, 0.812479 s, 25.8 MB/s

  ubutu-14.04-guest$ ssh omnios-r151010-host dd if=/dev/zero bs=1M count=20 | 
dd of=/dev/null
  20971520 bytes (21 MB) copied, 0.545423 s, 38.5 MB/s

as you can see the difference in guest network performance is
roughly one magnitude ...

I have not tested disk performance explicitly, but even booting a
windows host took ages ... so I suspect whatever is causing this
influences all kvm guest IO.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] kvm io 10 times slower after r151010 - r151012 upgrade

[Tobias Oetiker]

Yesterday Dan McDonald wrote:

 
  I have not tested disk performance explicitly, but even booting a
  windows host took ages ... so I suspect whatever is causing this
  influences all kvm guest IO.

 What's really REALLY weird about this is that we did not alter
 anything about how we built KVM between these releases.

 Tell me, can you run lockstat sleep time-of-test in the
 global zone while you run your KVM tests?  They will produce a
 lot of output, but they may be very informative about what's
 going on.


Unfortunately I don't have a spare 'big' iron box to play with, but
we should be able to do some downtime tonight to run that lockstat
sleep experiment and also to do some simple disk io test (with dd).

 Also, I'd be curious if you might (BEs and rpool space being
 available) upgrade a BE to bloody and repeat your tests?

 We don't have the facilities to stress out VMs like this, which
 is why we didn't notice this before 012 went out the door.
 Clearly something's messing up KVM performance (you're not the
 first to report this, but you seem to have a decent environment
 for comparisons).  Before the next stable (and incidentally
 long-term-support as well) release, I hope to have these problems
 cleared up.  One thing that should happen soon is that Joyent is
 upstreaming the VND changes into illumos-gate, which will allow
 us to be fully caught up to their illumos-kvm-cmd source, which
 we've frozen at revision 1c6181be55d1cadc4426069960688307a6083131
 since r151010.

I know that there was no kvm change ... so this must be some side
effect of another modificiation ...

What seems odd, is that only 2 (or 3) few people reported this
problem on the list.  After all, it's not something that was
difficult to notice.  After the upgrade the kvm guests really are
almost un-usable for interactive work involing network or disk IO,
especially when compared to before.

This leads me to suspect, that either only very few people are
using omnios as a kvm server OR it is also a hardware dependent
problem.

I was also wondering if we should try to boot the current smaros on
the box just to see what it does to kvm perf. But as I said, it is
a production machine, so it is all a bit tricky.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] best guide to tftp ?

[Tobias Oetiker]

Hi Michael,

Nov 9 Michael Mounteney wrote:

 [Later] just running

 # /usr/sbin/in.tftpd -p -d -s /tftpboot

 doesn't work either.  A client-side

 $ tftp cortex -c get text

 times out.

we found that tftpd on omnios stoped working with the upgrade to
r10 .. we have investigated a bit but not found the cause and
switched to another machine (linux) for your tftp needs ... but it
would certainly be nice to know what broke it ...

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] kvm performance regresseion r10 - r12

[Tobias Oetiker]

I am still running omnios r10 ...being reluctant to upgrade,
because we find that kvm virtio network performance seems to have
taken a severe hit from r10 to r12

I am runing this simple test:

  hw-box$ ssh -c aes256-ctr kvm-guest dd if=/dev/zero bs=10M count=10  
/dev/null

On r10 I get 31 MB/s

On r12 I get 21 MB/s


On both systems we are running kvm with the magic

  -device-virtio-net-pci,mac=$mac,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
  -net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac


Questions

a) do you see that too ?

b) any ideas what could be causing it ?

kvm-guest is configured with 8 CPUs and 16 GB ram

cheers
tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] kvm performance regresseion r10 - r12

[Tobias Oetiker]

Hi Dan,

Today Dan McDonald wrote:


  On Oct 29, 2014, at 9:31 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
  I am still running omnios r10 ...being reluctant to upgrade,
  because we find that kvm virtio network performance seems to have
  taken a severe hit from r10 to r12
 
  I am runing this simple test:
 
   hw-box$ ssh -c aes256-ctr kvm-guest dd if=/dev/zero bs=10M count=10  
  /dev/null
 
  On r10 I get 31 MB/s
 
  On r12 I get 21 MB/s
 
 
  On both systems we are running kvm with the magic
 
   
  -device-virtio-net-pci,mac=$mac,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
   -net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac
 
 
  Questions
 
  a) do you see that too ?
 
  b) any ideas what could be causing it ?

 I'll be honest -- there are no changes in the virtio code between r151010 
 and r151012:

 r151012(~/ws/illumos-omnios)[0]% git branch
 * r151012
 r151012(~/ws/illumos-omnios)[0]% git whatchanged origin/r151010.. | grep vir
 5004 load average should be virtualized for zones
 :100644 100644 558abd8... 2e82787... M  usr/src/man/man5/environ.5
 r151012(~/ws/illumos-omnios)[0]%

 Also, if you're measuring network performance only, use netperf
 or at least iperf (both are packages you'll have to download and
 compile for now), as they are better equipped to tell you (esp.
 netperf) if you're seeing problems in latency, bandwidth, or
 both.

the reason I am using this test ist that our thinclients are doing
roughly that when they are streaming content from your thinlinc
server (running in kvm on omni).

but yes, netperf would be more reproducible ...

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] illumos-kvm network performance

[Tobias Oetiker]

Hi

I have been looking into network performance on omnios hosted kvm
hosts. especially in connection with ssh.

the test is this:

  physical-linux-host$ ssh -c aes256-cbc virtual-kvm-linux-host dd if=/dev/zero 
bs=10M count=10  /dev/null

running this simple test from a physical ubuntu 12.04 host to a
omnios hosted (virtio) ubuntu 12.04 I get ~ 9 MB/s

running the same test to a ubuntu 12.04 running on linux kvm host
I get ~ 69 MB/s

runnint the test between two physical linux hosts I get well over 100 MB/s

any hints on how to improve the performance on kvm on omnios ? Or
am I the only one seeing this ?

cheers
tobi

ps all these systems support the hw aes and running this test via
localhost returns transfer speeds over 100 MB/s on all of them

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] /lib/svc/method/logadm-upgrade - a true engineering marvel

[Tobias Oetiker]

I just did a little investigation, why my additions to /etc/logadm.d
were not showing up in /etc/logadm.conf and came upon

  /lib/svc/method/logadm-upgrade

Has the person who crafed this little marvel ever wonderd what
the meaning of upgrade is ? Seriously ? Maybe the script should
have been called

  /lib/svc/method/logadm-append-for-files-in-etc-logadm.d-newer-than-logadm.conf

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Hello znapzend question

[Tobias Oetiker]

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

 Hello Tobias,

 question about znapzend plans,

 anyway to specify time to run 30d=1d plan? example: i want run 30d=1d plan  
 every 23:00,is this possible?

there is the --pre-snap-command= which you could abuse to shift
things (sleep 23*3600) but otherwhise there is no option for this
(yet).

cheers
tobi

 i'm using demonize mode

 Regards,

 Hafiz

 - Original Message -
 From: Tobias Oetiker t...@oetiker.ch
 To: Hafiz Rafibeyli rafibe...@gmail.com
 Cc: omnios-discuss omnios-discuss@lists.omniti.com
 Sent: Tuesday, 9 September, 2014 11:54:01 AM
 Subject: Re: znapzend question

 Today Hafiz Rafibeyli wrote:

  Hello Tobias,
 
  did you try znapzend on Nexenta 4.x?anyway run it on Nexenta?

 no


  and second question:
 
  is znapzend working with volume based(block based) filesystems?

 there should be no problem ...

 cheers
 tobi

 
  regards,
 
  Hafiz
 
 
 
 



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] znapzend question

[Tobias Oetiker]

Today Hafiz Rafibeyli wrote:

 Hello Tobias,

 did you try znapzend on Nexenta 4.x?anyway run it on Nexenta?

no


 and second question:

 is znapzend working with volume based(block based) filesystems?

there should be no problem ...

cheers
tobi


 regards,

 Hafiz





-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] announcement znapzend

[Tobias Oetiker]

Hi Hafiz

sure ... from the manpage :)

--mbuffer=/usr/bin/mbuffer:31337

Specifiy the path to your copy of the mbuffer utility and the port
used on the destination. Caution: znapzend will send the data
directly from source mbuffer to destination mbuffer, thus data
stream is not encrypted.


note this has only been added recently

cheers
tobi


Yesterday Hafiz Rafibeyli wrote:

 Thanks for quick answer Tobi,

 could you please share info about  znapsend via mbuffer only(without ssh) 
 syntax?


 is this something like this?

 znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
--mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
 SRC '7d=1h,30d=4h,90d=1d' tank/home \
 DST:a '7d=1h,30d=4h,90d=1d,1y=1w,10y=1month' -O 10.0.0.1:9090


 - Original Message -
 From: Tobias Oetiker t...@oetiker.ch
 To: Hafiz Rafibeyli rafibe...@gmail.com
 Cc: omnios-discuss@lists.omniti.com
 Sent: Monday, 11 August, 2014 11:44:21 AM
 Subject: Re: [OmniOS-discuss] announcement znapzend

 Hi Hafiz,

 Today Hafiz Rafibeyli wrote:

  Tobias thank you for great job,it was missing backup  part for zfs on 
  omnios,
 
  I think ssh will slow for bigger datasets,as you mention znapzend 0.11 
  supporting use of mbuffer.
 
  I could not find mbuffer package for omnios,could you explain how to 
  setup/use mbuffer on omnios please?

 mbuffer is in the omniti repo

 # pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
 # pkg install mbuffer

 cheers
 tobi

 
  regards
 
 
 
  - Original Message -
  From: omnios-discuss-requ...@lists.omniti.com
  To: omnios-discuss@lists.omniti.com
  Sent: Tuesday, 29 July, 2014 10:29:42 PM
  Subject: OmniOS-discuss Digest, Vol 28, Issue 8
 
  Send OmniOS-discuss mailing list submissions to
  omnios-discuss@lists.omniti.com
 
  To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.omniti.com/mailman/listinfo/omnios-discuss
  or, via email, send a message with subject or body 'help' to
  omnios-discuss-requ...@lists.omniti.com
 
  You can reach the person managing the list at
  omnios-discuss-ow...@lists.omniti.com
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of OmniOS-discuss digest...
 
 
  Today's Topics:
 
 1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
 2. Re: announcement znapzend a new zfs backup tool
(Theo Schlossnagle)
 3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
 4. Re: Slow scrub performance (wuffers)
 
 
  --
 
  Message: 1
  Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
  From: Tobias Oetiker t...@oetiker.ch
  To: omnios-discuss@lists.omniti.com
  Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
  Message-ID: alpine.deb.2.02.1407291748500.6...@froburg.oetiker.ch
  Content-Type: TEXT/PLAIN; charset=US-ASCII
 
  Just out:
 
   ZnapZend a Multilevel Backuptool for ZFS
 
  It is on Github. Check out
 
   http://www.znapzend.org
 
  cheers
  tobi
 
 



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] announcement znapzend

[Tobias Oetiker]

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

 Hi Tobi,

 but where to specify destination itself?is this syntax correct?

  znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer:9090 \
 --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
  SRC '7d=1h,30d=4h,90d=1d' tank/home \
  DST:a '7d=1h,30d=4h,90d=1d,1y=1w,10y=1month' -O 10.0.0.1:9090

the destination is the same as if you were using ssh only ...
znapzend still uses ssh to discover the snapshots present at the
remote end, and to launch the mbuffer command at the receiving end


znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer:13872 \
   --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
   SRC '7d=1h,30d=4h,90d=1d' tank/home \
   DST:a '7d=1h,30d=4h,90d=1d,1y=1w,10y=1month' root@bserv:backup/home

cheers
tobi



 - Original Message -
 From: Tobias Oetiker t...@oetiker.ch
 To: Hafiz Rafibeyli rafibe...@gmail.com
 Cc: omnios-discuss@lists.omniti.com
 Sent: Tuesday, 12 August, 2014 9:12:01 AM
 Subject: Re: [OmniOS-discuss] announcement znapzend

 Hi Hafiz

 sure ... from the manpage :)

 --mbuffer=/usr/bin/mbuffer:31337

 Specifiy the path to your copy of the mbuffer utility and the port
 used on the destination. Caution: znapzend will send the data
 directly from source mbuffer to destination mbuffer, thus data
 stream is not encrypted.


 note this has only been added recently

 cheers
 tobi


 Yesterday Hafiz Rafibeyli wrote:

  Thanks for quick answer Tobi,
 
  could you please share info about  znapsend via mbuffer only(without ssh) 
  syntax?
 
 
  is this something like this?
 
  znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
 --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
  SRC '7d=1h,30d=4h,90d=1d' tank/home \
  DST:a '7d=1h,30d=4h,90d=1d,1y=1w,10y=1month' -O 10.0.0.1:9090
 
 
  - Original Message -
  From: Tobias Oetiker t...@oetiker.ch
  To: Hafiz Rafibeyli rafibe...@gmail.com
  Cc: omnios-discuss@lists.omniti.com
  Sent: Monday, 11 August, 2014 11:44:21 AM
  Subject: Re: [OmniOS-discuss] announcement znapzend
 
  Hi Hafiz,
 
  Today Hafiz Rafibeyli wrote:
 
   Tobias thank you for great job,it was missing backup  part for zfs on 
   omnios,
  
   I think ssh will slow for bigger datasets,as you mention znapzend 0.11 
   supporting use of mbuffer.
  
   I could not find mbuffer package for omnios,could you explain how to 
   setup/use mbuffer on omnios please?
 
  mbuffer is in the omniti repo
 
  # pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
  # pkg install mbuffer
 
  cheers
  tobi
 
  
   regards
  
  
  
   - Original Message -
   From: omnios-discuss-requ...@lists.omniti.com
   To: omnios-discuss@lists.omniti.com
   Sent: Tuesday, 29 July, 2014 10:29:42 PM
   Subject: OmniOS-discuss Digest, Vol 28, Issue 8
  
   Send OmniOS-discuss mailing list submissions to
 omnios-discuss@lists.omniti.com
  
   To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.omniti.com/mailman/listinfo/omnios-discuss
   or, via email, send a message with subject or body 'help' to
 omnios-discuss-requ...@lists.omniti.com
  
   You can reach the person managing the list at
 omnios-discuss-ow...@lists.omniti.com
  
   When replying, please edit your Subject line so it is more specific
   than Re: Contents of OmniOS-discuss digest...
  
  
   Today's Topics:
  
  1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
  2. Re: announcement znapzend a new zfs backup tool
 (Theo Schlossnagle)
  3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
  4. Re: Slow scrub performance (wuffers)
  
  
   --
  
   Message: 1
   Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
   From: Tobias Oetiker t...@oetiker.ch
   To: omnios-discuss@lists.omniti.com
   Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
   Message-ID: alpine.deb.2.02.1407291748500.6...@froburg.oetiker.ch
   Content-Type: TEXT/PLAIN; charset=US-ASCII
  
   Just out:
  
ZnapZend a Multilevel Backuptool for ZFS
  
   It is on Github. Check out
  
http://www.znapzend.org
  
   cheers
   tobi
  
  
 
 



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] announcement znapzend

[Tobias Oetiker]

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

 Tobias thank you for great job,it was missing backup  part for zfs on omnios,

 I think ssh will slow for bigger datasets,as you mention znapzend 0.11 
 supporting use of mbuffer.

 I could not find mbuffer package for omnios,could you explain how to 
 setup/use mbuffer on omnios please?

mbuffer is in the omniti repo

# pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
# pkg install mbuffer

cheers
tobi


 regards



 - Original Message -
 From: omnios-discuss-requ...@lists.omniti.com
 To: omnios-discuss@lists.omniti.com
 Sent: Tuesday, 29 July, 2014 10:29:42 PM
 Subject: OmniOS-discuss Digest, Vol 28, Issue 8

 Send OmniOS-discuss mailing list submissions to
   omnios-discuss@lists.omniti.com

 To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.omniti.com/mailman/listinfo/omnios-discuss
 or, via email, send a message with subject or body 'help' to
   omnios-discuss-requ...@lists.omniti.com

 You can reach the person managing the list at
   omnios-discuss-ow...@lists.omniti.com

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of OmniOS-discuss digest...


 Today's Topics:

1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
2. Re: announcement znapzend a new zfs backup tool
   (Theo Schlossnagle)
3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
4. Re: Slow scrub performance (wuffers)


 --

 Message: 1
 Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
 From: Tobias Oetiker t...@oetiker.ch
 To: omnios-discuss@lists.omniti.com
 Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
 Message-ID: alpine.deb.2.02.1407291748500.6...@froburg.oetiker.ch
 Content-Type: TEXT/PLAIN; charset=US-ASCII

 Just out:

  ZnapZend a Multilevel Backuptool for ZFS

 It is on Github. Check out

  http://www.znapzend.org

 cheers
 tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] announcement znapzend

[Tobias Oetiker]

Hi Theo,

znapzend can use mbuffers ability to do a direct tcp connection to another
mbuffer instance ...

didn't know about pv though ... neat tool!

cheers
tobi

http://www.znapzend.org

Yesterday Theo Schlossnagle wrote:

 OmniOS ships with pipeviewer (pv), if you use pv -s several megs, it
 would have close to the same effect as using mbuffer.


 On Mon, Aug 11, 2014 at 2:06 AM, Hafiz Rafibeyli rafibe...@gmail.com
 wrote:

  Tobias thank you for great job,it was missing backup  part for zfs on
  omnios,
 
  I think ssh will slow for bigger datasets,as you mention znapzend 0.11
  supporting use of mbuffer.
 
  I could not find mbuffer package for omnios,could you explain how to
  setup/use mbuffer on omnios please?
 
  regards
 
 
 
  - Original Message -
  From: omnios-discuss-requ...@lists.omniti.com
  To: omnios-discuss@lists.omniti.com
  Sent: Tuesday, 29 July, 2014 10:29:42 PM
  Subject: OmniOS-discuss Digest, Vol 28, Issue 8
 
  Send OmniOS-discuss mailing list submissions to
  omnios-discuss@lists.omniti.com
 
  To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.omniti.com/mailman/listinfo/omnios-discuss
  or, via email, send a message with subject or body 'help' to
  omnios-discuss-requ...@lists.omniti.com
 
  You can reach the person managing the list at
  omnios-discuss-ow...@lists.omniti.com
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of OmniOS-discuss digest...
 
 
  Today's Topics:
 
 1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
 2. Re: announcement znapzend a new zfs backup tool
(Theo Schlossnagle)
 3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
 4. Re: Slow scrub performance (wuffers)
 
 
  --
 
  Message: 1
  Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
  From: Tobias Oetiker t...@oetiker.ch
  To: omnios-discuss@lists.omniti.com
  Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
  Message-ID: alpine.deb.2.02.1407291748500.6...@froburg.oetiker.ch
  Content-Type: TEXT/PLAIN; charset=US-ASCII
 
  Just out:
 
   ZnapZend a Multilevel Backuptool for ZFS
 
  It is on Github. Check out
 
   http://www.znapzend.org
 
  cheers
  tobi
 
  --
  Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
  www.oetiker.ch t...@oetiker.ch +41 62 775 9902
 
 
 
  --
 
  Message: 2
  Date: Tue, 29 Jul 2014 11:54:07 -0400
  From: Theo Schlossnagle je...@omniti.com
  To: OmniOS-discuss@lists.omniti.com
  omnios-discuss@lists.omniti.com
  Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
  tool
  Message-ID:
  
  caclsaptc_wdb+stkw2-jzkgp7oqz4oweuwg_nnrm_xkaook...@mail.gmail.com
  Content-Type: text/plain; charset=utf-8
 
  Awesome!
 
 
  On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
   Just out:
  
ZnapZend a Multilevel Backuptool for ZFS
  
   It is on Github. Check out
  
http://www.znapzend.org
  
   cheers
   tobi
  
   --
   Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
   www.oetiker.ch t...@oetiker.ch +41 62 775 9902
  
   ___
   OmniOS-discuss mailing list
   OmniOS-discuss@lists.omniti.com
   http://lists.omniti.com/mailman/listinfo/omnios-discuss
  
 
 
 
  --
 
  Theo Schlossnagle
 
  http://omniti.com/is/theo-schlossnagle
  -- next part --
  An HTML attachment was scrubbed...
  URL: 
  http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/f8adbbf5/attachment-0001.html
  
 
  --
 
  Message: 3
  Date: Tue, 29 Jul 2014 17:59:18 +0200
  From: Saso Kiselkov skiselkov...@gmail.com
  To: omnios-discuss@lists.omniti.com
  Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
  tool
  Message-ID: 53d7c4d6.5060...@gmail.com
  Content-Type: text/plain; charset=ISO-8859-1
 
  On 7/29/14, 5:50 PM, Tobias Oetiker wrote:
   Just out:
  
ZnapZend a Multilevel Backuptool for ZFS
  
   It is on Github. Check out
  
http://www.znapzend.org
 
  Neat, especially the feature that the backup config is part of a
  dataset's properties. Very cool.
 
  --
  Saso
 
 
 
  --
 
  Message: 4
  Date: Tue, 29 Jul 2014 15:29:38 -0400
  From: wuffers m...@wuffers.net
  To: Richard Elling richard.ell...@richardelling.com
  Cc: omnios-discuss omnios-discuss@lists.omniti.com
  Subject: Re: [OmniOS-discuss] Slow scrub performance
  Message-ID:
  
  ca+tr_kwx_1hn4tva+-zofjk2mn7re-nfh31smctno7tjjjf...@mail.gmail.com
  Content-Type: text/plain; charset=utf-8
 
  Going to try to answer both responses in one message..
 
  Short answer, yes. ? Keep in mind that
  
   1. a scrub runs in the background (so as not to impact production I/O,
   this was not always

[OmniOS-discuss] announcement znapzend a new zfs backup tool

[Tobias Oetiker]

Just out:

 ZnapZend a Multilevel Backuptool for ZFS

It is on Github. Check out

 http://www.znapzend.org

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] zfs diskusage

[Tobias Oetiker]

Today we were out of diskspace on one of our pools ... a few removed
snapshots later all is fine, except that I find that I don't realy
understand the numbers ... can anyone elighten me?

# zpool list fast
NAME   SIZE  ALLOC   FREE  EXPANDSZCAP  DEDUP  HEALTH  ALTROOT
fast  4.34T  1.74T  2.61T -39%  1.22x  ONLINE  -

# zfs list fast
NAME   USED  AVAIL  REFER  MOUNTPOINT
fast  2.59T   716G  78.5K  /fast

Why does the 'zpool list' claim that 2.61T is free (61%)
while 'zfs list' sees 716G free (27%)

I know there is raidz2 and compression so the numbers  don't match
up, but I don't understand why the ratio is so different between
the two.

I checked on other filesystems and there the view from zpool and
zfs look much more similar.

cheers
tobi

ps. the dedup ratio is a leftover from a time when I tried dedup.

$ zpool get all fast
NAME  PROPERTY   VALUE  SOURCE
fast  size   4.34T  -
fast  capacity   39%-
fast  altroot-  default
fast  health ONLINE -
fast  guid   16524146496274345089   default
fast  version-  default
fast  bootfs -  default
fast  delegation on default
fast  autoreplaceoffdefault
fast  cachefile  -  default
fast  failmode   wait   default
fast  listsnapshots  offdefault
fast  autoexpand offdefault
fast  dedupditto 0  default
fast  dedupratio 1.22x  -
fast  free   2.61T  -
fast  allocated  1.74T  -
fast  readonly   off-
fast  comment-  default
fast  expandsize 0  -
fast  freeing0  default
fast  feature@async_destroy  enabledlocal
fast  feature@empty_bpobjactive local
fast  feature@lz4_compress   active local
fast  feature@multi_vdev_crash_dump  enabledlocal
fast  feature@spacemap_histogram active local
fast  feature@extensible_dataset enabledlocal

$ zfs get all fast
NAME  PROPERTY  VALUE  SOURCE
fast  type  filesystem -
fast  creation  Fri Jan  4 17:19 2013  -
fast  used  2.59T  -
fast  available 716G   -
fast  referenced78.5K  -
fast  compressratio 1.81x  -
fast  mounted   yes-
fast  quota none   default
fast  reservation   none   default
fast  recordsize128K   default
fast  mountpoint/fast  default
fast  sharenfs  offdefault
fast  checksum  on default
fast  compression   lz4local
fast  atime on default
fast  devices   on default
fast  exec  on default
fast  setuidon default
fast  readonly  offdefault
fast  zoned offdefault
fast  snapdir   hidden default
fast  aclmode   discarddefault
fast  aclinheritrestricted default
fast  canmount  on default
fast  xattr on default
fast  copies1  default
fast  version   5  -
fast  utf8only  off-
fast  normalization none   -
fast  casesensitivity   sensitive  -
fast  vscan offdefault
fast  nbmandoffdefault
fast  sharesmb  offdefault
fast  refquota  none   default
fast  refreservationnone   default

Re: [OmniOS-discuss] zpool degraded while smart sais disks are OK

[Tobias Oetiker]

Hi Richard,

Mar 23 Richard Elling wrote:


 On Mar 21, 2014, at 10:13 PM, Tobias Oetiker t...@oetiker.ch wrote:

  Yesterday Richard Elling wrote:
 
 
  On Mar 21, 2014, at 3:23 PM, Tobias Oetiker t...@oetiker.ch wrote:
 
  [...]
 
  it happened over time as you can see from the timestamps in the
  log. The errors from zfs's point of view were 1 read and about 30 write
 
  but according to smart the disks are without flaw
 
  Actually, SMART is pretty dumb. In most cases, it only looks for 
  uncorrectable
  errors that are related to media or heads. For a clue to more permanent 
  errors,
  you will want to look at the read/write error reports for errors that are
  corrected with possible delays. You can also look at the grown defects 
  list.
 
  This behaviour is expected for drives with errors that are not being 
  quickly
  corrected or have firmware bugs (horrors!) and where the disk does not do 
  TLER
  (or its vendor's equivalent)
  -- richard
 
  the error counters look like this:
 
 
  Error counter log:
Errors Corrected by   Total   Correction Gigabytes
  Total
ECC  rereads/errors   algorithm  processed
  uncorrected
fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  
  errors
  read:   34940 0  3494  44904530.879 
0
  write: 00 0 0  39111   1793.323 
0
  verify:00 0 0   8133  0.000 
0

 Errors corrected without delay looks good. The problem lies elsewhere.

 
  the disk vendor is HGST in case anyone has further ideas ... the system has 
  20 of these disks and the problems occured with
  three of them. The system has been running fine for two months previously.

 ...and yet there are aborted commands, likely due to a reset after a timeout.
 Resets aren't issued without cause.

 There are two different resets issued by the sd driver: LU and bus. If the
 LU reset doesn't work, the resets are escalated to bus. This is, of course,
 tunable, but is rarely tuned. A bus reset for SAS is a questionable practice,
 since SAS is a fabric, not a bus. But the effect of a device in the fabric
 being reset could be seen as aborted commands by more than one target. To
 troubleshoot these cases, you need to look at all of the devices in the data
 path and map the common causes: HBAs, expanders, enclosures, etc. Traverse
 the devices looking for errors, as you did with the disks. Useful tools:
 sasinfo, lsiutil/sas2ircu, smp_utils, sg3_utils, mpathadm, fmtopo.

thanks for the hints ... after detatching/attaching the 'failed'
disks, they got resilvered and a subsequent scrub did not detect
any errors ...

all a bit mysterious ... will keep an eye on the box to see how it
fares on the future ...

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
*** We are hiring IT staff: www.oetiker.ch/jobs ***
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] zpool degraded while smart sais disks are OK

[Tobias Oetiker]

a zpool on one of our boxes has been degraded with several disks
faulted ...

* the disks are all sas direct attached
* according to smartctl the offending disks have no faults.
* zfs decided to fault the disks after the events below.

I have now told the pool to clear the errors and it is resilvering the disks 
... (in progress)

any idea what is happening here ?

Mar  2 22:21:51 foo scsi: [ID 243001 kern.warning] WARNING: 
/pci@0,0/pci8086,3c04@2/pci1000,3020@0 (mpt_sas0):
Mar  2 22:21:51 foo mptsas_handle_event_sync: IOCStatus=0x8000, 
IOCLogInfo=0x3117
Mar  2 22:21:51 foo scsi: [ID 243001 kern.warning] WARNING: 
/pci@0,0/pci8086,3c04@2/pci1000,3020@0 (mpt_sas0):
Mar  2 22:21:51 foo mptsas_handle_event: IOCStatus=0x8000, 
IOCLogInfo=0x3117
Mar  2 22:21:51 foo scsi: [ID 365881 kern.info] 
/pci@0,0/pci8086,3c04@2/pci1000,3020@0 (mpt_sas0):
Mar  2 22:21:51 foo Log info 0x3117 received for target 11.
Mar  2 22:21:51 foo scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc
Mar  2 22:21:51 foo scsi: [ID 365881 kern.info] 
/pci@0,0/pci8086,3c04@2/pci1000,3020@0 (mpt_sas0):
Mar  2 22:21:51 foo Log info 0x3117 received for target 11.
Mar  2 22:21:51 foo scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc


Mar  5 02:20:53 foo scsi: [ID 243001 kern.warning] WARNING: 
/pci@0,0/pci8086,3c06@2,2/pci1000,3020@0 (mpt_sas1):
Mar  5 02:20:53 foo mptsas_handle_event_sync: IOCStatus=0x8000, 
IOCLogInfo=0x3117
Mar  5 02:20:53 foo scsi: [ID 243001 kern.warning] WARNING: 
/pci@0,0/pci8086,3c06@2,2/pci1000,3020@0 (mpt_sas1):
Mar  5 02:20:53 foo mptsas_handle_event: IOCStatus=0x8000, 
IOCLogInfo=0x3117
Mar  5 02:20:53 foo scsi: [ID 365881 kern.info] 
/pci@0,0/pci8086,3c06@2,2/pci1000,3020@0 (mpt_sas1):
Mar  5 02:20:53 foo Log info 0x3117 received for target 10.
Mar  5 02:20:53 foo scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc
Mar  5 02:20:53 foo scsi: [ID 365881 kern.info] 
/pci@0,0/pci8086,3c06@2,2/pci1000,3020@0 (mpt_sas1):
Mar  5 02:20:53 foo Log info 0x3117 received for target 10.
Mar  5 02:20:53 foo scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
*** We are hiring IT staff: www.oetiker.ch/jobs ***
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] zpool degraded while smart sais disks are OK

[Tobias Oetiker]

Today Zach Malone wrote:

 On Fri, Mar 21, 2014 at 3:50 PM, Richard Elling
 richard.ell...@richardelling.com wrote:
 
  On Mar 21, 2014, at 9:48 AM, Tobias Oetiker t...@oetiker.ch wrote:
 
  a zpool on one of our boxes has been degraded with several disks
  faulted ...
 
  * the disks are all sas direct attached
  * according to smartctl the offending disks have no faults.
  * zfs decided to fault the disks after the events below.
 
  I have now told the pool to clear the errors and it is resilvering the disks
  ... (in progress)
 
  any idea what is happening here ?

 ...

 Did all the disks fault at the same time, or was it spread out over a
 longer period?  I'd suspect your power supply or disk controller.
 What are your zpool errors?

it happened over time as you can see from the timestamps in the
log. The errors from zfs's point of view were 1 read and about 30 write

but according to smart the disks are without flaw

cheers
tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
*** We are hiring IT staff: www.oetiker.ch/jobs ***
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] zpool degraded while smart sais disks are OK

[Tobias Oetiker]

Yesterday Richard Elling wrote:


 On Mar 21, 2014, at 3:23 PM, Tobias Oetiker t...@oetiker.ch wrote:

[...]
 
  it happened over time as you can see from the timestamps in the
  log. The errors from zfs's point of view were 1 read and about 30 write
 
  but according to smart the disks are without flaw

 Actually, SMART is pretty dumb. In most cases, it only looks for uncorrectable
 errors that are related to media or heads. For a clue to more permanent 
 errors,
 you will want to look at the read/write error reports for errors that are
 corrected with possible delays. You can also look at the grown defects list.

 This behaviour is expected for drives with errors that are not being quickly
 corrected or have firmware bugs (horrors!) and where the disk does not do TLER
 (or its vendor's equivalent)
  -- richard

the error counters look like this:


Error counter log:
   Errors Corrected by   Total   Correction Gigabytes
Total
   ECC  rereads/errors   algorithm  processed
uncorrected
   fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  
errors
read:   34940 0  3494  44904530.879 
  0
write: 00 0 0  39111   1793.323 
  0
verify:00 0 0   8133  0.000 
  0

the disk vendor is HGST in case anyone has further ideas ... the system has 20 
of these disks and the problems occured with
three of them. The system has been running fine for two months previously.

Vendor:   HGST
Product:  HUS724030ALS640
Revision: A152
User Capacity:3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Serial number:P8J20SNV
Device type:  disk
Transport protocol:   SAS

cheers
tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
*** We are hiring IT staff: www.oetiker.ch/jobs ***
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] iscsi timeouts

[Tobias Oetiker]

Hi,

we are serving ISCSI volumes from our omnios box ... in the log on
the client I keep seeing this pattern every few hours.

any idea what could be causing this ?

server and client are directly via a crossover cable over a dedicated interface.

Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: ping 
timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 
4557605264, now 4557606516 [kern.err]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: 
detected conn error (1011) [kern.info]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: ping 
timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last ping 
4557605264, now 4557606516 [kern.err]
Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: 
detected conn error (1011) [kern.info]
Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 
error (1011) state (3) [daemon.warning]
Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 
error (1011) state (3) [daemon.warning]
Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 10.10.10.1 
not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 10.10.10.1 
not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 10.10.10.1 
not responding, still trying [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 10.10.10.1 
OK [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 10.10.10.1 
OK [kern.notice]
Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 10.10.10.1 
OK [kern.notice]
Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after 
recovery (2 attempts) [daemon.warning]
Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after 
recovery (2 attempts) [daemon.warning]

chers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] iscsi timeouts

[Tobias Oetiker]

Today Dan McDonald wrote:


 On Jan 21, 2014, at 7:21 AM, Narayan Desai narayan.de...@gmail.com wrote:

  We've seen problems like this when we have a SATA drive in a SAS expander 
  that is going out to lunch. Are there any drives showing errors in iostat 
  -En? or any drive timeout messages in the ring buffer?

 Generally speaking -- you use a SATA drive in a SAS expander at
 your own risk.  I used to be at Nexenta, and they would not
 support customers who deployed SATA drives on SAS expanders.
 These days, the price delta between SAS and SATA (for enterprise)
 is small enough to be worth it for the headaches you avoid.

we are not using sata NOR a sas expander ...

we have a bunch of sas drives directly attached to sas controller
ports each ... (the ssd drives are sata but they are directly
attached to individual sas ports too)

we have several system setup in a similar manner, and the problem
only manifests on this one ... but it is also the most busy of the
bunch.

cheers
tobi

 Dan




-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] iscsi timeouts

[Tobias Oetiker]

Hi Tim,

Today Tim Rice wrote:

 On Tue, 21 Jan 2014, Tobias Oetiker wrote:

  Hi,
 
  we are serving ISCSI volumes from our omnios box ... in the log on
  the client I keep seeing this pattern every few hours.
 
  any idea what could be causing this ?
 
  server and client are directly via a crossover cable over a dedicated 
  interface.

 It might be a good idea to tell the list what network cards you are using.
 If they are 1G cards and you are using a Cat 5e cable, do yourself a
 favor and replace it with a Cat 6 cable.

sure, we have intel on-board controllers

07:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection 
(rev 01)
Subsystem: Intel Corporation Device 3584
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at d096 (32-bit, non-prefetchable)
I/O ports at 1060
Memory at d09b (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=10 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [e0] Vital Product Data

the cable issue I have to verify ...

the odd thing about this behaviour is, that there are several kvm
virtual machines running on this box as well, and even when omnios
goes 'offline' the kvm hosts (talking over the same physical
interface) are still reachable. They themselfs can not talk to
omnios either ...

cheers
tobi

  Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604535]  connection1:0: 
  ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last 
  ping 4557605264, now 4557606516 [kern.err]
  Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604656]  connection1:0: 
  detected conn error (1011) [kern.info]
  Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604661]  connection2:0: 
  ping timeout of 5 secs expired, recv timeout 5, last rx 4557604012, last 
  ping 4557605264, now 4557606516 [kern.err]
  Jan 21 01:21:34 iscsi-client kernel:  : [1048707.604763]  connection2:0: 
  detected conn error (1011) [kern.info]
  Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 1:0 
  error (1011) state (3) [daemon.warning]
  Jan 21 01:21:35 iscsi-client iscsid:  Kernel reported iSCSI connection 2:0 
  error (1011) state (3) [daemon.warning]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048713.496478] nfs: server 
  10.10.10.1 not responding, still trying [kern.notice]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048717.843552] nfs: server 
  10.10.10.1 not responding, still trying [kern.notice]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048718.087086] nfs: server 
  10.10.10.1 not responding, still trying [kern.notice]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048730.558551] nfs: server 
  10.10.10.1 OK [kern.notice]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559623] nfs: server 
  10.10.10.1 OK [kern.notice]
  Jan 21 01:21:57 iscsi-client kernel:  : [1048730.559654] nfs: server 
  10.10.10.1 OK [kern.notice]
  Jan 21 01:21:59 iscsi-client iscsid:  connection1:0 is operational after 
  recovery (2 attempts) [daemon.warning]
  Jan 21 01:21:59 iscsi-client iscsid:  connection2:0 is operational after 
  recovery (2 attempts) [daemon.warning]
 
  chers
  tobi
 



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] iscsi timeouts

[Tobias Oetiker]

Hi Nld,

Today Narayan Desai wrote:

 Sorry, I should have given the requisite yes, I know that this is a recipe
 for sadness, for I too have experienced said sadness.

 That said, we've seen this kind of problem when there was a device in a
 vdev that was dying a slow death. There wouldn't necessarily be any sign,
 aside from insanely high service times on an individual device in the pool.
 From this, I assume that ZFS is still sensitive to variation in underlying
 drive performance.

 Tobi, what do your drive service times look like?
  -nld

the drives seem fine, smart is not reporting anything out of the
ordinary and also iostat -En shows 0 on all counts

I don't think it is a disk issue, but rather something connected
with the network ...

On times the machine becomes unreachable for some time, and then it
is possible to login via console and all seems well internally.
setting the network interface offline and then online again using
the dladm tool brings the connectivity back immediatly. waiting
helps as well ... since the problem sorts itself out after a few
seconds to minutes ...

we just had another 'off the net' periode for 30 minutes

unfortunately omnios itself does not seem to realize that something
is off, at least dmesg does not show any kernel messages about this
problem ...

we have several systems running on the S2600CP MB ... this is the
only one showing problems ...

the next thing I intend todo is to upgrade the MB firmware since I
found that this box has an older version than the other ones ...

System Configuration: Intel Corporation S2600CP
BIOS Configuration: Intel Corp. SE5C600.86B.01.06.0002.110120121539 11/01/2012

other ideas, most welcome !

cheers
tobi


 On Tue, Jan 21, 2014 at 7:58 AM, Dan McDonald dan...@omniti.com wrote:

 
  On Jan 21, 2014, at 7:21 AM, Narayan Desai narayan.de...@gmail.com
  wrote:
 
   We've seen problems like this when we have a SATA drive in a SAS
  expander that is going out to lunch. Are there any drives showing errors in
  iostat -En? or any drive timeout messages in the ring buffer?
 
  Generally speaking -- you use a SATA drive in a SAS expander at your own
  risk.  I used to be at Nexenta, and they would not support customers who
  deployed SATA drives on SAS expanders.  These days, the price delta between
  SAS and SATA (for enterprise) is small enough to be worth it for the
  headaches you avoid.
 
  Dan
 
 
 


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] iscsi timeouts

[Tobias Oetiker]

Today Saso Kiselkov wrote:

  I guess you can check for this string at runtime:
  $ strings /kernel/drv/amd64/igb | grep _eee_support
 
  If it is missing, then it could be the buggy EEE support that's throwing
  your link out of whack here.
 
  Nevermind, missed your description of the KVM guests being reachable
  while only the host goes offline... Did snoop show anything arriving at
  the host while it is offline?

 However, on second thought, you did mention that you're running
 crossover between two hosts, which would match the description of the
 EEE issue:

 https://illumos.org/issues/3534
 The energy efficient Ethernet (EEE) support in Intel's I350 GigE NIC
 drops link on directly-attached link cases.

 Anyhow, make sure you're running the EEE fix.


I think that is in

# strings /kernel/drv/amd64/igb | grep _eee_support
_eee_support

the issue manifests also on the main interface ...

the worst case scenario is, that some odd ethernet packet, present only
in the wild-west-network where this box lives is sending the
network stack into some sort of a tail-spin ...

cheers
tobi
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] igb0 'hangs'

[Tobias Oetiker]

I just had an odd thing happening to my r151008 server. It suddenly
stopped communicating over its igb0 interface ...

Upon further investigation I found:

a) several KVM guests talking over the same physical interface were
   still happily chatting

b) logging into the guests and trying to reach the server over that
   route did not work either.

c) accessing the server via the hardware console revealed that it
   was working and did not seem to realize that igb0 was having a
   problem. At least dmesg did not show anyithing interesting.

   once I did

   # ipadm down-addr igb0/v4static
   # ipadm up-addr igb0/v4static

   the interface started working again ...

any idea what has happened here ?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [discuss] background snapshot destruction impact

[Tobias Oetiker]

Hi Richard,

Yesterday Richard Elling wrote:

 On Dec 22, 2013, at 4:23 PM, Tobias Oetiker t...@oetiker.ch wrote:

  Hi Richard,
 
  Yesterday Richard Elling wrote:
 
  c) shouldn't the smarter write throttle change
   
  https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e
   have helped with this by makeing zfs do its internal things
   with a lower priority.
 
  Yes, but the default zfs_vdev_max_pending remains at 10. Once
  the I/Os are sent to disk, there is no priority scheduling. You
  should consider lowering zfs_vdev_max_pending to allow the ZIO
  scheduler to do a better job of rescheduling the more important
  I/Os.
 
  the patch mentioned introduces a ton of new tuneables but it
  removes zfs_vdev_max_pending

 Indeed, these are now zfs_vdev_max_active and friends.
 It is very unclear to me what your graphite is attempting to show.
 Is this data from the pool itself, or from vdevs under the pool?
 The pool-level stats are mostly useless for this analysis, need to
 see the per-vdev stats.

the reason I am interested in this is that while the removal
operation is active, all data access to data not already in ARC
this is very slow ...  'ls' in a directory with 10 entries takes
several seconds to complete.

iostat -xnd 10 returns lines like this:

extended device statistics
r/sw/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
   85.3  265.1  350.4 3280.5 22.4  0.9   63.82.5   6   8 fast
0.00.00.00.0  0.0  0.00.00.0   0   0 rpool
0.00.20.00.0  0.0  0.00.00.0   0   0 
c0t5001517BB2AD9526d0
0.00.20.00.0  0.0  0.00.00.0   0   0 
c0t5001517BB2AD9589d0
0.0   92.80.0 1205.7  0.0  0.00.00.1   0   1 
c0t5001517803D28EA3d0
0.6  331.80.4  789.1  0.0  1.40.04.2   0  99 
c24t5000CCA03E45E11Dd0
   11.1   25.6   49.9  302.8  0.0  0.10.03.2   0   5 
c20t50014EE700052642d0
0.3  394.60.2  919.5  0.0  1.20.03.1   0  99 
c25t5000CCA03E45E25Dd0
   10.5   24.4   43.4  302.4  0.0  0.10.03.2   0   5 
c19t50014EE70005217Ed0
0.00.00.00.0  0.0  0.00.00.0   0   0 
c29t5000CCA03E404FDDd0
   12.0   23.8   42.5  301.2  0.0  0.10.03.4   0   5 
c15t50014EE70005248Ed0
0.4  427.30.3  960.5  0.0  1.70.03.9   0  99 
c28t5000CCA03E426985d0
9.2   24.3   45.5  302.1  0.0  0.10.03.2   0   5 
c18t50014EE7AAAFCC0Ad0
0.6  380.20.5 1061.0  0.0  1.80.04.6   0  99 
c22t5000CCA03E45E211d0
   11.1   24.8   49.1  301.2  0.0  0.10.03.0   0   5 
c14t50014EE7555A792Ed0
0.4  330.60.3  800.3  0.0  1.30.03.9   0  99 
c26t5000CCA03E420D4Dd0
   10.4   24.7   35.8  302.7  0.0  0.10.02.6   0   4 
c17t50014EE7555A7B7Ad0
0.6  371.70.5  901.7  0.0  1.20.03.1   0  99 
c23t5000CCA03E434C41d0
   10.4   27.3   52.0  302.1  0.0  0.10.03.1   0   5 
c13t50014EE700052386d0
0.3  347.40.3  766.9  0.0  1.70.04.8   0 100 
c27t5000CCA03E4229ADd0
   10.6   24.2   32.3  301.3  0.0  0.10.02.8   0   5 
c16t50014EE7555A7B4Ad0
3.2 2607.42.3 6539.9 3610203.4 10.2 1382912.33.9 100 100 slow

the config of the pool is this:

NAME STATE READ WRITE CKSUM
slowpool ONLINE   0 0 0
  raidz2-0   ONLINE   0 0 0
c22t5000CCA03E45E211d0   ONLINE   0 0 0
c23t5000CCA03E434C41d0   ONLINE   0 0 0
c24t5000CCA03E45E11Dd0   ONLINE   0 0 0
c25t5000CCA03E45E25Dd0   ONLINE   0 0 0
c26t5000CCA03E420D4Dd0   ONLINE   0 0 0
c27t5000CCA03E4229ADd0   ONLINE   0 0 0
c28t5000CCA03E426985d0   ONLINE   0 0 0
logs
  mirror-1   ONLINE   0 0 0
c0t5001517BB2AD9526d0s3  ONLINE   0 0 0
c0t5001517BB2AD9589d0s3  ONLINE   0 0 0
cache
  c0t5001517803D28EA3d0s1ONLINE   0 0 0
spares
  c29t5000CCA03E404FDDd0 AVAIL



  ? richard



 ---
 illumos-discuss
 Archives: https://www.listbox.com/member/archive/182180/=now
 RSS Feed: https://www.listbox.com/member/archive/rss/182180/25228367-6b1cb39c
 Modify Your Subscription: 
 https://www.listbox.com/member/?member_id=25228367id_secret=25228367-5c415042
 Powered by Listbox: http://www.listbox.com



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] background snapshot destruction impact

[Tobias Oetiker]

I am running omnios r151008 on a recent box with 3gig SAS disks
arranged in a raidz2 pool.

I have this 7TB filesystem where I have my zimbra server store its
backups.  The backup-sets are highly redundant, so for a time I had
deduplication turned on to great effect, but as the size of the
backup-sets grew, I ran out of ram and performance on the system
became realy bad. So I turned deduplication of. Performance for
newly written data is fine again.

The other day, I destroyed a bunch of old snapshots on this
filesysem. Thanks to background destruction this did not realy take
a long time. But now as background destruction is progressing, the
system remains very slugish when doing io on the pool where
the destruction is taking place.

I put up some graphs and raw data on

  http://tobi.oetiker.ch/background-destruction/

to show the state of things.

My Questions:

a) would it be faster to send/receive the content of the
   deduplicated filesystem to a new non deduplicated
   and then destroy the entire filesystem (not the pool).

b) is there a way to monitor progress on the background
   destruction?

c) shouldn't the smarter write throttle change
   
https://github.com/illumos/illumos-gate/commit/69962b5647e4a8b9b14998733b765925381b727e
   have helped with this by makeing zfs do its internal things
   with a lower priority.

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] strange io-pattern

[Tobias Oetiker]

Hi Paul,

Today Paul Jochum wrote:

 Hi Tobias:

     Sorry, I don't know why you are having these strang io-patterns, but I 
 was wondering if you could share how you
 record and display this info?

I created a little plugin for collectd to interface with iostat. I
guess having one for vfsstat and arcstat along the same lines would
give a better picture as to what users actually experience but this
one gives some impression as to what happens deep down.

#!/usr/bin/perl
my $filter = $ARGV[0] || '.+';

my $pid = open my $iostat, -|, 
/usr/bin/iostat,-Tu,-xnr,int($ENV{COLLECTD_INTERVAL}) or die launching 
iostat: $!;

$SIG{PIPE} = 'ignore';
$SIG{CHLD} = 'ignore';
$SIG{TERM} = sub {
   kill 9,$pid;
   exit 1;
};

my %data;
my @cols;
my $round = 0;
while ($iostat){
chomp;
my @input = split /,/;
if ($#input == 0 and $input[0] =~ /^\d+$/){
publish() if $round++  1;
%data = ();
next;
}
if ($input[-1] eq 'device'){
@cols = @input;
pop @cols;
next;
}
if ($#input == $#cols+1){
my $dev = pop @input;
my %row;
@row{@cols} = @input;
$data{$dev} = \%row;
};
}

sub publish {
$|=0;
my $time = time();
for my $dev (sort keys %data){
next unless $dev =~ /^${filter}$/;
my $d = $data{$dev};
my $prefix = PUTVAL 
$ENV{COLLECTD_HOSTNAME}/sol_iostat-$dev/sol_iostat_;
print $prefix.op $time:$d-{'r/s'}:$d-{'w/s'}\n;
print $prefix.byte 
$time:.($d-{'kr/s'}*1024).:.($d-{'kw/s'}*1024).\n;
print $prefix.busypct $time:$d-{'%w'}:$d-{'%b'}\n;
print $prefix.wait $time:$d-{wait}\n;
print $prefix.actv $time:$d-{actv}\n;
print $prefix.wsvc_t $time:.($d-{wsvc_t}/1000).\n;
print $prefix.asvc_t $time:.($d-{asvc_t}/1000).\n;
}
}

-
adding these new types to the types.db

sol_iostat_op   read:GAUGE:0:U, write:GAUGE:0:U
sol_iostat_byte read:GAUGE:0:U, write:GAUGE:0:U
sol_iostat_busypct  queue:GAUGE:0:100, disk:GAUGE:0:100
sol_iostat_wait count:GAUGE:0:U
sol_iostat_actv count:GAUGE:0:U
sol_iostat_wsvc_t   second:GAUGE:0:U
sol_iostat_asvc_t   second:GAUGE:0:U

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] strange io-pattern

[Tobias Oetiker]

Hi Henk,

Today Henk Langeveld wrote:

 There's a known problem with iostat -xn  on multi-processor systems that I
 posted on the illumos-list
 back in September/October, where we occasionally see an astronomical spike in
 the io wait and service times.

 This appears to be caused by the hires kernel timer used by the kstat_io
 routines, which produces increasing
 values of timestamps *per* *physical* *cpu*.  When io events are handled by
 different cpus, the delta_t can
 become negative, as the result of a 64bit int underflow.

 These occurrences are rare, but frequent enough to mess up those wait times.
 Also, the wait times only show
 up with the combined '-x' and '-n'  options.

 Can you eliminate the possibility of such an incident?

 I intended to post a bug report on this, but I've moved on since then, and
 don't have access to
 any multi-cpu hardware right now.  I *think* I've seen it once in a multi-cpu
 virtualbox instance, but have not
 been able to reproduce that.  (This would suggest that virtualbox actually
 emulates the physical cpu registers.)

have a look at the graphs attached to my original post, its not a
spiking problem I think ...

cheers
tobi


 Cheers,
 Henk


 On 13/12/2013 14:13, Tobias Oetiker wrote:
  I created a little plugin for collectd to interface with iostat. I
  guess having one for vfsstat and arcstat along the same lines would
  give a better picture as to what users actually experience but this
  one gives some impression as to what happens deep down.
 
  #!/usr/bin/perl
  my $filter = $ARGV[0] || '.+';
 
  my $pid = open my $iostat, -|,
  /usr/bin/iostat,-Tu,-xnr,int($ENV{COLLECTD_INTERVAL}) or die
  launching iostat: $!;
 

 ___
 OmniOS-discuss mailing list
 OmniOS-discuss@lists.omniti.com
 http://lists.omniti.com/mailman/listinfo/omnios-discuss



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] userland woes

[Tobias Oetiker]

Hi Eric,

Today Eric Sproul wrote:

 On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker t...@oetiker.ch wrote:
  Following the latest instructions from your webpage, we tried this:
 
pkg list incorporation/jeos/omnios-userland /dev/null 21 || pkg 
  install incorporation/jeos/omnios-userland@11,5.11-0.151006
 
  now, if we run
 
# pkg update -nv
 
  we get
 
   Creating Plan /
   pkg update: No solution was found to satisfy constraints
   Plan Creation: Package solver has not found a solution to update to latest 
  available versions.
   This may indicate an overly constrained set of packages are installed.

 Hi Tobi,
 It's possible you have packages that are holding back the update.  Do
 you use the ms.omniti.com publisher?  Recent builds there incorporate
 on entire at the release on which they were built, to ensure they
 don't get installed on the wrong release.

 You can check to see if any unexpected incorporate dependencies exist
 with pkg search:

 pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq

 Under normal circumstances (that is, you use only packages from the
 omnios publisher) you should see only entire, illumos-gate and
 omnios-userland.  If you see anything else, that's something to
 investigate.

ah, we are getting closer ...

we have installed some packages from our own repository
pkg.oetiker.ch and these packages themselfe have dependencies on
ms.omniti.com stuff.

namely the following:

 $ pkg uninstall -nv libgcrypt
 Creating Planpkg uninstall: Cannot remove
 
'pkg://ms.omniti.com/omniti/security/libgcrypt@1.5.3,5.11-0.151006:20130810T181134Z'
 due to the following packages that depend on it:

 pkg://pkg.oetiker.ch/system/collectd@5.4.0,5.11-0.151007:20131005T114950Z

does this mean we have to rebuild the collectd package for 0.151008
because its dependency on ms.omniti.com is going away ?

cheers
tobi


 Eric



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] userland woes

[Tobias Oetiker]

Following the latest instructions from your webpage, we tried this:

  pkg list incorporation/jeos/omnios-userland /dev/null 21 || pkg install 
incorporation/jeos/omnios-userland@11,5.11-0.151006

now, if we run

  # pkg update -nv

we get

 Creating Plan /
 pkg update: No solution was found to satisfy constraints
 Plan Creation: Package solver has not found a solution to update to latest 
available versions.
 This may indicate an overly constrained set of packages are installed.

 latest incorporations:

  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151008:20131204T022427Z
  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151008:20131206T160517Z
  pkg://omnios/entire@11,5.11-0.151008:20131205T195242Z
  pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151008:20131204T024149Z
 Dependency analysis is unable to determine exact cause.
 Try specifying expected results to obtain more detailed error messages.


cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] SuperStorage Server 6047R-E1R36L SAS Question

[Tobias Oetiker]

We are looking at purchasing a new box. According to
https://github.com/joyent/manufacturing/blob/master/parts-database.ods
it seems that Joyent is using

Supermicro SuperStorage Server 6047R-E1R36L with 7K3000 (and maybe
soon 7K4000) disks.
http://www.supermicro.com/products/system/4u/6047/ssg-6047r-e1r36l.cfm

We asked our system integrator for an offer on these boxes and he
said, that he has several in the field and they wer cool, BUT he
has seen problems with the on-board LSI 2308 and the backplane, and
that he would recommend installing 5 extra LSI SAS controllers to
directly connect each sas disk to a controller port ...

Is this the reason that joyent lists all the firmware versions and
one should make sure to use exactly these versions ?

Any ideas ?

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SuperStorage Server 6047R-E1R36L SAS Question

[Tobias Oetiker]

Hi Saso,

Today Saso Kiselkov wrote:

 On 11/11/13, 2:05 PM, Tobias Oetiker wrote:
  We are looking at purchasing a new box. According to
  https://github.com/joyent/manufacturing/blob/master/parts-database.ods
  it seems that Joyent is using
 
  Supermicro SuperStorage Server 6047R-E1R36L with 7K3000 (and maybe
  soon 7K4000) disks.
  http://www.supermicro.com/products/system/4u/6047/ssg-6047r-e1r36l.cfm
 
  We asked our system integrator for an offer on these boxes and he
  said, that he has several in the field and they wer cool, BUT he
  has seen problems with the on-board LSI 2308 and the backplane, and
  that he would recommend installing 5 extra LSI SAS controllers to
  directly connect each sas disk to a controller port ...
 
  Is this the reason that joyent lists all the firmware versions and
  one should make sure to use exactly these versions ?
 
  Any ideas ?

 I may be completely off, but I see no reason why using LSI SAS chips
 installed on stand-alone extension cards is better than using the LSI
 SAS chip installed on the motherboard. I smell an attempt at upsell...

this system has a sas expander on the backplane, so that all 36
disks can be controlled from the single on-board LSI 2308

our integrater maintains that he has seen issues with the
LSI SAS2X28 expander on the backplane of the 6047R-E1R36L.

I did find some messages from 2012 that there were issues but
nothing recent.

cheers
tobi

 Cheers


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [smartos-discuss] SuperStorage Server 6047R-E1R36L SAS Question

[Tobias Oetiker]

Hi Keith,

Today Keith Wesolowski wrote:

 On Mon, Nov 11, 2013 at 03:05:00PM +0100, Tobias Oetiker wrote:

  We are looking at purchasing a new box. According to
  https://github.com/joyent/manufacturing/blob/master/parts-database.ods
  it seems that Joyent is using
 
  Supermicro SuperStorage Server 6047R-E1R36L with 7K3000 (and maybe
  soon 7K4000) disks.
  http://www.supermicro.com/products/system/4u/6047/ssg-6047r-e1r36l.cfm
 
  We asked our system integrator for an offer on these boxes and he
  said, that he has several in the field and they wer cool, BUT he
  has seen problems with the on-board LSI 2308 and the backplane, and
  that he would recommend installing 5 extra LSI SAS controllers to
  directly connect each sas disk to a controller port ...

 That's not how this system works.  The backplanes have SAS expanders and
 as far as I know there is no way to get an alternate backplane.

they would build the system based on
http://www.supermicro.com/products/chassis/4U/847/SC847A-R1400LP.cfm
then. With the X9DRD-7LN4F-JBOD motherboard and some extra LSI
controller cards.

 The only reason to want to bypass the expanders is if you are using SATA
 devices.  We don't use them in this system, and do not recommend them.

we use one sata ssd for l2arc and two for zil ... you seem to get around
the zil part by using zeus (expensive, is it worth it?). and no
l2arc (reason?).

 We've had no expander-related issues in our SAS systems.  The only
 systems we use SATA devices in are the ones with expanderless 16-bay
 backplanes (Richmond-A/Richmond-C).

 Anything more useful will require actual data as to what problems have
 supposedly occurred and under what circumstances.  A crash dump, if a
 panic occurred, is essential.  Error messages, anything at all.
 Otherwise this feels a lot like an attempt to sell you 4 extra HBAs and
 a giant unmanageable wad of internal cables.

:) there is no data, and I hope there never will be :-)

  Is this the reason that joyent lists all the firmware versions and
  one should make sure to use exactly these versions ?

 Yes.  Never deviate from known-to-work firmware revisions unless you
 encounter a bug that is specific to this version and *known* to be fixed
 in a different one.

:-)

thanks!
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] hw recomendation for JBOD box

[Tobias Oetiker]

We are looking at buying a system consisting of a 1U server and 1
or more 3U JBOD boxes to run and OmniOS ZFS server. Any HW
recommendations for the JBOD box, Controller, Disks, what are you
using ?

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] hw recomendation for JBOD box

[Tobias Oetiker]

Yesterday Michael Rasmussen wrote:

 On Wed, 30 Oct 2013 23:05:11 +0100 (CET)
 Tobias Oetiker t...@oetiker.ch wrote:

 
  http://www.supermicro.com/products/system/4u/6047/ssg-6047r-e1r36l.cfm
 
  filled with UltraStar 7k3000 and a ZeusRam 8GB as Zil
 
  and 256 GB ram

 Nice rick;-)

 
  nice :-) no jbod though as far as I can see ... so maybe jbod is
  not such a good idea ...
 
 Point 6:  Onboard LSI 2308 IT mode. For LSI HBA IT mode means jbod
 mode. And no, the only good thing for ZFS is jbod mode! The non-IT mode
 HBA's where you create a RAID0 for each disk is simply horrible.

sure, jbod mode, I meant having an external jbod box attached

cheers
tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] omnios host goes suddenly silent on the network

[Tobias Oetiker]

Folks,

I am runnning omnios OmniOS 5.11 omnios-8d266aa  2013.05.04 on
a box where we server zfs storage space and also run a few kvm
hosts.

Over the last few days, omnios has intermittently become 'mute' on
its network interface. Not answering to tcp or icmp requests.

Connecting via the console shows that the host is otherwhise fine,
it just can not talk over the network anymore.

Normally the condition cleared after a few minutes.

The kernel does not write anything into the log file (running with
*.debug /var/log/debug.log)

Whats more, the virtual machines running on the machine, talking
over the same physical network interface continue their work
unperturbed. With network connectivity and all ... but they also
can not talk to the omnios server via the network.

I have the following network setup

oot@fugu:~# dladm show-link
LINKCLASS MTUSTATEBRIDGE OVER
igb0phys  1500   up   -- --
igb1phys  1500   up   -- --
igb2phys  1500   unknown  -- --
igb3phys  1500   unknown  -- --
akami0  vnic  1500   up   -- igb0
nigiri0 vnic  1500   up   -- igb0
fugu0   vnic  1500   up   -- igb0
fugu1   vnic  1500   up   -- igb1

the interfaces akami0 and nigiri0 are assigned to two kvm hosts
fugu0 is used by the omnios host and fugu1 is a direct link to a
second omnios host for zfs send receive backups.

anyone seem such a behaviour ?
any debugging ideas ?

cheers
tobi
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] omnios host goes suddenly silent on the network

[Tobias Oetiker]

Today Eric Sproul wrote:

 On Tue, Oct 29, 2013 at 6:21 AM, Tobias Oetiker t...@oetiker.ch wrote:
  oot@fugu:~# dladm show-link
  LINKCLASS MTUSTATEBRIDGE OVER
  igb0phys  1500   up   -- --
  igb1phys  1500   up   -- --
  igb2phys  1500   unknown  -- --
  igb3phys  1500   unknown  -- --
  akami0  vnic  1500   up   -- igb0
  nigiri0 vnic  1500   up   -- igb0
  fugu0   vnic  1500   up   -- igb0
  fugu1   vnic  1500   up   -- igb1
 
  the interfaces akami0 and nigiri0 are assigned to two kvm hosts
  fugu0 is used by the omnios host and fugu1 is a direct link to a
  second omnios host for zfs send receive backups.

 Could we see the output of `ipadm show-addr` in the global zone?  If
 not, are fugu0 and fugu1 in the same subnet?  Does the drop-out
 coincide with any other usage patterns, such as an active backup over
 fugu1?

ADDROBJ   TYPE STATEADDR
lo0/v4static   ok   127.0.0.1/8
fugu0/v4staticstatic   ok   zzz.yy.8.5/23
fugu1/v4staticstatic   ok   10.10.10.1/30
lo0/v6static   ok   ::1/128

the dropout does not coincide with a big backup job ... I am
running collectd on the omnios host, and it has been faithfully
recoding what happend on the interface while it was offline.

The trafic stats show that packets have been coming into fugu0 but
only very few got sent out ... (if it happens again I will do a
snoop in the interface)

 For good measure, let's also look at `prtconf -d` to see what this igb
 hardware is.

pci8086,1d10 (pciex8086,1d10) [Intel Corporation C600/X79 series 
chipset PCI Express Root Port 1], instance #6
pci8086,3584 (pciex8086,1521) [Intel Corporation I350 Gigabit 
Network Connection], instance #0
pci8086,3584 (pciex8086,1521) [Intel Corporation I350 Gigabit 
Network Connection], instance #1
pci8086,3584 (pciex8086,1521) [Intel Corporation I350 Gigabit 
Network Connection], instance #2
pci8086,3584 (pciex8086,1521) [Intel Corporation I350 Gigabit 
Network Connection], instance #3

note that the kvm hosts were able to talk via igb0 while fugu (zone0) was not.

cheers
tobi


 Eric



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] omnios host goes suddenly silent on the network

[Tobias Oetiker]

Today Eric Sproul wrote:

 On Tue, Oct 29, 2013 at 3:10 PM, Tobias Oetiker t...@oetiker.ch wrote:
  the troubling bit is that during the outage, the kvm hosts on
  akami0 and nigiri0 were able to talk to the physical network just
  fine, but they were not able to talk to fugu0 ...  and this is all
  happening inside the crossbow switch within illumos if I
  understand the concept correctly ...

 I'm not an expert on the Crossbow stack, but essentially I think this
 is correct, so perhaps we're looking at a VNIC issue with fugu0 and
 not anything to do with hardware.

 Since you're not using aggregate links, it should be possible to let
 the global zone use igb0 directly without disturbing the KVM vnics.  I
 do this on a number of dev systems.  It might be worth a try to move
 the address fugu0/v4static to igb0/v4static, though you'll of course
 need out-of-band or console access to do that.

this how we had it setup originally :-) we thought that it might be
better to hook zone0 into the virtual switch ... for performance
since the kvms are using nfs resources from zone0 ...

but you are right, it might make sense to switch back ...

cheers
tobi


 Eric



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] nfs problems linux (client) illumos (server)

[Tobias Oetiker]

Folks,

I have this nfs client (ubunty 3.5 kernel) which seems to have
issues talking to our omnios server.  In the example below the
client does not seem to get an answer to his ACCESS3 call from
08:19:48.43 and starts retransmitting.  It does not seem as if
packets got lost ...  Does this pattern ring a bell?

(as seen from the omnios server)

8:19:42.11355   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=1F8F 
(read,lookup,modify,extend,delete)
8:19:42.11358   10.10.10.1 - 10.10.10.2   NFS R ACCESS3 OK 
(read,lookup,modify,extend,delete)
8:19:42.11372   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=8B8A 
(read,lookup,modify,extend,delete)
8:19:42.11387   10.10.10.1 - 10.10.10.2   NFS R ACCESS3 OK 
(read,lookup,modify,extend,delete)
8:19:42.15340   10.10.10.2 - 10.10.10.1   TCP D=2049 S=822 Ack=3569055649 
Seq=330388801 Len=0 Win=20638 Options=nop,nop,tstamp 3449855200 396193080
8:19:42.65429   10.10.10.2 - 10.10.10.1   NFS C GETATTR3 FH=1391
8:19:42.65493   10.10.10.1 - 10.10.10.2   NFS R GETATTR3 OK
8:19:42.65507   10.10.10.2 - 10.10.10.1   TCP D=2049 S=822 Ack=3569055765 
Seq=330388917 Len=0 Win=20638 Options=nop,nop,tstamp 3449855325 396193134
8:19:48.43236   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=8B45 
(read,lookup,modify,extend,delete)
8:19:48.49820   10.10.10.1 - 10.10.10.2   TCP D=822 S=2049 Ack=330389029 
Seq=3569055765 Len=0 Win=32806 Options=nop,nop,tstamp 396193719 3449856769
8:19:49.12947   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=8B45 
(read,lookup,modify,extend,delete) (retransmit)
8:19:49.19819   10.10.10.1 - 10.10.10.2   TCP D=822 S=2049 Ack=330389141 
Seq=3569055765 Len=0 Win=32806 Options=nop,nop,tstamp 396193789 3449856944
8:19:50.53345   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=8B45 
(read,lookup,modify,extend,delete) (retransmit)
8:19:50.59817   10.10.10.1 - 10.10.10.2   TCP D=822 S=2049 Ack=330389253 
Seq=3569055765 Len=0 Win=32806 Options=nop,nop,tstamp 396193929 3449857295
8:19:52.64147   10.10.10.2 - 10.10.10.1   NFS C ACCESS3 FH=8B45 
(read,lookup,modify,extend,delete) (retransmit)
8:19:52.70810   10.10.10.1 - 10.10.10.2   TCP D=822 S=2049 Ack=330389365 
Seq=3569055765 Len=0 Win=32806 Options=nop,nop,tstamp 396194140 3449857822
8:19:53.50200   10.10.10.2 - 10.10.10.1   NFS C GETATTR3 FH=08CA
8:19:53.56808   10.10.10.1 - 10.10.10.2   TCP D=822 S=2049 Ack=330389477 
Seq=3569055765 Len=0 Win=32806 Options=nop,nop,tstamp 396194226 3449858037

(as seeen from the ubuntu linux 3.5 client)

08:19:42.113444   10.10.10.2 - 10.10.10.1   NFS 186 V3 ACCESS Call, 
FH:0xbff47443, [Check: RD LU MD XT DL]
08:19:42.113512   10.10.10.1 - 10.10.10.2   NFS 190 V3 ACCESS Reply (Call In 
86), [Allowed: RD LU MD XT DL]
08:19:42.113620   10.10.10.2 - 10.10.10.1   NFS 186 V3 ACCESS Call, 
FH:0x312c9eb9, [Check: RD LU MD XT DL]
08:19:42.113804   10.10.10.1 - 10.10.10.2   NFS 190 V3 ACCESS Reply (Call In 
88), [Allowed: RD LU MD XT DL]
08:19:42.153301   10.10.10.2 - 10.10.10.1   TCP 66 822  nfs [ACK] Seq=7121 
Ack=4485 Win=20638 Len=0 TSval=3449855200 TSecr=396193080
08:19:42.654182   10.10.10.2 - 10.10.10.1   NFS 182 V3 GETATTR Call, 
FH:0x7b7d2a4e
08:19:42.654932   10.10.10.1 - 10.10.10.2   NFS 182 V3 GETATTR Reply (Call In 
91)  Regular File mode:0644 uid:0 gid:0
08:19:42.654979   10.10.10.2 - 10.10.10.1   TCP 66 822  nfs [ACK] Seq=7237 
Ack=4601 Win=20638 Len=0 TSval=3449855325 TSecr=396193134
08:19:48.432250   10.10.10.2 - 10.10.10.1   NFS 178 V3 ACCESS Call, 
FH:0x505b4bee, [Check: RD LU MD XT DL]
08:19:48.498217   10.10.10.1 - 10.10.10.2   TCP 66 nfs  822 [ACK] Seq=4601 
Ack=7349 Win=32806 Len=0 TSval=396193719 TSecr=3449856769
08:19:49.129364   10.10.10.2 - 10.10.10.1   NFS 178 [RPC retransmission of 
#94]V3 ACCESS Call, FH:0x505b4bee, [Check: RD LU MD XT DL]
08:19:49.198215   10.10.10.1 - 10.10.10.2   TCP 66 nfs  822 [ACK] Seq=4601 
Ack=7461 Win=32806 Len=0 TSval=396193789 TSecr=3449856944
08:19:50.56   10.10.10.2 - 10.10.10.1   NFS 178 [RPC retransmission of 
#94]V3 ACCESS Call, FH:0x505b4bee, [Check: RD LU MD XT DL]
08:19:50.598191   10.10.10.1 - 10.10.10.2   TCP 66 nfs  822 [ACK] Seq=4601 
Ack=7573 Win=32806 Len=0 TSval=396193929 TSecr=3449857295
08:19:52.641348   10.10.10.2 - 10.10.10.1   NFS 178 [RPC retransmission of 
#94]V3 ACCESS Call, FH:0x505b4bee, [Check: RD LU MD XT DL]
08:19:52.708091   10.10.10.1 - 10.10.10.2   TCP 66 nfs  822 [ACK] Seq=4601 
Ack=7685 Win=32806 Len=0 TSval=396194140 TSecr=3449857822
08:19:53.501892   10.10.10.2 - 10.10.10.1   NFS 178 V3 GETATTR Call, 
FH:0x8a584406
08:19:53.568104   10.10.10.1 - 10.10.10.2   TCP 66 nfs  822 [ACK] Seq=4601 
Ack=7797 Win=32806 Len=0 TSval=396194226 TSecr=3449858037

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] file system organisation for pkg packages

[Tobias Oetiker]

Hi Eric,

Today Eric Sproul wrote:

 On Wed, Sep 25, 2013 at 7:29 AM, Tobias Oetiker t...@oetiker.ch wrote:
  Folks,
 
  I have started to create packages for omnios and I am a bit at a
  loss as to packaging 'standards' ...
 
  With omnios getting more popular, I think it would be a good move
  to have some standards as to where things should go on the system
  ...
 
  good old
 
  /opt/X
  /etc/opt/X
  /var/opt/X
 
  come to mind

 I have tended to prefer the SysV style of /opt/app or /opt/vendor
 so that the entire application set is under a single top-level
 directory.  This makes it simple to avoid conflicting with apps from
 other sources, which dovetails with the OmniOS
 keep-your-stuff-to-yourself philosophy.

from a system management point of view I like to have a simple rule
to decide where the config is and where the 'data' is ...

so keeping the application in /opt/vendor is perfect for the static
part of the application ...

but having the configuration and the data in the same tree makes it
harder to know what is part of the distribution and what is part of
the application ...

I can obviously use symlinks to fix things, but it would be great
if there were some admin friendly suggestions ...

cheers
tobi
-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss