From johan.kragsterman at capvert.se Thu Apr 2 14:18:01 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Thu, 2 Apr 2015 16:18:01 +0200 Subject: [OmniOS-discuss] pkg update Message-ID: Hi! I'm a bit confused here... I ran an update, I was on 151010, and wanted to get 151012 before 151014 was released, but it seems I'm still on 151010... The update went fine, a new BE was created and made active, but.... root at san1:~# cat /etc/release OmniOS v11 r151010 Copyright 2014 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. root at san1:~# root at san1:~# uname -srvmpi SunOS 5.11 omnios-8c08411 i86pc i386 i86pc root at san1:~# root at san1:~# beadm list BE Active Mountpoint Space Policy Created omnios - - 270M static 2014-06-23 11:41 omnios-1 NR / 2,80G static 2015-04-02 12:29 omniosvar - - 31,0K static 2014-06-23 11:41 root at san1:~# Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert From jdg117 at elvis.arl.psu.edu Thu Apr 2 14:23:33 2015 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Thu, 02 Apr 2015 10:23:33 -0400 Subject: [OmniOS-discuss] pkg update In-Reply-To: Your message of "Thu, 02 Apr 2015 16:18:01 +0200." References: Message-ID: <201504021423.t32ENXje022397@elvis.arl.psu.edu> In message , Johan Kragsterman writes: >I ran an update, I was on 151010, and wanted to get 151012 before 151014 was r >eleased, but it seems I'm still on 151010... # pkg publisher My WAG is you want to set yours to 151012. John groenveld at acm.org From danmcd at omniti.com Thu Apr 2 14:31:42 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 2 Apr 2015 10:31:42 -0400 Subject: [OmniOS-discuss] pkg update In-Reply-To: References: Message-ID: <278352A0-25CC-46B3-9B4F-CE13F7FB8214@omniti.com> > On Apr 2, 2015, at 10:18 AM, Johan Kragsterman wrote: > > > Hi! > > > I'm a bit confused here... > > I ran an update, I was on 151010, and wanted to get 151012 before 151014 was released, but it seems I'm still on 151010... > > The update went fine, a new BE was created and made active, but.... > > > root at san1:~# cat /etc/release > OmniOS v11 r151010 > Copyright 2014 OmniTI Computer Consulting, Inc. All rights reserved. > Use is subject to license terms. > root at san1:~# Each release has its own repo server. You need to update the omnios publisher as such. I can tell you that an upgrade from 010 to 014 is possible and supported ==> tested it myself. Make sure your non-omnios-publisher packages (e.g. ms.omniti.com) aren't overly restrictive, however. Dan From johan.kragsterman at capvert.se Thu Apr 2 15:34:52 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Thu, 2 Apr 2015 17:34:52 +0200 Subject: [OmniOS-discuss] Ang: Re: pkg update In-Reply-To: <278352A0-25CC-46B3-9B4F-CE13F7FB8214@omniti.com> References: <278352A0-25CC-46B3-9B4F-CE13F7FB8214@omniti.com>, Message-ID: Hi! -----Dan McDonald skrev: ----- Till: Johan Kragsterman Fr?n: Dan McDonald Datum: 2015-04-02 16:31 Kopia: omnios-discuss at lists.omniti.com ?rende: Re: [OmniOS-discuss] pkg update > On Apr 2, 2015, at 10:18 AM, Johan Kragsterman wrote: > > > Hi! > > > I'm a bit confused here... > > I ran an update, I was on 151010, and wanted to get 151012 before 151014 was released, but it seems I'm still on 151010... > > The update went fine, a new BE was created and made active, but.... > > > root at san1:~# cat /etc/release > ?OmniOS v11 r151010 > ?Copyright 2014 OmniTI Computer Consulting, Inc. All rights reserved. > ?Use is subject to license terms. > root at san1:~# Each release has its own repo server. ?You need to update the omnios publisher as such. Yeah, now I remember this discussion and the change to separate publisher url's for each release. Never used it before, sorry for the noice.... Regards Johan I can tell you that an upgrade from 010 to 014 is possible and supported ==> tested it myself. ?Make sure your non-omnios-publisher packages (e.g. ms.omniti.com) aren't overly restrictive, however. Dan From nsmith at careyweb.com Thu Apr 2 16:43:10 2015 From: nsmith at careyweb.com (Nate Smith) Date: Thu, 2 Apr 2015 12:43:10 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Message-ID: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> So going over the forum over the last month, it appears more than a couple people have had problem with Omnios as a storage backend for virtualization platforms, both as iSCSI targets and as Fibre Channel targets. Looking at a list of possible alternatives, what infrastructure works well? Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? -Nate From danmcd at omniti.com Thu Apr 2 16:58:38 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 2 Apr 2015 12:58:38 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> Message-ID: <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> > On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: > > Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. It's "simply" a matter of upstreaming it. Dan From chip at innovates.com Thu Apr 2 17:35:01 2015 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 2 Apr 2015 12:35:01 -0500 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> Message-ID: On Apr 2, 2015 11:50 AM, "Nate Smith" wrote: > > So going over the forum over the last month, it appears more than a couple people have had problem with Omnios as a storage backend for virtualization platforms, both as iSCSI targets and as Fibre Channel targets. Looking at a list of possible alternatives, what infrastructure works well? > > Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? > I run OmniOS with NFS for vSphere. It works very good. One bit of disclosure all my VM storage is SSD, however ZFS with compression makes SSD goes a lot further. I also use linked clones using the vsphere api. I have 250 VMS running on 5 TB of SSD. Performance is awesome for every VM. -Chip > -Nate > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 17:33:46 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 17:33:46 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> Message-ID: An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Thu Apr 2 18:07:11 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Thu, 2 Apr 2015 20:07:11 +0200 Subject: [OmniOS-discuss] Ang: Re: Best infrastructure for VSphere/Hyper-V In-Reply-To: References: , <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> Message-ID: Hi, Thomas! -----"OmniOS-discuss" skrev: ----- Till: Dan McDonald Fr?n: "T. Wiese, OVIS IT Consulting GmbH" S?nt av: "OmniOS-discuss" Datum: 2015-04-02 19:43 Kopia: "omnios-discuss at lists.omniti.com" ?rende: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Hi, we had very good experience with omnios and fibrechannel.? We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based.? But after we changed all back to FibreChannel ist works great.? We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer.? No Probs thins were changed back to FC! So i can say, use HCL listed Cards for VMWare! I guess you're talking about the VmWare hosts Fc adapters, huh? Not the storage servers Fc adapters? Because I've tried many times with emulex adapters on my storage appliancies, and always having problems. I never have had problems with qlogic adapters on the storage appliancies. Regards Johan Bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? ?Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. ?It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From thomas.wiese at ovis-consulting.de Thu Apr 2 18:17:55 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 18:17:55 +0000 Subject: [OmniOS-discuss] Ang: Re: Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <,> <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> Message-ID: <219ECD3F-F65C-4FA2-A8D5-46D5C341DFD6@ovis-consulting.de> An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 18:25:19 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 18:25:19 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> Message-ID: <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 18:42:10 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 18:42:10 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> Message-ID: An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 18:44:53 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 18:44:53 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> Message-ID: <8F91F511-D22E-4AD9-B0B9-ED2B3B4F4B0C@ovis-consulting.de> An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Thu Apr 2 18:50:01 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Thu, 2 Apr 2015 20:50:01 +0200 Subject: [OmniOS-discuss] Ang: Re: Best infrastructure for VSphere/Hyper-V In-Reply-To: <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> References: <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de>, <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> Message-ID: Nate, please, don't forget to include the list, we are many people here interested in this discussion! Johan -----"OmniOS-discuss" skrev: ----- Till: Nate Smith Fr?n: "T. Wiese, OVIS IT Consulting GmbH" S?nt av: "OmniOS-discuss" Datum: 2015-04-02 20:30 Kopia: "omnios-discuss at lists.omniti.com" ?rende: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Which server system do you use for storage? HP, DELL, Supermicro? Turn off sr-iov thats make many problems and try to turn off auto detection f?r pci-express speed. And don’t use any PCI-Express slots for graphic cards! Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:16 schrieb Nate Smith : Hmmm. Was hoping for an 8GB variant (I’m on QL2562), might have to go down to this to see how well it works. ? Thanks, ? -Nate ? From:?T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de]? Sent:?Thursday, April 02, 2015 2:15 PM To:?Nate Smith Subject:?Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V ? Of course…? We use?Emulex LPe11002 Dual Port 4Gb PCIe Fibre With latest firmware. Works great!!! All VMServer use RoundRoubin as pathselection. For FC Switch we use 2 x Brocade 5000.? Low cost, good speed an stable ^^ ? bye Thomas ? Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 19:35 schrieb Nate Smith : ? Can I ask what model cards, Thomas? ? From:?T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de]? Sent:?Thursday, April 02, 2015 1:34 PM To:?Dan McDonald Cc:?Nate Smith;?omnios-discuss at lists.omniti.com Subject:?Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V ? Hi, we had very good experience with omnios and fibrechannel.? We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based.? But after we changed all back to FibreChannel ist works great.? We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 ? We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer.? No Probs thins were changed back to FC! ? So i can say, use HCL listed Cards for VMWare! ? Bye Thomas ? ? ? Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : ? On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? ?Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. ?It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From nsmith at careyweb.com Thu Apr 2 18:58:46 2015 From: nsmith at careyweb.com (Nate Smith) Date: Thu, 2 Apr 2015 14:58:46 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> Message-ID: You mentioned Queue depth. I will have to check into recommended settings for HyperV... My Storage Pool is about 32TB raw (10TB used), and I have 6 luns. I also have a 6TB pool that is 2 luns feeding my 3 system hyper-v cluster. Situations that trigger dopout behavior include: snapshot initiation on the hypervisor, checkpoint deletion (with accompanying vhdx merge). I?m using Dell R720s with QLE2562 cards. I?ve also had this problem on an IBM server SR2625ULXLR which was an intel 5520 chipset. We discussed this a bit back, but both these systems have risers, and we surmised it could be a riser issue, but I don?t know if I buy it. So FC Switch is a dual (full mesh) HP8-20Q which is a Qlogic OEM. How do I turn of sr-iov and pci-express speed? Is this a Bios or Omnios setting? I posted errors a couple times. (you responded these could be bios) I get weird "Drop outs" in certain IO situations. I get no notice of the drop out, just a notice when it comes back up. Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt0,0 LINK UP, portid 20000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:25 storm3 last message repeated 1 time Apr 2 09:31:54 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt1,0 LINK UP, portid 10000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt3,0 LINK UP, portid 10100, topology Fabric Pt-to-Pt,speed 8G From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:25 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Which server system do you use for storage? HP, DELL, Supermicro? Turn off sr-iov thats make many problems and try to turn off auto detection f?r pci-express speed. And don?t use any PCI-Express slots for graphic cards! Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:16 schrieb Nate Smith : Hmmm. Was hoping for an 8GB variant (I?m on QL2562), might have to go down to this to see how well it works. Thanks, -Nate From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:15 PM To: Nate Smith Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Of course... We use Emulex LPe11002 Dual Port 4Gb PCIe Fibre With latest firmware. Works great!!! All VMServer use RoundRoubin as pathselection. For FC Switch we use 2 x Brocade 5000. Low cost, good speed an stable ^^ bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 19:35 schrieb Nate Smith : Can I ask what model cards, Thomas? From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 1:34 PM To: Dan McDonald Cc: Nate Smith; omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Hi, we had very good experience with omnios and fibrechannel. We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based. But after we changed all back to FibreChannel ist works great. We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer. No Probs thins were changed back to FC! So i can say, use HCL listed Cards for VMWare! Bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 19:14:23 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 19:14:23 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> Message-ID: <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> An HTML attachment was scrubbed... URL: From nsmith at careyweb.com Thu Apr 2 19:24:59 2015 From: nsmith at careyweb.com (Nate Smith) Date: Thu, 2 Apr 2015 15:24:59 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> Message-ID: <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> I?m running maybe 7 active VMs on two servers across two different luns/pools (basically have a "Fast" storage Pool and a "Slower" storage Pool). From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 3:14 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V I remember that i had also a problem on IBM Server... See http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030265 That helps me... How many VMs did you had on every lun? Big lungs make sometimes trouble on vmware. Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:58 schrieb Nate Smith : You mentioned Queue depth. I will have to check into recommended settings for HyperV... My Storage Pool is about 32TB raw (10TB used), and I have 6 luns. I also have a 6TB pool that is 2 luns feeding my 3 system hyper-v cluster. Situations that trigger dopout behavior include: snapshot initiation on the hypervisor, checkpoint deletion (with accompanying vhdx merge). I?m using Dell R720s with QLE2562 cards. I?ve also had this problem on an IBM server SR2625ULXLR which was an intel 5520 chipset. We discussed this a bit back, but both these systems have risers, and we surmised it could be a riser issue, but I don?t know if I buy it. So FC Switch is a dual (full mesh) HP8-20Q which is a Qlogic OEM. How do I turn of sr-iov and pci-express speed? Is this a Bios or Omnios setting? I posted errors a couple times. (you responded these could be bios) I get weird "Drop outs" in certain IO situations. I get no notice of the drop out, just a notice when it comes back up. Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt0,0 LINK UP, portid 20000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:25 storm3 last message repeated 1 time Apr 2 09:31:54 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt1,0 LINK UP, portid 10000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt3,0 LINK UP, portid 10100, topology Fabric Pt-to-Pt,speed 8G From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:25 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Which server system do you use for storage? HP, DELL, Supermicro? Turn off sr-iov thats make many problems and try to turn off auto detection f?r pci-express speed. And don?t use any PCI-Express slots for graphic cards! Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:16 schrieb Nate Smith : Hmmm. Was hoping for an 8GB variant (I?m on QL2562), might have to go down to this to see how well it works. Thanks, -Nate From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:15 PM To: Nate Smith Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Of course... We use Emulex LPe11002 Dual Port 4Gb PCIe Fibre With latest firmware. Works great!!! All VMServer use RoundRoubin as pathselection. For FC Switch we use 2 x Brocade 5000. Low cost, good speed an stable ^^ bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 19:35 schrieb Nate Smith : Can I ask what model cards, Thomas? From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 1:34 PM To: Dan McDonald Cc: Nate Smith; omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Hi, we had very good experience with omnios and fibrechannel. We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based. But after we changed all back to FibreChannel ist works great. We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer. No Probs thins were changed back to FC! So i can say, use HCL listed Cards for VMWare! Bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.wiese at ovis-consulting.de Thu Apr 2 19:43:50 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Thu, 2 Apr 2015 19:43:50 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> Message-ID: An HTML attachment was scrubbed... URL: From nsmith at careyweb.com Thu Apr 2 19:58:19 2015 From: nsmith at careyweb.com (Nate Smith) Date: Thu, 2 Apr 2015 15:58:19 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> Message-ID: <872a609f-4d1b-4d2d-9b83-ccd2c85a0ef0@careyweb.com> "In which situations?" When the hypervisor tries to perform a VSS snapshot for backup purposes. When I delete a Checkpoint (Hyper-V?s new term for a snapshot) on the VM (which initiates a merge on the VHDX) On VMware or HyperV? Always HyperV "Can you see any timeouts in an VM log?" Yeah. Everything drops out. MPIO errors, missing disks, etc. "How many Disks in your pool?" 22 "Which Raidz?" Striped 11 disk Raidz2 "Raidcontroller?" LSI 9285CV-8e (Disks in JBOD) And LSI 9308-8i Do you use zoning in your Fabric? Yes. With Views and at the Switch. I do not separate my Hyper-V traffic from my non-HyperV traffic on the OmniOS side target side (I just round robin them on every FC initiator). I run with dual QLE2548s. I am going to separate them and possibly run the storage off separate systems to my HyperV storage and my NonHyperV Storage (that just feeds a windows file server). I figured out the SR/IOV stuff, but what were you talking about when you mentioned turning of PCI Express Speed in bios? From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 3:44 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V You wrote "I get weird "Drop outs" in certain IO situations." In which situations? On VMware or HyperV? Can you see any timeouts in an VM log? How many Disks in your pool? Wich Raidz? Raidcontroller? Do you use zoning in your Fabric? Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 21:24 schrieb Nate Smith : I?m running maybe 7 active VMs on two servers across two different luns/pools (basically have a "Fast" storage Pool and a "Slower" storage Pool). From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 3:14 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V I remember that i had also a problem on IBM Server... See http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030265 That helps me... How many VMs did you had on every lun? Big lungs make sometimes trouble on vmware. Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:58 schrieb Nate Smith : You mentioned Queue depth. I will have to check into recommended settings for HyperV... My Storage Pool is about 32TB raw (10TB used), and I have 6 luns. I also have a 6TB pool that is 2 luns feeding my 3 system hyper-v cluster. Situations that trigger dopout behavior include: snapshot initiation on the hypervisor, checkpoint deletion (with accompanying vhdx merge). I?m using Dell R720s with QLE2562 cards. I?ve also had this problem on an IBM server SR2625ULXLR which was an intel 5520 chipset. We discussed this a bit back, but both these systems have risers, and we surmised it could be a riser issue, but I don?t know if I buy it. So FC Switch is a dual (full mesh) HP8-20Q which is a Qlogic OEM. How do I turn of sr-iov and pci-express speed? Is this a Bios or Omnios setting? I posted errors a couple times. (you responded these could be bios) I get weird "Drop outs" in certain IO situations. I get no notice of the drop out, just a notice when it comes back up. Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt0,0 LINK UP, portid 20000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:25 storm3 last message repeated 1 time Apr 2 09:31:54 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt1,0 LINK UP, portid 10000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt3,0 LINK UP, portid 10100, topology Fabric Pt-to-Pt,speed 8G From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:25 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Which server system do you use for storage? HP, DELL, Supermicro? Turn off sr-iov thats make many problems and try to turn off auto detection f?r pci-express speed. And don?t use any PCI-Express slots for graphic cards! Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:16 schrieb Nate Smith : Hmmm. Was hoping for an 8GB variant (I?m on QL2562), might have to go down to this to see how well it works. Thanks, -Nate From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:15 PM To: Nate Smith Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Of course... We use Emulex LPe11002 Dual Port 4Gb PCIe Fibre With latest firmware. Works great!!! All VMServer use RoundRoubin as pathselection. For FC Switch we use 2 x Brocade 5000. Low cost, good speed an stable ^^ bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 19:35 schrieb Nate Smith : Can I ask what model cards, Thomas? From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 1:34 PM To: Dan McDonald Cc: Nate Smith; omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Hi, we had very good experience with omnios and fibrechannel. We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based. But after we changed all back to FibreChannel ist works great. We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer. No Probs thins were changed back to FC! So i can say, use HCL listed Cards for VMWare! Bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Apr 3 01:58:26 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 2 Apr 2015 21:58:26 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! Message-ID: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> Say hello to OmniOS r151014: http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 I won't go over all of the release notes here, but I will say to FOLLOW THE UPGRADE INSTRUCTIONS CAREFULLY. People who upgrade must make sure they don't run into the too-many-BEs problem (more than 40, worry about it), AND make sure they update the signature policy when they reset the "omnios" publisher. OmniOS r151014 is not only the next Stable release, it is also the next Long-Term Support release. Because '014 is the next LTS, during at least its first six months, it MAY receive more than usual amounts of updates (i.e. not just security patches) in order to insure its longer-term stability (additional devices, for example). Soon the r151015 bloody cycle will begin, in preparation for this fall's r151016 (next Stable) release. Thank you to the OmniOS community for your feedback, and support! Dan McDonald -- OmniOS Engineering From danmcd at omniti.com Fri Apr 3 02:02:33 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 2 Apr 2015 22:02:33 -0400 Subject: [OmniOS-discuss] END OF SUPPORT LIFE FOR OmniOS r151010 Message-ID: <9D6904FF-A4E1-4C29-B9AC-92761ADB5F6C@omniti.com> OmniOS r151010 will no longer be receiving updates of any kind. You can and should migrate any r151010 machines over to r151014 as soon as possible. This is in accordance with the OmniOS lifecycle, published here: http://omnios.omniti.com/wiki.php/ReleaseCycle. Questions about r151010 will be answered with, "Please upgrade to r151014." We officially support r151010 to r151014 upgrades, and can assist if you have any difficulties. Please read the r151014 upgrade instructions: http://omnios.omniti.com/wiki.php/Upgrade_to_r151014 prior to upgrading. Thank you, Dan McDonald - OmniOS Engineering p.s. beadm(1M) is your friend (modulo having too many BEs thanks to grub). Creating backup BEs in case of mistakes is easy. ZFS means they don't take up a lot of space and happen quickly. From danmcd at omniti.com Fri Apr 3 02:04:21 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 2 Apr 2015 22:04:21 -0400 Subject: [OmniOS-discuss] And finally -- Happy 3rd Anniversary OmniOS! Message-ID: <9FA18CCC-5E5A-435B-8429-A6BCF2E3CD6F@omniti.com> Three years ago OmniOS r151002 was released to the world. It's been a while, and I've only been here for not quite half it's lifetime, I'm looking forward to many more years of OmniOS. Thanks! Dan From gate03 at landcroft.co.uk Fri Apr 3 06:22:41 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Fri, 3 Apr 2015 16:22:41 +1000 Subject: [OmniOS-discuss] And finally -- Happy 3rd Anniversary OmniOS! In-Reply-To: <9FA18CCC-5E5A-435B-8429-A6BCF2E3CD6F@omniti.com> References: <9FA18CCC-5E5A-435B-8429-A6BCF2E3CD6F@omniti.com> Message-ID: <20150403162241.33187c8a@emeritus> On Thu, 2 Apr 2015 22:04:21 -0400 Dan McDonald wrote: > Three years ago OmniOS r151002 was released to the world. It's been > a while, and I've only been here for not quite half it's lifetime, > I'm looking forward to many more years of OmniOS. This might seem rather corny or clich?d Dan, but I for one am enormously thankful for OmniTI's decision to open up their distribution to the world. I hope it's paid-off for them, and it's great to continue to run a Solaris-based OS on the server, that's for the server and maintained by people who know servers. Let's all continue to do our bit and give feedback and do our bit for the distribution. Michael. From davide.poletto at gmail.com Fri Apr 3 10:11:12 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Fri, 3 Apr 2015 12:11:12 +0200 Subject: [OmniOS-discuss] And finally -- Happy 3rd Anniversary OmniOS! In-Reply-To: <9FA18CCC-5E5A-435B-8429-A6BCF2E3CD6F@omniti.com> References: <9FA18CCC-5E5A-435B-8429-A6BCF2E3CD6F@omniti.com> Message-ID: That's my first post on the list...I'm silently using OmniOS since its 151002 release, trying to learn as much I can (and yes...I'm still a noob among experts who play with complex systems) from every single post I've seen here during these fast moving years. It's time for me to say that what you all have done, what you all are doing and, hopefully, what you all are going to do with and for OmniOS is amazing. One word again: Amazing. OmniTI is great, OmniOS is amazing. Really. Kind regards, Davide (Europe, Italy) On Apr 3, 2015 4:11 AM, "Dan McDonald" wrote: > Three years ago OmniOS r151002 was released to the world. It's been a > while, and I've only been here for not quite half it's lifetime, I'm > looking forward to many more years of OmniOS. > > Thanks! > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Fri Apr 3 11:16:13 2015 From: mir at miras.org (Michael Rasmussen) Date: Fri, 3 Apr 2015 13:16:13 +0200 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> Message-ID: <20150403131613.655a2266@sleipner.datanom.net> Hi Dan, On Thu, 2 Apr 2015 21:58:26 -0400 Dan McDonald wrote: > Say hello to OmniOS r151014: > First congratulation;-) Second an question. In 151006 you needed to freeze entire to be absolutely curtain to not get packages from a never release. I guess with the new policy of a dedicate repo for each release this precaution is no longer needed? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: This fortune is encrypted -- get your decoder rings ready! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Fri Apr 3 12:47:47 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 08:47:47 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <20150403131613.655a2266@sleipner.datanom.net> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <20150403131613.655a2266@sleipner.datanom.net> Message-ID: <8BFD112F-E438-48EC-B6D6-6BD34E6B1046@omniti.com> Correct, and that's why we went to the change-the-repo model. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 3, 2015, at 7:16 AM, Michael Rasmussen wrote: > > Hi Dan, > > On Thu, 2 Apr 2015 21:58:26 -0400 > Dan McDonald wrote: > >> Say hello to OmniOS r151014: >> > First congratulation;-) > > Second an question. In 151006 you needed to freeze entire to be > absolutely curtain to not get packages from a never release. I guess > with the new policy of a dedicate repo for each release this precaution > is no longer needed? > > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > This fortune is encrypted -- get your decoder rings ready! > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From vab at bb-c.de Fri Apr 3 14:12:30 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 3 Apr 2015 16:12:30 +0200 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> Message-ID: <21790.40910.761210.766294@glaurung.bb-c.de> Dan McDonald writes: > Say hello to OmniOS r151014: > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > I won't go over all of the release notes here, but I will say to > FOLLOW THE UPGRADE INSTRUCTIONS CAREFULLY. People who upgrade must > make sure they don't run into the too-many-BEs problem (more than > 40, worry about it), AND make sure they update the signature policy > when they reset the "omnios" publisher. Thanks for all of the great work you and OmniTI are doing. OmniOS is Good Stuff(tm)! One info item for those of you who upgraded right away (like me :-). If you have IPS pkg servers running on your system, they will be in maintenance mode after you reboot into your new 151014 BE. You need to manually "refresh" and "clear" your server instances: # svcadm refresh svc:/application/pkg/server: # svcadm clear svc:/application/pkg/server: This is because the name of the start method has changed in the manifest (from "svc-pkg-depot" to "svc-pkg-server"). HTH, and happy Easter! Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Fri Apr 3 14:14:06 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 10:14:06 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <21790.40910.761210.766294@glaurung.bb-c.de> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <21790.40910.761210.766294@glaurung.bb-c.de> Message-ID: Thanks for your praise, and also... > On Apr 3, 2015, at 10:12 AM, Volker A. Brandt wrote: > > Dan McDonald writes: >> Say hello to OmniOS r151014: > > You need to manually "refresh" and "clear" your server instances: > > # svcadm refresh svc:/application/pkg/server: > # svcadm clear svc:/application/pkg/server: > > This is because the name of the start method has changed in the > manifest (from "svc-pkg-depot" to "svc-pkg-server"). ... THANK YOU for this warning. I forgot about that particular case. Dan From doug at will.to Fri Apr 3 14:39:31 2015 From: doug at will.to (Doug Hughes) Date: Fri, 3 Apr 2015 10:39:31 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <21790.40910.761210.766294@glaurung.bb-c.de> Message-ID: Does anybody know if anybody is planning on updating the list of free packages in a repo somewhere? in r12 using the public omniti repo (r10) was a bit tenuous. I imagine it will be even mor so with r14. it'd be nice to reference an up to date open source repo somewhere for things like postfix, iperf, and a bunch of other utils. On Fri, Apr 3, 2015 at 10:14 AM, Dan McDonald wrote: > Thanks for your praise, and also... > > > On Apr 3, 2015, at 10:12 AM, Volker A. Brandt wrote: > > > > Dan McDonald writes: > >> Say hello to OmniOS r151014: > > > > > > > You need to manually "refresh" and "clear" your server instances: > > > > # svcadm refresh svc:/application/pkg/server: > > # svcadm clear svc:/application/pkg/server: > > > > This is because the name of the start method has changed in the > > manifest (from "svc-pkg-depot" to "svc-pkg-server"). > > ... THANK YOU for this warning. I forgot about that particular case. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Apr 3 14:51:22 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 10:51:22 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <21790.40910.761210.766294@glaurung.bb-c.de> Message-ID: > On Apr 3, 2015, at 10:39 AM, Doug Hughes wrote: > > Does anybody know if anybody is planning on updating the list of free packages in a repo somewhere? in r12 using the public omniti repo (r10) was a bit tenuous. You talking about the omniti-ms (aka. ms.omniti.com) repo? > I imagine it will be even mor so with r14. it'd be nice to reference an up to date open source repo somewhere for things like postfix, iperf, and a bunch of other utils. If you're talking omniti-ms, I believe there's work being done (or possibly already done) to make 'em more 014-friendly. Dan From doug at will.to Fri Apr 3 15:08:00 2015 From: doug at will.to (Doug Hughes) Date: Fri, 3 Apr 2015 11:08:00 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <21790.40910.761210.766294@glaurung.bb-c.de> Message-ID: Yes, that! I've tried it somewhat recently on r12 with mixed luck. Some things are ok, others just have too many non-available dependencies or conflicts. (sorry, no specifics at the moment) On Fri, Apr 3, 2015 at 10:51 AM, Dan McDonald wrote: > > > On Apr 3, 2015, at 10:39 AM, Doug Hughes wrote: > > > > Does anybody know if anybody is planning on updating the list of free > packages in a repo somewhere? in r12 using the public omniti repo (r10) was > a bit tenuous. > > You talking about the omniti-ms (aka. ms.omniti.com) repo? > > > I imagine it will be even mor so with r14. it'd be nice to reference an > up to date open source repo somewhere for things like postfix, iperf, and a > bunch of other utils. > > If you're talking omniti-ms, I believe there's work being done (or > possibly already done) to make 'em more 014-friendly. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsmith at careyweb.com Fri Apr 3 15:11:12 2015 From: nsmith at careyweb.com (Nate Smith) Date: Fri, 3 Apr 2015 11:11:12 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> Message-ID: Update. I turned off sr/iov and also the I/OAT DMA Engine in BIOS to see if that solved the problem. IT definitely seemed to help. My fibre targets didn?t drop out immediately on a backup, but when the system came back under a decent load it dropped the luns again. Thinking about messing with the Queue Depth like you mentioned, Thomas. From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 3:44 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V You wrote "I get weird "Drop outs" in certain IO situations." In which situations? On VMware or HyperV? Can you see any timeouts in an VM log? How many Disks in your pool? Wich Raidz? Raidcontroller? Do you use zoning in your Fabric? Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 21:24 schrieb Nate Smith : I?m running maybe 7 active VMs on two servers across two different luns/pools (basically have a "Fast" storage Pool and a "Slower" storage Pool). From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 3:14 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V I remember that i had also a problem on IBM Server... See http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030265 That helps me... How many VMs did you had on every lun? Big lungs make sometimes trouble on vmware. Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:58 schrieb Nate Smith : You mentioned Queue depth. I will have to check into recommended settings for HyperV... My Storage Pool is about 32TB raw (10TB used), and I have 6 luns. I also have a 6TB pool that is 2 luns feeding my 3 system hyper-v cluster. Situations that trigger dopout behavior include: snapshot initiation on the hypervisor, checkpoint deletion (with accompanying vhdx merge). I?m using Dell R720s with QLE2562 cards. I?ve also had this problem on an IBM server SR2625ULXLR which was an intel 5520 chipset. We discussed this a bit back, but both these systems have risers, and we surmised it could be a riser issue, but I don?t know if I buy it. So FC Switch is a dual (full mesh) HP8-20Q which is a Qlogic OEM. How do I turn of sr-iov and pci-express speed? Is this a Bios or Omnios setting? I posted errors a couple times. (you responded these could be bios) I get weird "Drop outs" in certain IO situations. I get no notice of the drop out, just a notice when it comes back up. Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:30:32 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt0,0 LINK UP, portid 20000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:25 storm3 last message repeated 1 time Apr 2 09:31:54 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt2,0 LINK UP, portid 20100, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt1,0 LINK UP, portid 10000, topology Fabric Pt-to-Pt,speed 8G Apr 2 09:31:56 storm3 fct: [ID 132490 kern.notice] NOTICE: qlt3,0 LINK UP, portid 10100, topology Fabric Pt-to-Pt,speed 8G From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:25 PM To: Nate Smith Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Which server system do you use for storage? HP, DELL, Supermicro? Turn off sr-iov thats make many problems and try to turn off auto detection f?r pci-express speed. And don?t use any PCI-Express slots for graphic cards! Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 20:16 schrieb Nate Smith : Hmmm. Was hoping for an 8GB variant (I?m on QL2562), might have to go down to this to see how well it works. Thanks, -Nate From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 2:15 PM To: Nate Smith Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Of course... We use Emulex LPe11002 Dual Port 4Gb PCIe Fibre With latest firmware. Works great!!! All VMServer use RoundRoubin as pathselection. For FC Switch we use 2 x Brocade 5000. Low cost, good speed an stable ^^ bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 19:35 schrieb Nate Smith : Can I ask what model cards, Thomas? From: T. Wiese, OVIS IT Consulting GmbH [mailto:thomas.wiese at ovis-consulting.de] Sent: Thursday, April 02, 2015 1:34 PM To: Dan McDonald Cc: Nate Smith; omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Hi, we had very good experience with omnios and fibrechannel. We tried it with infiniband and SRP but no look. Because the Mellanox driver were only community based. But after we changed all back to FibreChannel ist works great. We use only EmulexCards, because there were listed by VMware in the HCL for ESXi 5.5 We had 10 VMHosts, 3 Storageserver each witch 1 dual port FC Card. They host 124 VMs, 10 Terminalserver, 5 SQL-Server, and 8 ExchangeServer. No Probs thins were changed back to FC! So i can say, use HCL listed Cards for VMWare! Bye Thomas Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 02.04.2015 um 18:58 schrieb Dan McDonald : On Apr 2, 2015, at 12:43 PM, Nate Smith wrote: Is it limited to NFS on VSphere, or is there some way I can get this working with Hyper-V (which would be vastly preferable due to licensing advantages for me)? Hyper-V uses SMB3.0, right? Like iSCSI, illumos community member (and storage vendor) Nexenta has done nontrivial amounts of work here. It's "simply" a matter of upstreaming it. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Apr 3 15:27:50 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 11:27:50 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> Message-ID: <8AD5DBCB-7601-48D8-AE07-5AEE0D5C8148@omniti.com> Speaking of BIOS... I thought everyone knew this, but in case you don't, you need to disable C-states for ANY illumos distro. Not sure if you did that already, though. FYI, Dan From danmcd at omniti.com Fri Apr 3 19:42:59 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 15:42:59 -0400 Subject: [OmniOS-discuss] Attention still-using r151006 users --> one last big kernel update Message-ID: <359990EA-F392-4F4A-B389-00AC32BF265B@omniti.com> At the request of one of our customers, we've rebuilt the entirety of illumos-omnios for r151006 (no new features, just a clean-from-scratch rebuild) to address any possible concerns about mismatched kernel components lying around the the r151006 (aka. the old http://pkg.omniti.com/omnios/release ) repo. This will mean if you're an 006 user, you have a "pkg update" that'll require a reboot. There is nothing new in this update, save for a fresh build of ALL existing 006 components. This is not a backport of any later features beyond ones already done months ago. This is merely to (re)stabilize 006. We highly recommend starting your migration to r151014, but this refresh is a stablizer in case you need more time. In one year, r151006 support will entirely disappear. Until then, it will receive ONLY security updates. Thanks, Dan McDonald -- OmniOS Engineering From Kevin.Swab at ColoState.EDU Fri Apr 3 20:07:15 2015 From: Kevin.Swab at ColoState.EDU (Kevin Swab) Date: Fri, 03 Apr 2015 14:07:15 -0600 Subject: [OmniOS-discuss] r151014 and ipmitool Message-ID: <551EF2F3.40003@ColoState.EDU> Hello Omni crew and list, I upgraded a system to r151014 this morning, and most everything looks great - Thanks! The one exception I've noticed is 'ipmitool'. Further to the discussion on 3/25 regarding ipmitool in bloody, the 'open' interface seems to have gone missing, preventing direct access through /dev/ipmi0: # cat /etc/release OmniOS v11 r151014 Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. # /usr/sbin/ipmitool -h 2>&1 | ggrep -A5 Interfaces Interfaces: lan IPMI v1.5 LAN Interface [default] lanplus IPMI v2.0 RMCP+ LAN Interface serial-terminal Serial Interface, Terminal Mode serial-basic Serial Interface, Basic Mode Do you suppose you could put that back when you have a chance? Thanks, Kevin From danmcd at omniti.com Fri Apr 3 21:02:21 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 17:02:21 -0400 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: <551EF2F3.40003@ColoState.EDU> References: <551EF2F3.40003@ColoState.EDU> Message-ID: I thought I had in response to someone (you?) already. Can you please check the version in the 014 repo now? (I'm away from any computers at the moment.) Here's the commits in OmniOS-build's master and r151014 branches respectively: https://github.com/omniti-labs/omnios-build/commit/1212fafafc8fbac63093e77a867f397a96b79bf5 https://github.com/omniti-labs/omnios-build/commit/4c983f3abd8a3f9ffeb8261ed735bf3c5e0da2f6 When I'm near a computer again, I'll make sure this actually built. It should have. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 3, 2015, at 4:07 PM, Kevin Swab wrote: > > Hello Omni crew and list, > > I upgraded a system to r151014 this morning, and most everything looks > great - Thanks! The one exception I've noticed is 'ipmitool'. Further > to the discussion on 3/25 regarding ipmitool in bloody, the 'open' > interface seems to have gone missing, preventing direct access through > /dev/ipmi0: > > # cat /etc/release > OmniOS v11 r151014 > Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved. > Use is subject to license terms. > # /usr/sbin/ipmitool -h 2>&1 | ggrep -A5 Interfaces > Interfaces: > lan IPMI v1.5 LAN Interface [default] > lanplus IPMI v2.0 RMCP+ LAN Interface > serial-terminal Serial Interface, Terminal Mode > serial-basic Serial Interface, Basic Mode > > > Do you suppose you could put that back when you have a chance? > > Thanks, > Kevin > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From Kevin.Swab at ColoState.EDU Fri Apr 3 21:34:03 2015 From: Kevin.Swab at ColoState.EDU (Kevin Swab) Date: Fri, 03 Apr 2015 15:34:03 -0600 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: References: <551EF2F3.40003@ColoState.EDU> Message-ID: <551F074B.2070001@ColoState.EDU> Well the patch looks right as far as I can tell, but I reinstalled ipmitool just now and still no 'open' interface. Maybe (as you suspected) it didn't actually get built? Kevin On 04/03/2015 03:02 PM, Dan McDonald wrote: > I thought I had in response to someone (you?) already. Can you please check the version in the 014 repo now? (I'm away from any computers at the moment.) > > Here's the commits in OmniOS-build's master and r151014 branches respectively: > > https://github.com/omniti-labs/omnios-build/commit/1212fafafc8fbac63093e77a867f397a96b79bf5 > > https://github.com/omniti-labs/omnios-build/commit/4c983f3abd8a3f9ffeb8261ed735bf3c5e0da2f6 > > > When I'm near a computer again, I'll make sure this actually built. It should have. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 3, 2015, at 4:07 PM, Kevin Swab wrote: >> >> Hello Omni crew and list, >> >> I upgraded a system to r151014 this morning, and most everything looks >> great - Thanks! The one exception I've noticed is 'ipmitool'. Further >> to the discussion on 3/25 regarding ipmitool in bloody, the 'open' >> interface seems to have gone missing, preventing direct access through >> /dev/ipmi0: >> >> # cat /etc/release >> OmniOS v11 r151014 >> Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved. >> Use is subject to license terms. >> # /usr/sbin/ipmitool -h 2>&1 | ggrep -A5 Interfaces >> Interfaces: >> lan IPMI v1.5 LAN Interface [default] >> lanplus IPMI v2.0 RMCP+ LAN Interface >> serial-terminal Serial Interface, Terminal Mode >> serial-basic Serial Interface, Basic Mode >> >> >> Do you suppose you could put that back when you have a chance? >> >> Thanks, >> Kevin >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Fri Apr 3 21:53:16 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 17:53:16 -0400 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: <551F074B.2070001@ColoState.EDU> References: <551EF2F3.40003@ColoState.EDU> <551F074B.2070001@ColoState.EDU> Message-ID: Greetings from BWI... > On Apr 3, 2015, at 5:34 PM, Kevin Swab wrote: > > Well the patch looks right as far as I can tell, but I reinstalled > ipmitool just now and still no 'open' interface. Maybe (as you > suspected) it didn't actually get built? You and I are wrong w.r.t. the patch. I patched the wrong file. -bash-4.3$ git diff diff --git a/build/ipmitool/patches/configure.patch b/build/ipmitool/patches/configure.patch index 34d4dae..9469270 100644 --- a/build/ipmitool/patches/configure.patch +++ b/build/ipmitool/patches/configure.patch @@ -1,6 +1,6 @@ ---- ipmitool-1.8.15/configure.orig Wed Mar 25 19:40:41 2015 -+++ ipmitool-1.8.15/configure Wed Mar 25 19:40:50 2015 -@@ -12638,7 +12638,7 @@ +--- ipmitool-1.8.15/configure.ac.orig Fri Apr 3 17:46:06 2015 ++++ ipmitool-1.8.15/configure.ac Fri Apr 3 17:45:47 2015 +@@ -78,7 +78,7 @@ # disable the linux-specific interfaces xenable_intf_bmc=yes xenable_intf_imb=no I will be updating omnios-build both r151014 and master. Then respinning the package. The current one is: -bash-4.3$ pkg list -v ipmitool FMRI IFO pkg://omnios/system/management/ipmitool at 1.8.15-0.151014:20150402T213812Z i-- -bash-4.3$ The new one will have a 20150403... value when it shows up. I'll also re-ping the list. Good catch, Kevin! And NOTE: the update will create a backup BE. You all should erase that backup BE afterwards (given what we discovered about #-of-BEs during 014's testing). Thank you! Dan From danmcd at omniti.com Fri Apr 3 22:03:22 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 3 Apr 2015 18:03:22 -0400 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: References: <551EF2F3.40003@ColoState.EDU> <551F074B.2070001@ColoState.EDU> Message-ID: <0CA97D66-D256-4D4D-A47A-0962049AA1C2@omniti.com> > On Apr 3, 2015, at 5:53 PM, Dan McDonald wrote: > > The new one will have a 20150403... value when it shows up. I'll also re-ping the list. r151014(~)[0]% pkg list -v ipmitool FMRI IFO pkg://omnios/system/management/ipmitool at 1.8.15-0.151014:20150403T215657Z i-- r151014(~)[0]% ipmitool -h | & ggrep -H Interface (standard input): -I intf Interface to use (standard input):Interfaces: (standard input): open Linux OpenIPMI Interface [default] (standard input): lan IPMI v1.5 LAN Interface (standard input): lanplus IPMI v2.0 RMCP+ LAN Interface (standard input): serial-terminal Serial Interface, Terminal Mode (standard input): serial-basic Serial Interface, Basic Mode (standard input): dcmi Data Center Management Interface I think that's better. Please confirm/deny this on your end, Kevin? Thanks again for the catch! Dan From Kevin.Swab at ColoState.EDU Fri Apr 3 22:16:50 2015 From: Kevin.Swab at ColoState.EDU (Kevin Swab) Date: Fri, 03 Apr 2015 16:16:50 -0600 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: <0CA97D66-D256-4D4D-A47A-0962049AA1C2@omniti.com> References: <551EF2F3.40003@ColoState.EDU> <551F074B.2070001@ColoState.EDU> <0CA97D66-D256-4D4D-A47A-0962049AA1C2@omniti.com> Message-ID: <551F1152.8030706@ColoState.EDU> I upgraded to: pkg://omnios/system/management/ipmitool at 1.8.15-0.151014:20150403T215657Z and it's working great! Thanks Dan! On 04/03/2015 04:03 PM, Dan McDonald wrote: > >> On Apr 3, 2015, at 5:53 PM, Dan McDonald wrote: >> >> The new one will have a 20150403... value when it shows up. I'll also re-ping the list. > > r151014(~)[0]% pkg list -v ipmitool > FMRI IFO > pkg://omnios/system/management/ipmitool at 1.8.15-0.151014:20150403T215657Z i-- > r151014(~)[0]% ipmitool -h | & ggrep -H Interface > (standard input): -I intf Interface to use > (standard input):Interfaces: > (standard input): open Linux OpenIPMI Interface [default] > (standard input): lan IPMI v1.5 LAN Interface > (standard input): lanplus IPMI v2.0 RMCP+ LAN Interface > (standard input): serial-terminal Serial Interface, Terminal Mode > (standard input): serial-basic Serial Interface, Basic Mode > (standard input): dcmi Data Center Management Interface > > > I think that's better. Please confirm/deny this on your end, Kevin? > > Thanks again for the catch! > Dan > From fwp at deepthought.com Sat Apr 4 04:31:54 2015 From: fwp at deepthought.com (Frank Pittel) Date: Fri, 3 Apr 2015 23:31:54 -0500 Subject: [OmniOS-discuss] Realtek ethernet driver Message-ID: <20150404043154.GA2630@warlock.deepthought.com> I have an addon ethernet board in my machine that uses a RTL8169 chip. The driver loads and I am able to configure it and assign the nic an IP address. However when I connect a cable to it the nic doesn't respond to ping, ssh, etc. The intel onboard nic works without issue. The relevent entry from lspci is: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) Is there a known issue with the driver? Frank From vab at bb-c.de Sat Apr 4 08:14:58 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Sat, 4 Apr 2015 10:14:58 +0200 Subject: [OmniOS-discuss] r151014 and ipmitool In-Reply-To: References: <551EF2F3.40003@ColoState.EDU> <551F074B.2070001@ColoState.EDU> Message-ID: <21791.40322.340910.413791@glaurung.bb-c.de> Dan McDonald writes: [...] > I will be updating omnios-build both r151014 and master. Then > respinning the package. The current one is: > > -bash-4.3$ pkg list -v ipmitool FMRI IFO > pkg://omnios/system/management/ipmitool at 1.8.15-0.151014:20150402T213812Z > i-- -bash-4.3$ > > The new one will have a 20150403... value when it shows up. I'll > also re-ping the list. > > Good catch, Kevin! And NOTE: the update will create a backup BE. > You all should erase that backup BE afterwards (given what we > discovered about #-of-BEs during 014's testing). ... or do a "pkg update --no-backup-be ..." ;-) Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From mir at miras.org Sat Apr 4 15:57:43 2015 From: mir at miras.org (Michael Rasmussen) Date: Sat, 4 Apr 2015 17:57:43 +0200 Subject: [OmniOS-discuss] New MB Message-ID: <20150404175743.6b504b61@sleipner.datanom.net> Hi all, I have been looking at this motherboard for a low-power storage server: http://supermicro.nl/products/motherboard/Atom/X10/A1SA7-2750F.cfm I wonder whether there should be any problems in Omnios for this board? It is packed with a LSI 2116 controller which is also used in LSISAS9200-16e and LSISAS9201-16i Nics is based on Intel i354. 1 internal SATA 3 with SATA DOM power connector which I consider use for OS. Anybody with experience using Intel Avoton (C2750) as storage server? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: We have found all life forms in the galaxy are capable of superior development. -- Kirk, "The Gamesters of Triskelion", stardate 3211.7 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From thomas.wiese at ovis-consulting.de Sat Apr 4 18:43:42 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Sat, 4 Apr 2015 18:43:42 +0000 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <8AD5DBCB-7601-48D8-AE07-5AEE0D5C8148@omniti.com> References: <1154e54e-30cf-4501-b9ed-e3a959900604@careyweb.com> <34CFE093-177D-4F3B-94FC-9839E6C7258E@omniti.com> <35FE7D75-6B47-43B2-B02D-6A80E88CB901@ovis-consulting.de> <83EC3559-09CE-434A-822F-A8D55A00443C@ovis-consulting.de> <7b157201-9d62-4dd3-82d9-4d2c6556acf1@careyweb.com> <2D3CC48C-5697-4304-BD80-A5999E741016@ovis-consulting.de> <1de22d15-33a1-405f-985d-31dcc6812f43@careyweb.com> <8AD5DBCB-7601-48D8-AE07-5AEE0D5C8148@omniti.com> Message-ID: Hi Dan, are there other Bios settings for illumos to known? THX > Mit freundlichen Gr??en Thomas Wiese Gesch?ftsf?hrender Gesellschafter OVIS IT Consulting GmbH Arnulfstra?e 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Gesch?ftsf?hrer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 03.04.2015 um 17:27 schrieb Dan McDonald : > > Speaking of BIOS... > > I thought everyone knew this, but in case you don't, you need to disable C-states for ANY illumos distro. Not sure if you did that already, though. > > FYI, > Dan > From mir at miras.org Sat Apr 4 18:45:03 2015 From: mir at miras.org (Michael Rasmussen) Date: Sat, 4 Apr 2015 20:45:03 +0200 Subject: [OmniOS-discuss] New MB In-Reply-To: References: <20150404175743.6b504b61@sleipner.datanom.net> Message-ID: <20150404204503.1ad47b54@sleipner.datanom.net> On Sat, 4 Apr 2015 11:02:10 -0600 Warren Marts wrote: > Fascinating product - I don't know if you've spoken with your Supermicro > representative, but I see it has non-standard form factor and power supply > connectors. > For formfactor (8.3x6.7) I think it boils down-to that it is larger than mini-itx (6.7x6.7) and lesser than mATX (9.6x9.6). So given a U1-4 with space for at least mATX should suffice. As for the power supply the one used in CSE-801LTQ-R406B is PWS-406P-1R which can be seen here: http://www.newegg.com/Product/Product.aspx?Item=N82E16817377063 which apart from a 24 pin connector and a 2+4 CPU (+12V at 33A) as well as a 4 pin standby (5V Standby at 3A). You could by the Supermicro for safety but it should be possible to find another PSU with the given specs in standard ATX format. > > There's 10Gb ethernet supported with some sort of proprietary card in the > server chassis. > I guess it is and add-on PCIe card. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: What fools these mortals be. -- Lucius Annaeus Seneca -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From nagele at wildbit.com Sat Apr 4 19:07:54 2015 From: nagele at wildbit.com (Chris Nagele) Date: Sat, 4 Apr 2015 15:07:54 -0400 Subject: [OmniOS-discuss] All SSD pool advice In-Reply-To: References: Message-ID: We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? Thanks, Chris -- Chris Nagele Co-founder, Wildbit Beanstalk , Postmark , dploy.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at marzocchi.net Sat Apr 4 21:11:18 2015 From: lists at marzocchi.net (Olaf Marzocchi) Date: Sat, 04 Apr 2015 23:11:18 +0200 Subject: [OmniOS-discuss] All SSD pool advice In-Reply-To: References: Message-ID: <8D773654-6A29-4DBA-BC10-FEB18F015678@marzocchi.net> To begin with, this could be useful: http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes And remember that the closer you get to the rated write-endurance the shorter the no-power retention time becomes. Olaf Il 04 aprile 2015 21:07:54 CEST, Chris Nagele ha scritto: >We've been running a few 4U Supermicro servers using ZeusRAM for zil >and >SSDs for L2. The main disks are regular 1TB SAS. > >I'm considering moving to all SSD since the pricing has dropped so >much. >What things should I know or do when moving to all SSD pools? I'm >assuming >I don't need L2 and that I should keep the ZeusRAM. Should I only use >certain types of SSDs? > >Thanks, >Chris > > >-- > >Chris Nagele >Co-founder, Wildbit >Beanstalk , Postmark >, >dploy.io > > >------------------------------------------------------------------------ > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From alka at hfg-gmuend.de Sat Apr 4 21:34:15 2015 From: alka at hfg-gmuend.de (=?utf-8?Q?G=C3=BCnther_Alka?=) Date: Sat, 4 Apr 2015 23:34:15 +0200 Subject: [OmniOS-discuss] Fwd: All SSD pool advice References: Message-ID: <19927354-4053-4F08-AB27-B989C2265FB2@hfg-gmuend.de> SSD only pools can give you a similar sequential performance like good SAS disks but while oops of a regular disk is a few hundreds, a SSD is at a few thousands so there may be a huge improvement with iops sensitive use cases. With ZeusRam and SAS disks, it seems a production machine. For SSD only I would consider - with an expander stay with SAS, without expander Sata is much cheaper - prefer enterprise SSDs with powerless protection and a build in over provisioning like Intel series 3500 - 3700 and newer Desktop SSDs come without over provisioning (you may add your own) but without powerless protection (okay, your SAS disks does no have as well) - as SSDs have that many iops, you may use Raid-Z (1-3) instead of multiple mirrors (reduce cost) - a L2Arc is not needed but a ZeusRAM as dedicated ZIL makes a lot of sense as it is much faster than your SSD pool (and you do not need to write data twice (sync log and cached write) to your pool Gea > > > >> Am 04.04.2015 um 21:07 schrieb Chris Nagele >: >> >> We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. >> >> I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? >> >> Thanks, >> Chris >> >> >> -- >> >> Chris Nagele >> Co-founder, Wildbit >> Beanstalk , Postmark , dploy.io >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsmith at careyweb.com Sat Apr 4 22:47:42 2015 From: nsmith at careyweb.com (Nate Smith) Date: Sat, 4 Apr 2015 18:47:42 -0400 Subject: [OmniOS-discuss] Fwd: All SSD pool advice In-Reply-To: <19927354-4053-4F08-AB27-B989C2265FB2@hfg-gmuend.de> References: <19927354-4053-4F08-AB27-B989C2265FB2@hfg-gmuend.de> Message-ID: You also have to consider your use cases: High read low write environments, versus mixed loads, versus high write environments. SSD vendors are designing enterprise drives with those use cases in mind. High read environments will not have nearly the write endurance. (Intel S3500s seem designed for low write endurance environments). And yes, as Gea said, you need to have built in capacitors in enterprise SSDs for power protection. Agree with Gea on the Intel S3500 and S3700 series. They?re good, but the write endurance is much lower on S3500. I?ve been using the Samsung datacenter series because of the price. http://www.samsung.com/global/business/semiconductor/product/flash-ssd/overview Also, no SAS expanders and SATA are a no-no. SAS SSDs are much more expensive and harder to find. There are decently priced enterprise level SATA SSDs. Plan your infrastructure accordingly. -Nate From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of G?nther Alka Sent: Saturday, April 04, 2015 5:34 PM To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] Fwd: All SSD pool advice SSD only pools can give you a similar sequential performance like good SAS disks but while oops of a regular disk is a few hundreds, a SSD is at a few thousands so there may be a huge improvement with iops sensitive use cases. With ZeusRam and SAS disks, it seems a production machine. For SSD only I would consider - with an expander stay with SAS, without expander Sata is much cheaper - prefer enterprise SSDs with powerless protection and a build in over provisioning like Intel series 3500 - 3700 and newer Desktop SSDs come without over provisioning (you may add your own) but without powerless protection (okay, your SAS disks does no have as well) - as SSDs have that many iops, you may use Raid-Z (1-3) instead of multiple mirrors (reduce cost) - a L2Arc is not needed but a ZeusRAM as dedicated ZIL makes a lot of sense as it is much faster than your SSD pool (and you do not need to write data twice (sync log and cached write) to your pool Gea Am 04.04.2015 um 21:07 schrieb Chris Nagele : We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? Thanks, Chris -- Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Sat Apr 4 23:18:06 2015 From: doug at will.to (Doug Hughes) Date: Sat, 04 Apr 2015 19:18:06 -0400 Subject: [OmniOS-discuss] All SSD pool advice In-Reply-To: References: Message-ID: <5520712E.6030207@will.to> We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the current favorite). They work great for IOPS. Here's my take. 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst the existing zpool devices. They are plenty fast enough. 2) you don't need an L2arc for the same reason. a smaller number of dedicated devices would likely cause more of a bottleneck than serving off the existing pool devices (unless you were to put it on one of those giant RDRAM things or similar, but that adds a lot of expense) On 4/4/2015 3:07 PM, Chris Nagele wrote: > We've been running a few 4U Supermicro servers using ZeusRAM for zil > and SSDs for L2. The main disks are regular 1TB SAS. > > I'm considering moving to all SSD since the pricing has dropped so > much. What things should I know or do when moving to all SSD pools? > I'm assuming I don't need L2 and that I should keep the ZeusRAM. > Should I only use certain types of SSDs? > > Thanks, > Chris > > > -- > > Chris Nagele > Co-founder,Wildbit > Beanstalk , Postmark > , dploy.io > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Mon Apr 6 08:20:56 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 6 Apr 2015 10:20:56 +0200 Subject: [OmniOS-discuss] r151014 KVM crash Message-ID: Hi! I switched one of my development ?machines over to r151014. On that machine I got a few KVM VM's. One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. The following msg is from /var/adm/messages: 40b0000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff0614236000 , id=3, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x1010101 data fffffd 7fffdfe8e0 Apr ?4 20:45:52 omni2 last message repeated 3 times Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0xff3d0f9c data fffff d7fffdfe8b0 Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x0 data 0 Apr ?4 20:45:52 omni2 last message repeated 6 times Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 1 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 2 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 3 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140b0000 , id=1, base_msr= fee00800 PRIx64 base_address=fee00000 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00800 PRIx64 base_address=fee00000 Then it goes on like this: Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 And like this: Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr I switched back to r151012, and there everything is working fine... I do a rollback of the volumes I used for the chroots in the VM, because they've been messed up of the repetedly interupted upgrade attemts, so I run new updates/upgrades on the chroots, and even build new ones, and no problems here in r151012. So the problem seem to be exclusively in r151014. I got some messages on the omnios console after the VM crashes that I didn't record, unfortunatly. What I remember was that it was complaining about a bus, and it was also complains about either ps or pthread as well. I will go back to r151014 again, and run more tests like this, to get this clarified, and record the exact msg on the consol. Any suggestion? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert From natxo.asenjo at gmail.com Mon Apr 6 09:32:16 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 6 Apr 2015 11:32:16 +0200 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> Message-ID: On Fri, Apr 3, 2015 at 3:58 AM, Dan McDonald wrote: > Say hello to OmniOS r151014: > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 upgrade succesful on my home microserver :-) Congrats on the good work! -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From al.slater at scluk.com Mon Apr 6 10:03:47 2015 From: al.slater at scluk.com (Al Slater) Date: Mon, 06 Apr 2015 11:03:47 +0100 Subject: [OmniOS-discuss] pkgrecv r151014 Message-ID: <55225A03.7020102@scluk.com> Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? -- Al Slater From rafibeyli at gmail.com Mon Apr 6 09:50:00 2015 From: rafibeyli at gmail.com (Hafiz Rafiyev) Date: Mon, 6 Apr 2015 12:50:00 +0300 (EEST) Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue Message-ID: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> After upgrade from r151012 to r151014 i have issue with nfs server, after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, and it's being randomly,after omnios restart again some datastores connected and some not when looking omnios side,nfs server up and running, note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport regards Hafiz. From al.slater at scluk.com Mon Apr 6 10:24:30 2015 From: al.slater at scluk.com (Al Slater) Date: Mon, 06 Apr 2015 11:24:30 +0100 Subject: [OmniOS-discuss] pkgrecv r151014 In-Reply-To: <55225A03.7020102@scluk.com> References: <55225A03.7020102@scluk.com> Message-ID: <55225EDE.2010902@scluk.com> On 06/04/15 11:03, Al Slater wrote: > Hi, > > I am trying to pkgrecv r151014 into my own repository and keep bumping > into this: > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > Is there a problem with this package in the repository? Same happens with pkg install... # pkg install pkg:/developer/sunstudio12.1 at 12.1-0.151014 Packages to install: 1 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 3.0M/s Errors were encountered while attempting to retrieve package or file data for the requested operation. Details follow: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) regards -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 From alka at hfg-gmuend.de Mon Apr 6 10:34:30 2015 From: alka at hfg-gmuend.de (=?utf-8?Q?G=C3=BCnther_Alka?=) Date: Mon, 6 Apr 2015 12:34:30 +0200 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> References: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <4700B3B3-2CED-407D-A131-62FE1E392B53@hfg-gmuend.de> just to rule out a permission problem can you recursively reset permissions of that filesystem to a everyone@=modify setting. > Am 06.04.2015 um 11:50 schrieb Hafiz Rafiyev : > > > After upgrade from r151012 to r151014 i have issue with nfs server, > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > and it's being randomly,after omnios restart again some datastores connected and some not > > when looking omnios side,nfs server up and running, > > note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport > > > regards > > Hafiz. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From nagele at wildbit.com Mon Apr 6 13:41:19 2015 From: nagele at wildbit.com (Chris Nagele) Date: Mon, 6 Apr 2015 09:41:19 -0400 Subject: [OmniOS-discuss] All SSD pool advice In-Reply-To: <5520712E.6030207@will.to> References: <5520712E.6030207@will.to> Message-ID: Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS -> SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the > current favorite). They work great for IOPS. Here's my take. > 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst > the existing zpool devices. They are plenty fast enough. > 2) you don't need an L2arc for the same reason. a smaller number of > dedicated devices would likely cause more of a bottleneck than serving off > the existing pool devices (unless you were to put it on one of those giant > RDRAM things or similar, but that adds a lot of expense) > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > SSDs for L2. The main disks are regular 1TB SAS. > > I'm considering moving to all SSD since the pricing has dropped so much. > What things should I know or do when moving to all SSD pools? I'm assuming I > don't need L2 and that I should keep the ZeusRAM. Should I only use certain > types of SSDs? > > Thanks, > Chris > > > -- > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From fabio at fabiorabelo.wiki.br Mon Apr 6 13:53:01 2015 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Mon, 6 Apr 2015 10:53:01 -0300 Subject: [OmniOS-discuss] Fwd: All SSD pool advice In-Reply-To: References: <5520712E.6030207@will.to> Message-ID: Sorry, forget to forward to the list ... ---------- Forwarded message ---------- From: F?bio Rabelo Date: 2015-04-06 10:51 GMT-03:00 Subject: Re: [OmniOS-discuss] All SSD pool advice To: Chris Nagele I never get my hands at that 4U model ... I have 2 of this babys in a customer of mine : http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm Each one with 24 1TB Samsung 850PRO for a litle over an year, OminOS+Napp-it , no issue whatsoever ... Expanded Chassis brings me lots and lots of headaches ... F?bio Rabelo 2015-04-06 10:41 GMT-03:00 Chris Nagele : Thanks everyone. Regarding the expanders, our 4U servers are on the > following chassis: > > http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm > > We are using all SAS disks, except for the SSDs. How big is the risk > here when it comes to SAS -> SATA conversion? Our newer servers have > direct connections on each lane to the disk. > > Chris > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > > > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is > the > > current favorite). They work great for IOPS. Here's my take. > > 1) you don't need a dedicated zil. Just let the zpool intersperse it > amongst > > the existing zpool devices. They are plenty fast enough. > > 2) you don't need an L2arc for the same reason. a smaller number of > > dedicated devices would likely cause more of a bottleneck than serving > off > > the existing pool devices (unless you were to put it on one of those > giant > > RDRAM things or similar, but that adds a lot of expense) > > > > > > > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > > SSDs for L2. The main disks are regular 1TB SAS. > > > > I'm considering moving to all SSD since the pricing has dropped so much. > > What things should I know or do when moving to all SSD pools? I'm > assuming I > > don't need L2 and that I should keep the ZeusRAM. Should I only use > certain > > types of SSDs? > > > > Thanks, > > Chris > > > > > > -- > > > > Chris Nagele > > Co-founder, Wildbit > > Beanstalk, Postmark, dploy.io > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Mon Apr 6 14:00:58 2015 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 6 Apr 2015 09:00:58 -0500 Subject: [OmniOS-discuss] All SSD pool advice In-Reply-To: References: <5520712E.6030207@will.to> Message-ID: On Mon, Apr 6, 2015 at 8:41 AM, Chris Nagele wrote: > Thanks everyone. Regarding the expanders, our 4U servers are on the > following chassis: > > http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm > > We are using all SAS disks, except for the SSDs. How big is the risk > here when it comes to SAS -> SATA conversion? Our newer servers have > direct connections on each lane to the disk. > There are A LOT of opinions on this. What I have done that has worked extremely well was use 70 Samsung 840 Pro SSD with LSI interposers in Supermicro chassis. There were a couple early failures of the interposers but it has been rock solid ever since. mpt_sas blue chunks and panic'd the system on one. On another one I caught it in action and doing a 'zpool offline {device}' kept everything running without a hitch. I run with ZIL off because this is used entirely for scratch data and virtual machines that can be redeployed in minutes. It would be sync safe with the addition of some good log devices. I'm not sure if the interposers increased stability or it has simply been the quality of the Samsung SSD. -Chip > Chris > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > > > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is > the > > current favorite). They work great for IOPS. Here's my take. > > 1) you don't need a dedicated zil. Just let the zpool intersperse it > amongst > > the existing zpool devices. They are plenty fast enough. > > 2) you don't need an L2arc for the same reason. a smaller number of > > dedicated devices would likely cause more of a bottleneck than serving > off > > the existing pool devices (unless you were to put it on one of those > giant > > RDRAM things or similar, but that adds a lot of expense) > > > > > > > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > > SSDs for L2. The main disks are regular 1TB SAS. > > > > I'm considering moving to all SSD since the pricing has dropped so much. > > What things should I know or do when moving to all SSD pools? I'm > assuming I > > don't need L2 and that I should keep the ZeusRAM. Should I only use > certain > > types of SSDs? > > > > Thanks, > > Chris > > > > > > -- > > > > Chris Nagele > > Co-founder, Wildbit > > Beanstalk, Postmark, dploy.io > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Mon Apr 6 14:04:34 2015 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 6 Apr 2015 09:04:34 -0500 Subject: [OmniOS-discuss] Fwd: All SSD pool advice In-Reply-To: References: <5520712E.6030207@will.to> Message-ID: On Mon, Apr 6, 2015 at 8:53 AM, F?bio Rabelo wrote: > Sorry, forget to forward to the list ... > > > ---------- Forwarded message ---------- > From: F?bio Rabelo > Date: 2015-04-06 10:51 GMT-03:00 > Subject: Re: [OmniOS-discuss] All SSD pool advice > To: Chris Nagele > > > I never get my hands at that 4U model ... > > I have 2 of this babys in a customer of mine : > > http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm > > Each one with 24 1TB Samsung 850PRO for a litle over an year, > OminOS+Napp-it , no issue whatsoever ... > > Expanded Chassis brings me lots and lots of headaches ... > The system I've built with interposers has SAS expanders and gives me no problems. Samsung SSDs are the only SSD I've found that works well with the interposer. -Chip > > > F?bio Rabelo > > 2015-04-06 10:41 GMT-03:00 Chris Nagele : > > Thanks everyone. Regarding the expanders, our 4U servers are on the >> following chassis: >> >> http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm >> >> We are using all SAS disks, except for the SSDs. How big is the risk >> here when it comes to SAS -> SATA conversion? Our newer servers have >> direct connections on each lane to the disk. >> >> Chris >> >> Chris Nagele >> Co-founder, Wildbit >> Beanstalk, Postmark, dploy.io >> >> >> On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: >> > >> > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro >> is the >> > current favorite). They work great for IOPS. Here's my take. >> > 1) you don't need a dedicated zil. Just let the zpool intersperse it >> amongst >> > the existing zpool devices. They are plenty fast enough. >> > 2) you don't need an L2arc for the same reason. a smaller number of >> > dedicated devices would likely cause more of a bottleneck than serving >> off >> > the existing pool devices (unless you were to put it on one of those >> giant >> > RDRAM things or similar, but that adds a lot of expense) >> > >> > >> > >> > >> > >> > On 4/4/2015 3:07 PM, Chris Nagele wrote: >> > >> > We've been running a few 4U Supermicro servers using ZeusRAM for zil and >> > SSDs for L2. The main disks are regular 1TB SAS. >> > >> > I'm considering moving to all SSD since the pricing has dropped so much. >> > What things should I know or do when moving to all SSD pools? I'm >> assuming I >> > don't need L2 and that I should keep the ZeusRAM. Should I only use >> certain >> > types of SSDs? >> > >> > Thanks, >> > Chris >> > >> > >> > -- >> > >> > Chris Nagele >> > Co-founder, Wildbit >> > Beanstalk, Postmark, dploy.io >> > >> > >> > >> > _______________________________________________ >> > OmniOS-discuss mailing list >> > OmniOS-discuss at lists.omniti.com >> > http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > >> > >> > >> > _______________________________________________ >> > OmniOS-discuss mailing list >> > OmniOS-discuss at lists.omniti.com >> > http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.sproul at circonus.com Mon Apr 6 14:08:12 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 6 Apr 2015 10:08:12 -0400 Subject: [OmniOS-discuss] Realtek ethernet driver In-Reply-To: <20150404043154.GA2630@warlock.deepthought.com> References: <20150404043154.GA2630@warlock.deepthought.com> Message-ID: On Sat, Apr 4, 2015 at 12:31 AM, Frank Pittel wrote: > I have an addon ethernet board in my machine that uses a RTL8169 chip. The driver loads and I am able to configure it and assign the nic an IP > address. However when I connect a cable to it the nic doesn't respond to ping, ssh, etc. The intel onboard nic works without issue. > > The relevent entry from lspci is: > Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) > > Is there a known issue with the driver? > Frank, This chip is ostensibly supported by rge(7D), but there are many revisions of that chip, used in a wide variety of adapters. These are usually found more on desktop/enthusiast systems than server hardware, so the driver, rge, doesn't get a whole lot of attention. The last substantive update to it was back in the OpenSolaris days, when Sun thought that developer laptops were a good distro target. :/ It's possible there are newer revisions of the chip that have different enough PHYs that the driver doesn't know how to initialize the link. If you could share the PCI ID of that part (`prtconf -d | grep RTL8169`), that would be helpful, but my guess would be that someone will have to take up the task of updating rge(7D) to support more parts. And.. if it were me, I'd just forget about it and use the Intel port. If you need a second NIC, go Intel. Eric From eric.sproul at circonus.com Mon Apr 6 14:14:56 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 6 Apr 2015 10:14:56 -0400 Subject: [OmniOS-discuss] pkgrecv r151014 In-Reply-To: <55225EDE.2010902@scluk.com> References: <55225A03.7020102@scluk.com> <55225EDE.2010902@scluk.com> Message-ID: On Mon, Apr 6, 2015 at 6:24 AM, Al Slater wrote: > On 06/04/15 11:03, Al Slater wrote: >> Hi, >> >> I am trying to pkgrecv r151014 into my own repository and keep bumping >> into this: >> >> pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: >> chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 >> computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) >> >> Is there a problem with this package in the repository? It seems fine from my location: $ pkg contents -mr developer/sunstudio12.1 | grep libsunir.so file 19d832f8b112a9545e9d9b5aaf1384a7a37248f3 chash=b251c238070b6fdbf392194e85319e2c954a5384 elfarch=i386 elfbits=32 elfhash=710138bfbc99dd3aefd4a41dd49b9779cae35f15 group=bin mode=0755 $ curl -s http://pkg.omniti.com/omnios/r151014/file/1/19d832f8b112a9545e9d9b5aaf1384a7a37248f3 | sha1sum b251c238070b6fdbf392194e85319e2c954a5384 - Eric From mir at miras.org Mon Apr 6 14:22:27 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 16:22:27 +0200 Subject: [OmniOS-discuss] Realtek ethernet driver In-Reply-To: References: <20150404043154.GA2630@warlock.deepthought.com> Message-ID: <20150406162227.30fc655b@sleipner.datanom.net> On Mon, 6 Apr 2015 10:08:12 -0400 Eric Sproul wrote: > revisions of that chip, used in a wide variety of adapters. These are > usually found more on desktop/enthusiast systems than server hardware, with one exception: Realtek are often used as interface for IPMI+KVM. At least this is true for all my Supermicro boards. But then again this has nothing to do with the OS;-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Not exactly as shown. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 6 14:25:56 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 10:25:56 -0400 Subject: [OmniOS-discuss] r151014 KVM crash In-Reply-To: References: Message-ID: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> If you can find those extra messages, that'd be very helpful. Your /var/adm/messages.* files should contain everything that gets spit out. When you say "it crashes" you mean the KVM machine, not the OmniOS kernel, right? Thanks, Dan From al.slater at scluk.com Mon Apr 6 14:29:56 2015 From: al.slater at scluk.com (Al Slater) Date: Mon, 06 Apr 2015 15:29:56 +0100 Subject: [OmniOS-discuss] pkgrecv r151014 In-Reply-To: References: <55225A03.7020102@scluk.com> <55225EDE.2010902@scluk.com> Message-ID: <55229864.1070306@scluk.com> Thanks Eric, AV on the gateway was the problem. Al On 06/04/15 15:14, Eric Sproul wrote: > On Mon, Apr 6, 2015 at 6:24 AM, Al Slater wrote: >> On 06/04/15 11:03, Al Slater wrote: >>> Hi, >>> >>> I am trying to pkgrecv r151014 into my own repository and keep bumping >>> into this: >>> >>> pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: >>> chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 >>> computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) >>> >>> Is there a problem with this package in the repository? > > It seems fine from my location: > > $ pkg contents -mr developer/sunstudio12.1 | grep libsunir.so > file 19d832f8b112a9545e9d9b5aaf1384a7a37248f3 > chash=b251c238070b6fdbf392194e85319e2c954a5384 elfarch=i386 elfbits=32 > elfhash=710138bfbc99dd3aefd4a41dd49b9779cae35f15 group=bin mode=0755 > > $ curl -s http://pkg.omniti.com/omnios/r151014/file/1/19d832f8b112a9545e9d9b5aaf1384a7a37248f3 > | sha1sum > b251c238070b6fdbf392194e85319e2c954a5384 - > > Eric > -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 From danmcd at omniti.com Mon Apr 6 14:30:47 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 10:30:47 -0400 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> References: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <5496C3F5-2194-4936-847A-950BD8AAAF55@omniti.com> > On Apr 6, 2015, at 5:50 AM, Hafiz Rafiyev wrote: > > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport Are you having DNS problems? This error is in an unchanged subsystem, the NFSv4 callback daemon. The error looks like something caused by a naming-services failure. I'll forward your note along to an illumos-community NFS expert, I may find out more. Dan From johan.kragsterman at capvert.se Mon Apr 6 14:36:48 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 6 Apr 2015 16:36:48 +0200 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> References: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com>, Message-ID: An HTML attachment was scrubbed... URL: From mir at miras.org Mon Apr 6 14:55:36 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 16:55:36 +0200 Subject: [OmniOS-discuss] Bacula and LTO-3 Message-ID: <20150406165536.20cd68c5@sleipner.datanom.net> Hi all, For my home storage server I am in the position of getting my hand on a decommissioned tape drive either Quantum TE7100 LTO-3 SAS or HP StorageWorks Ultrium 920 SAS LTO 3. I have 2 HBA's in this box: LSI 1068 and LSI 1078. I guess both would be sufficient? Anybody have experience with either one of these on Omnios (151014) and in particular with the Bacula 5.2.6 version from the repo? Which one to choose? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "The jig's up, Elman." "Which jig?" -- Jeff Elman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 6 15:55:27 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 11:55:27 -0400 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: References: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <, > Message-ID: <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> > On Apr 6, 2015, at 10:36 AM, Johan Kragsterman wrote: > > > Hej! > > > I mean the KVM process crashes or get killed or whatever. The KVM virtual machine is suddenly stopped, and can't get started again, until reboot of the OmniOS machine. The Linux OS on the virtual machine doesn't crash. > > I guess I need to get back to the r151014 again to find out more, but I wanted to roll back to r151012 to see the difference. And as I told you, there were no crashes on the r151012. > > When I done some update jobs here on r151012, I'll get back to r151014 and try to find out more... I'm talking with the illumos KVM folks. They mentioned that Ivy Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have erratum that can cause problems. That you do not seem to see these in r151012, however, is very odd. There was only ONE change in the illumos-kvm kernel bits between releases, and it should have nothing to do with the errors you're seeing. commit 8bdb134ab2cbdd179cd0af6b4c4acf21af34fb87 Author: Robert Mustacchi Date: Wed Dec 10 21:22:50 2014 +0000 HVM-812 QEMU build fails after eventfd That change was very tiny. They also asked for kernel panics on your guests, but you say they aren't panicking, just stopped? Do you have coredump from the kvm processes by any chance? That would ALSO be useful. Dan From mir at miras.org Mon Apr 6 16:03:00 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 18:03:00 +0200 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> References: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> Message-ID: <20150406180300.41cd70d5@sleipner.datanom.net> On Mon, 6 Apr 2015 11:55:27 -0400 Dan McDonald wrote: > I'm talking with the illumos KVM folks. They mentioned that Ivy Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have erratum that can cause problems. That you do not seem to see these in r151012, however, is very odd. > There is also E3-12xx v2 which is Ivy Bridge based. Are these affected by this erratum as well? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It's amazing how much "mature wisdom" resembles being too tired. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sjorge+ml at blackdot.be Mon Apr 6 17:04:24 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 06 Apr 2015 19:04:24 +0200 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: <20150406180300.41cd70d5@sleipner.datanom.net> References: <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be> Out of curiosity, are you passing --cpu=host? I had issues with that on my ivy bridge. I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make a lot of things smoother. I stil get these but qemu does not crash for me: Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 PRIx64 base_address=fee00000 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Regards Jorge On 2015-04-06 18:03, Michael Rasmussen wrote: > On Mon, 6 Apr 2015 11:55:27 -0400 > Dan McDonald wrote: > >> I'm talking with the illumos KVM folks. They mentioned that Ivy >> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >> erratum that can cause problems. That you do not seem to see these in >> r151012, however, is very odd. >> > There is also E3-12xx v2 which is Ivy Bridge based. Are these affected > by this erratum as well? > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From johan.kragsterman at capvert.se Mon Apr 6 17:22:08 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 6 Apr 2015 19:22:08 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be> References: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <, > <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: Jorge, I thought you would jump in on this thread! Are you asking me or Michael? I'm not running ivy bridge on this machine, it's an older westmere... Yeah, I pass --cpu=host Can you provide your config file, pls? Mine is like this: root at omni2:/usr/bin# cat vmedu14041.sh #!/usr/bin/bash # on omnios command is /usr/bin/qemu-system-x86_64 # configuration NAME="EDU14041" NUM=4 VNIC0=ltsp0 VNIC1=ltsp1 VNIC2=ltsptl0 HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt CD=/mainpool/iso/edu14041.iso HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap MEM=8192 # don't change below here! TLN=`expr 7000 + $NUM` mac0=`dladm show-vnic -po macaddress $VNIC0` mac1=`dladm show-vnic -po macaddress $VNIC1` mac2=`dladm show-vnic -po macaddress $VNIC2` /usr/bin/qemu-system-x86_64 \ -name $NAME \ -boot cd \ -enable-kvm \ -vnc 0.0.0.0:$NUM \ -smp cores=2,threads=2 \ -m $MEM \ -no-hpet \ -localtime \ -drive file=$HDD0,if=virtio,index=0 \ -drive file=$HDD1,if=virtio,index=2 \ -drive file=$CD,media=cdrom,if=ide,index=1 \ -drive file=$HDD2,if=virtio,index=3 \ -drive file=$HDD3,if=virtio,index=4 \ -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ -vga std \ -cpu host \ -pidfile /mainpool/vm/edu/pids/$NAME.pid \ -monitor telnet:localhost:$TLN,server,nowait,nodelay \ -daemonize if [ $? -gt 0 ]; then echo "Failed to start VM" exit fi port=`expr 5900 + $NUM` public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') echo "Started VM: $NAME" echo "VNC available at: host IP ${public_ip} port ${port}" echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] to exit monitor before quit! " Rgrds Johan -----"OmniOS-discuss" skrev: ----- Till: Michael Rasmussen Fr?n: Jorge Schrauwen S?nt av: "OmniOS-discuss" Datum: 2015-04-06 19:06 Kopia: omnios-discuss at lists.omniti.com ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash Out of curiosity, are you passing --cpu=host? I had issues with that on my ivy bridge. I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make a lot of things smoother. I stil get these but qemu does not crash for me: Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Regards Jorge On 2015-04-06 18:03, Michael Rasmussen wrote: > On Mon, 6 Apr 2015 11:55:27 -0400 > Dan McDonald wrote: > >> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >> erratum that can cause problems. ?That you do not seem to see these in >> r151012, however, is very odd. >> > There is also E3-12xx v2 which is Ivy Bridge based. Are these affected > by this erratum as well? > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From eric.sproul at circonus.com Mon Apr 6 17:23:28 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 6 Apr 2015 13:23:28 -0400 Subject: [OmniOS-discuss] New MB In-Reply-To: <20150404175743.6b504b61@sleipner.datanom.net> References: <20150404175743.6b504b61@sleipner.datanom.net> Message-ID: On Sat, Apr 4, 2015 at 11:57 AM, Michael Rasmussen wrote: > Hi all, > > I have been looking at this motherboard for a low-power storage server: > http://supermicro.nl/products/motherboard/Atom/X10/A1SA7-2750F.cfm > > I wonder whether there should be any problems in Omnios for this board? > > It is packed with a LSI 2116 controller which is also used in > LSISAS9200-16e and LSISAS9201-16i LSI SAS2116 is either pciex1000,64 or ,65. Both appear to be supported by mpt_sas in OmniOS 014. You should be good there. > > Nics is based on Intel i354. Supported in recent stable releases that contain (or got backported) https://www.illumos.org/issues/4431 > > 1 internal SATA 3 with SATA DOM power connector which I consider use > for OS. I believe the C2000 SoC SATA ports are standard AHCI and should "just work". Modulo actually being able to mount the weird form-factor in a standard case (note that you need enough of the mounting holes to line up, not just that the dimensions fit!), I would expect OmniOS to work. Eric From sjorge+ml at blackdot.be Mon Apr 6 17:24:46 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 06 Apr 2015 19:24:46 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: Who ever is having the problem :) It was a bit hard to follow, I'm using kvmadm and this is my config: { "cosmos" : { "nics" : [ { "index" : "0", "nic_name" : "vcosmos0", "model" : "virtio", "vlan_id" : "10" }, { "index" : "1", "nic_name" : "vcosmos1", "model" : "virtio" } ], "cpu_type" : "qemu64,+aes,+sse4.2,+sse4.1,+ssse3", "hpet" : "true", "usb_tablet" : "true", "disks" : [ { "index" : "0", "boot" : "true", "disk_path" : "main/vms/hosts/cosmos/disk0", "model" : "virtio" } ], "shutdown" : "acpi_kill", "boot_order" : "cd", "vcpus" : "sockets=1,cores=4,threads=2", "serials" : [ { "index" : "0", "serial_name" : "console" } ], "cleanup" : "true", "ram" : "6144", "time_base" : "utc" } } Which turns into: -(~)-[!]-{ pfexec pargs 616 }-(sjorge at core)- 616: /usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144 -cpu qemu64,+aes,+ argv[0]: /usr/bin/qemu-system-x86_64 argv[1]: -name argv[2]: cosmos argv[3]: -enable-kvm argv[4]: -m argv[5]: 6144 argv[6]: -cpu argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 argv[8]: -smp argv[9]: sockets=1,cores=4,threads=2 argv[10]: -rtc argv[11]: base=utc,driftfix=slew argv[12]: -pidfile argv[13]: /var/run/kvm/cosmos.pid argv[14]: -monitor argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay argv[16]: -vga argv[17]: none argv[18]: -nographic argv[19]: -drive argv[20]: file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on argv[21]: -boot argv[22]: order=cd argv[23]: -device argv[24]: virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=200000,x-txburst=128,vlan=10 argv[25]: -net argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0 argv[27]: -device argv[28]: virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 argv[29]: -net argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1 argv[31]: -chardev argv[32]: socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait argv[33]: -serial argv[34]: chardev:serial0 argv[35]: -usb argv[36]: -usbdevice argv[37]: tablet argv[38]: -daemonize PS: shout out to dan for introducing me to pgrep and pargs! Regards Jorge On 2015-04-06 19:22, Johan Kragsterman wrote: > Jorge, I thought you would jump in on this thread! > > Are you asking me or Michael? > > I'm not running ivy bridge on this machine, it's an older westmere... > > Yeah, I pass --cpu=host > > Can you provide your config file, pls? > > Mine is like this: > > > > > root at omni2:/usr/bin# cat vmedu14041.sh > #!/usr/bin/bash > > # on omnios command is /usr/bin/qemu-system-x86_64 > > # configuration > NAME="EDU14041" > NUM=4 > VNIC0=ltsp0 > VNIC1=ltsp1 > VNIC2=ltsptl0 > HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os > HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt > CD=/mainpool/iso/edu14041.iso > HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home > HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap > MEM=8192 > > # don't change below here! > > TLN=`expr 7000 + $NUM` > mac0=`dladm show-vnic -po macaddress $VNIC0` > mac1=`dladm show-vnic -po macaddress $VNIC1` > mac2=`dladm show-vnic -po macaddress $VNIC2` > > /usr/bin/qemu-system-x86_64 \ > -name $NAME \ > -boot cd \ > -enable-kvm \ > -vnc 0.0.0.0:$NUM \ > -smp cores=2,threads=2 \ > -m $MEM \ > -no-hpet \ > -localtime \ > -drive file=$HDD0,if=virtio,index=0 \ > -drive file=$HDD1,if=virtio,index=2 \ > -drive file=$CD,media=cdrom,if=ide,index=1 \ > -drive file=$HDD2,if=virtio,index=3 \ > -drive file=$HDD3,if=virtio,index=4 \ > -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ > -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ > -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ > -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ > -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ > -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ > > -vga std \ > -cpu host \ > -pidfile /mainpool/vm/edu/pids/$NAME.pid \ > -monitor telnet:localhost:$TLN,server,nowait,nodelay \ > -daemonize > > if [ $? -gt 0 ]; then > echo "Failed to start VM" > exit > fi > > port=`expr 5900 + $NUM` > public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') > public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') > > echo "Started VM: $NAME" > echo "VNC available at: host IP ${public_ip} port ${port}" > echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] > to exit monitor before quit! > " > > > Rgrds Johan > > > -----"OmniOS-discuss" skrev: > ----- > Till: Michael Rasmussen > Fr?n: Jorge Schrauwen > S?nt av: "OmniOS-discuss" > Datum: 2015-04-06 19:06 > Kopia: omnios-discuss at lists.omniti.com > ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash > > Out of curiosity, are you passing --cpu=host? I had issues with that on > my ivy bridge. > I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make > a lot of things smoother. > > I stil get these but qemu does not crash for me: > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > > > Regards > > Jorge > > > On 2015-04-06 18:03, Michael Rasmussen wrote: >> On Mon, 6 Apr 2015 11:55:27 -0400 >> Dan McDonald wrote: >> >>> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >>> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >>> erratum that can cause problems. ?That you do not seem to see these >>> in >>> r151012, however, is very odd. >>> >> There is also E3-12xx v2 which is Ivy Bridge based. Are these affected >> by this erratum as well? >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From johan.kragsterman at capvert.se Mon Apr 6 17:42:23 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 6 Apr 2015 19:42:23 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: , <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <, > <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: Thnks, Jorge! Yeah, I'm the one with the problems... So you're using kvmadm...? Is that from smartOS, huh? How did you manage to get it to work on OmniOS? Rgrds Johan -----Jorge Schrauwen skrev: ----- Till: Johan Kragsterman Fr?n: Jorge Schrauwen Datum: 2015-04-06 19:25 Kopia: Michael Rasmussen , omnios-discuss at lists.omniti.com ?rende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash Who ever is having the problem :) It was a bit hard to follow, I'm using kvmadm and this is my config: { ?? ?"cosmos" : { ?? ? ? "nics" : [ ?? ? ? ? ?{ ?? ? ? ? ? ? "index" : "0", ?? ? ? ? ? ? "nic_name" : "vcosmos0", ?? ? ? ? ? ? "model" : "virtio", ?? ? ? ? ? ? "vlan_id" : "10" ?? ? ? ? ?}, ?? ? ? ? ?{ ?? ? ? ? ? ? "index" : "1", ?? ? ? ? ? ? "nic_name" : "vcosmos1", ?? ? ? ? ? ? "model" : "virtio" ?? ? ? ? ?} ?? ? ? ], ?? ? ? "cpu_type" : "qemu64,+aes,+sse4.2,+sse4.1,+ssse3", ?? ? ? "hpet" : "true", ?? ? ? "usb_tablet" : "true", ?? ? ? "disks" : [ ?? ? ? ? ?{ ?? ? ? ? ? ? "index" : "0", ?? ? ? ? ? ? "boot" : "true", ?? ? ? ? ? ? "disk_path" : "main/vms/hosts/cosmos/disk0", ?? ? ? ? ? ? "model" : "virtio" ?? ? ? ? ?} ?? ? ? ], ?? ? ? "shutdown" : "acpi_kill", ?? ? ? "boot_order" : "cd", ?? ? ? "vcpus" : "sockets=1,cores=4,threads=2", ?? ? ? "serials" : [ ?? ? ? ? ?{ ?? ? ? ? ? ? "index" : "0", ?? ? ? ? ? ? "serial_name" : "console" ?? ? ? ? ?} ?? ? ? ], ?? ? ? "cleanup" : "true", ?? ? ? "ram" : "6144", ?? ? ? "time_base" : "utc" ?? ?} } Which turns into: -(~)-[!]-{ pfexec pargs 616 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }-(sjorge at core)- 616: ? ?/usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144 -cpu qemu64,+aes,+ argv[0]: /usr/bin/qemu-system-x86_64 argv[1]: -name argv[2]: cosmos argv[3]: -enable-kvm argv[4]: -m argv[5]: 6144 argv[6]: -cpu argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 argv[8]: -smp argv[9]: sockets=1,cores=4,threads=2 argv[10]: -rtc argv[11]: base=utc,driftfix=slew argv[12]: -pidfile argv[13]: /var/run/kvm/cosmos.pid argv[14]: -monitor argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay argv[16]: -vga argv[17]: none argv[18]: -nographic argv[19]: -drive argv[20]: file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on argv[21]: -boot argv[22]: order=cd argv[23]: -device argv[24]: virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=200000,x-txburst=128,vlan=10 argv[25]: -net argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0 argv[27]: -device argv[28]: virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 argv[29]: -net argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1 argv[31]: -chardev argv[32]: socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait argv[33]: -serial argv[34]: chardev:serial0 argv[35]: -usb argv[36]: -usbdevice argv[37]: tablet argv[38]: -daemonize PS: shout out to dan for introducing me to pgrep and pargs! Regards Jorge On 2015-04-06 19:22, Johan Kragsterman wrote: > Jorge, I thought you would jump in on this thread! > > Are you asking me or Michael? > > I'm not running ivy bridge on this machine, it's an older westmere... > > Yeah, I pass --cpu=host > > Can you provide your config file, pls? > > Mine is like this: > > > > > root at omni2:/usr/bin# cat vmedu14041.sh > #!/usr/bin/bash > > # on omnios command is /usr/bin/qemu-system-x86_64 > > # configuration > NAME="EDU14041" > NUM=4 > VNIC0=ltsp0 > VNIC1=ltsp1 > VNIC2=ltsptl0 > HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os > HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt > CD=/mainpool/iso/edu14041.iso > HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home > HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap > MEM=8192 > > # don't change below here! > > TLN=`expr 7000 + $NUM` > mac0=`dladm show-vnic -po macaddress $VNIC0` > mac1=`dladm show-vnic -po macaddress $VNIC1` > mac2=`dladm show-vnic -po macaddress $VNIC2` > > /usr/bin/qemu-system-x86_64 \ > -name $NAME \ > -boot cd \ > -enable-kvm \ > -vnc 0.0.0.0:$NUM \ > -smp cores=2,threads=2 \ > -m $MEM \ > -no-hpet \ > -localtime \ > -drive file=$HDD0,if=virtio,index=0 \ > -drive file=$HDD1,if=virtio,index=2 \ > -drive file=$CD,media=cdrom,if=ide,index=1 \ > -drive file=$HDD2,if=virtio,index=3 \ > -drive file=$HDD3,if=virtio,index=4 \ > -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ > -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ > -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ > -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ > -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ > -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ > > -vga std \ > -cpu host \ > -pidfile /mainpool/vm/edu/pids/$NAME.pid \ > -monitor telnet:localhost:$TLN,server,nowait,nodelay \ > -daemonize > > if [ $? -gt 0 ]; then > ? ? echo "Failed to start VM" > ? ? exit > fi > > port=`expr 5900 + $NUM` > public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') > public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') > > echo "Started VM: $NAME" > echo "VNC available at: host IP ${public_ip} port ${port}" > echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] > to exit monitor before quit! > " > > > Rgrds Johan > > > -----"OmniOS-discuss" skrev: > ----- > Till: Michael Rasmussen > Fr?n: Jorge Schrauwen > S?nt av: "OmniOS-discuss" > Datum: 2015-04-06 19:06 > Kopia: omnios-discuss at lists.omniti.com > ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash > > Out of curiosity, are you passing --cpu=host? I had issues with that on > my ivy bridge. > I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make > a lot of things smoother. > > I stil get these but qemu does not crash for me: > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] > kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 PRIx64 > base_address=fee00000 > Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs > revision_id = 10 > > > Regards > > Jorge > > > On 2015-04-06 18:03, Michael Rasmussen wrote: >> On Mon, 6 Apr 2015 11:55:27 -0400 >> Dan McDonald wrote: >> >>> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >>> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >>> erratum that can cause problems. ?That you do not seem to see these >>> in >>> r151012, however, is very odd. >>> >> There is also E3-12xx v2 which is Ivy Bridge based. Are these affected >> by this erratum as well? >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From sjorge+ml at blackdot.be Mon Apr 6 17:43:36 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 06 Apr 2015 19:43:36 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: , <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: Nope :) https://github.com/hadfl/kvmadm/ Regards Jorge On 2015-04-06 19:42, Johan Kragsterman wrote: > Thnks, Jorge! > > Yeah, I'm the one with the problems... > > So you're using kvmadm...? Is that from smartOS, huh? How did you > manage to get it to work on OmniOS? > > Rgrds Johan > > > -----Jorge Schrauwen skrev: ----- > Till: Johan Kragsterman > Fr?n: Jorge Schrauwen > Datum: 2015-04-06 19:25 > Kopia: Michael Rasmussen , > omnios-discuss at lists.omniti.com > ?rende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash > > Who ever is having the problem :) > It was a bit hard to follow, I'm using kvmadm and this is my config: > { > ?? ?"cosmos" : { > ?? ? ? "nics" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "nic_name" : "vcosmos0", > ?? ? ? ? ? ? "model" : "virtio", > ?? ? ? ? ? ? "vlan_id" : "10" > ?? ? ? ? ?}, > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "1", > ?? ? ? ? ? ? "nic_name" : "vcosmos1", > ?? ? ? ? ? ? "model" : "virtio" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "cpu_type" : "qemu64,+aes,+sse4.2,+sse4.1,+ssse3", > ?? ? ? "hpet" : "true", > ?? ? ? "usb_tablet" : "true", > ?? ? ? "disks" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "boot" : "true", > ?? ? ? ? ? ? "disk_path" : "main/vms/hosts/cosmos/disk0", > ?? ? ? ? ? ? "model" : "virtio" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "shutdown" : "acpi_kill", > ?? ? ? "boot_order" : "cd", > ?? ? ? "vcpus" : "sockets=1,cores=4,threads=2", > ?? ? ? "serials" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "serial_name" : "console" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "cleanup" : "true", > ?? ? ? "ram" : "6144", > ?? ? ? "time_base" : "utc" > ?? ?} > } > > > Which turns into: > -(~)-[!]-{ pfexec pargs 616 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > }-(sjorge at core)- > 616: ? ?/usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144 > -cpu qemu64,+aes,+ > argv[0]: /usr/bin/qemu-system-x86_64 > argv[1]: -name > argv[2]: cosmos > argv[3]: -enable-kvm > argv[4]: -m > argv[5]: 6144 > argv[6]: -cpu > argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 > argv[8]: -smp > argv[9]: sockets=1,cores=4,threads=2 > argv[10]: -rtc > argv[11]: base=utc,driftfix=slew > argv[12]: -pidfile > argv[13]: /var/run/kvm/cosmos.pid > argv[14]: -monitor > argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay > argv[16]: -vga > argv[17]: none > argv[18]: -nographic > argv[19]: -drive > argv[20]: > file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on > argv[21]: -boot > argv[22]: order=cd > argv[23]: -device > argv[24]: > virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=200000,x-txburst=128,vlan=10 > argv[25]: -net > argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0 > argv[27]: -device > argv[28]: > virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 > argv[29]: -net > argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1 > argv[31]: -chardev > argv[32]: > socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait > argv[33]: -serial > argv[34]: chardev:serial0 > argv[35]: -usb > argv[36]: -usbdevice > argv[37]: tablet > argv[38]: -daemonize > > PS: shout out to dan for introducing me to pgrep and pargs! > > Regards > > Jorge > > On 2015-04-06 19:22, Johan Kragsterman wrote: >> Jorge, I thought you would jump in on this thread! >> >> Are you asking me or Michael? >> >> I'm not running ivy bridge on this machine, it's an older westmere... >> >> Yeah, I pass --cpu=host >> >> Can you provide your config file, pls? >> >> Mine is like this: >> >> >> >> >> root at omni2:/usr/bin# cat vmedu14041.sh >> #!/usr/bin/bash >> >> # on omnios command is /usr/bin/qemu-system-x86_64 >> >> # configuration >> NAME="EDU14041" >> NUM=4 >> VNIC0=ltsp0 >> VNIC1=ltsp1 >> VNIC2=ltsptl0 >> HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os >> HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt >> CD=/mainpool/iso/edu14041.iso >> HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home >> HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap >> MEM=8192 >> >> # don't change below here! >> >> TLN=`expr 7000 + $NUM` >> mac0=`dladm show-vnic -po macaddress $VNIC0` >> mac1=`dladm show-vnic -po macaddress $VNIC1` >> mac2=`dladm show-vnic -po macaddress $VNIC2` >> >> /usr/bin/qemu-system-x86_64 \ >> -name $NAME \ >> -boot cd \ >> -enable-kvm \ >> -vnc 0.0.0.0:$NUM \ >> -smp cores=2,threads=2 \ >> -m $MEM \ >> -no-hpet \ >> -localtime \ >> -drive file=$HDD0,if=virtio,index=0 \ >> -drive file=$HDD1,if=virtio,index=2 \ >> -drive file=$CD,media=cdrom,if=ide,index=1 \ >> -drive file=$HDD2,if=virtio,index=3 \ >> -drive file=$HDD3,if=virtio,index=4 \ >> -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ >> -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ >> -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ >> -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ >> -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ >> -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ >> >> -vga std \ >> -cpu host \ >> -pidfile /mainpool/vm/edu/pids/$NAME.pid \ >> -monitor telnet:localhost:$TLN,server,nowait,nodelay \ >> -daemonize >> >> if [ $? -gt 0 ]; then >> ? ? echo "Failed to start VM" >> ? ? exit >> fi >> >> port=`expr 5900 + $NUM` >> public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') >> public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') >> >> echo "Started VM: $NAME" >> echo "VNC available at: host IP ${public_ip} port ${port}" >> echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] >> to exit monitor before quit! >> " >> >> >> Rgrds Johan >> >> >> -----"OmniOS-discuss" skrev: >> ----- >> Till: Michael Rasmussen >> Fr?n: Jorge Schrauwen >> S?nt av: "OmniOS-discuss" >> Datum: 2015-04-06 19:06 >> Kopia: omnios-discuss at lists.omniti.com >> ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash >> >> Out of curiosity, are you passing --cpu=host? I had issues with that >> on >> my ivy bridge. >> I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to >> make >> a lot of things smoother. >> >> I stil get these but qemu does not crash for me: >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> >> >> Regards >> >> Jorge >> >> >> On 2015-04-06 18:03, Michael Rasmussen wrote: >>> On Mon, 6 Apr 2015 11:55:27 -0400 >>> Dan McDonald wrote: >>> >>>> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >>>> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >>>> erratum that can cause problems. ?That you do not seem to see these >>>> in >>>> r151012, however, is very odd. >>>> >>> There is also E3-12xx v2 which is Ivy Bridge based. Are these >>> affected >>> by this erratum as well? >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From johan.kragsterman at capvert.se Mon Apr 6 17:50:50 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 6 Apr 2015 19:50:50 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: , , <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <, > <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: Ahh, that one! Thanks again! I'll have a look at it! Since you use it, I guess you find it useful? Any pro's and con's as you see it? Rgrds Johan -----Jorge Schrauwen skrev: ----- Till: Johan Kragsterman Fr?n: Jorge Schrauwen Datum: 2015-04-06 19:44 Kopia: Michael Rasmussen , omnios-discuss at lists.omniti.com ?rende: Re: Ang: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash Nope :) https://github.com/hadfl/kvmadm/ Regards Jorge On 2015-04-06 19:42, Johan Kragsterman wrote: > Thnks, Jorge! > > Yeah, I'm the one with the problems... > > So you're using kvmadm...? Is that from smartOS, huh? How did you > manage to get it to work on OmniOS? > > Rgrds Johan > > > -----Jorge Schrauwen skrev: ----- > Till: Johan Kragsterman > Fr?n: Jorge Schrauwen > Datum: 2015-04-06 19:25 > Kopia: Michael Rasmussen , > omnios-discuss at lists.omniti.com > ?rende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash > > Who ever is having the problem :) > It was a bit hard to follow, I'm using kvmadm and this is my config: > { > ?? ?"cosmos" : { > ?? ? ? "nics" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "nic_name" : "vcosmos0", > ?? ? ? ? ? ? "model" : "virtio", > ?? ? ? ? ? ? "vlan_id" : "10" > ?? ? ? ? ?}, > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "1", > ?? ? ? ? ? ? "nic_name" : "vcosmos1", > ?? ? ? ? ? ? "model" : "virtio" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "cpu_type" : "qemu64,+aes,+sse4.2,+sse4.1,+ssse3", > ?? ? ? "hpet" : "true", > ?? ? ? "usb_tablet" : "true", > ?? ? ? "disks" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "boot" : "true", > ?? ? ? ? ? ? "disk_path" : "main/vms/hosts/cosmos/disk0", > ?? ? ? ? ? ? "model" : "virtio" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "shutdown" : "acpi_kill", > ?? ? ? "boot_order" : "cd", > ?? ? ? "vcpus" : "sockets=1,cores=4,threads=2", > ?? ? ? "serials" : [ > ?? ? ? ? ?{ > ?? ? ? ? ? ? "index" : "0", > ?? ? ? ? ? ? "serial_name" : "console" > ?? ? ? ? ?} > ?? ? ? ], > ?? ? ? "cleanup" : "true", > ?? ? ? "ram" : "6144", > ?? ? ? "time_base" : "utc" > ?? ?} > } > > > Which turns into: > -(~)-[!]-{ pfexec pargs 616 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > }-(sjorge at core)- > 616: ? ?/usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144 > -cpu qemu64,+aes,+ > argv[0]: /usr/bin/qemu-system-x86_64 > argv[1]: -name > argv[2]: cosmos > argv[3]: -enable-kvm > argv[4]: -m > argv[5]: 6144 > argv[6]: -cpu > argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 > argv[8]: -smp > argv[9]: sockets=1,cores=4,threads=2 > argv[10]: -rtc > argv[11]: base=utc,driftfix=slew > argv[12]: -pidfile > argv[13]: /var/run/kvm/cosmos.pid > argv[14]: -monitor > argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay > argv[16]: -vga > argv[17]: none > argv[18]: -nographic > argv[19]: -drive > argv[20]: > file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on > argv[21]: -boot > argv[22]: order=cd > argv[23]: -device > argv[24]: > virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=200000,x-txburst=128,vlan=10 > argv[25]: -net > argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0 > argv[27]: -device > argv[28]: > virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 > argv[29]: -net > argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1 > argv[31]: -chardev > argv[32]: > socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait > argv[33]: -serial > argv[34]: chardev:serial0 > argv[35]: -usb > argv[36]: -usbdevice > argv[37]: tablet > argv[38]: -daemonize > > PS: shout out to dan for introducing me to pgrep and pargs! > > Regards > > Jorge > > On 2015-04-06 19:22, Johan Kragsterman wrote: >> Jorge, I thought you would jump in on this thread! >> >> Are you asking me or Michael? >> >> I'm not running ivy bridge on this machine, it's an older westmere... >> >> Yeah, I pass --cpu=host >> >> Can you provide your config file, pls? >> >> Mine is like this: >> >> >> >> >> root at omni2:/usr/bin# cat vmedu14041.sh >> #!/usr/bin/bash >> >> # on omnios command is /usr/bin/qemu-system-x86_64 >> >> # configuration >> NAME="EDU14041" >> NUM=4 >> VNIC0=ltsp0 >> VNIC1=ltsp1 >> VNIC2=ltsptl0 >> HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os >> HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt >> CD=/mainpool/iso/edu14041.iso >> HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home >> HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap >> MEM=8192 >> >> # don't change below here! >> >> TLN=`expr 7000 + $NUM` >> mac0=`dladm show-vnic -po macaddress $VNIC0` >> mac1=`dladm show-vnic -po macaddress $VNIC1` >> mac2=`dladm show-vnic -po macaddress $VNIC2` >> >> /usr/bin/qemu-system-x86_64 \ >> -name $NAME \ >> -boot cd \ >> -enable-kvm \ >> -vnc 0.0.0.0:$NUM \ >> -smp cores=2,threads=2 \ >> -m $MEM \ >> -no-hpet \ >> -localtime \ >> -drive file=$HDD0,if=virtio,index=0 \ >> -drive file=$HDD1,if=virtio,index=2 \ >> -drive file=$CD,media=cdrom,if=ide,index=1 \ >> -drive file=$HDD2,if=virtio,index=3 \ >> -drive file=$HDD3,if=virtio,index=4 \ >> -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ >> -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ >> -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ >> -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ >> -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ >> -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ >> >> -vga std \ >> -cpu host \ >> -pidfile /mainpool/vm/edu/pids/$NAME.pid \ >> -monitor telnet:localhost:$TLN,server,nowait,nodelay \ >> -daemonize >> >> if [ $? -gt 0 ]; then >> ? ? echo "Failed to start VM" >> ? ? exit >> fi >> >> port=`expr 5900 + $NUM` >> public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') >> public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') >> >> echo "Started VM: $NAME" >> echo "VNC available at: host IP ${public_ip} port ${port}" >> echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] >> to exit monitor before quit! >> " >> >> >> Rgrds Johan >> >> >> -----"OmniOS-discuss" skrev: >> ----- >> Till: Michael Rasmussen >> Fr?n: Jorge Schrauwen >> S?nt av: "OmniOS-discuss" >> Datum: 2015-04-06 19:06 >> Kopia: omnios-discuss at lists.omniti.com >> ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash >> >> Out of curiosity, are you passing --cpu=host? I had issues with that >> on >> my ivy bridge. >> I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to >> make >> a lot of things smoother. >> >> I stil get these but qemu does not crash for me: >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >> kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 >> PRIx64 >> base_address=fee00000 >> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >> revision_id = 10 >> >> >> Regards >> >> Jorge >> >> >> On 2015-04-06 18:03, Michael Rasmussen wrote: >>> On Mon, 6 Apr 2015 11:55:27 -0400 >>> Dan McDonald wrote: >>> >>>> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >>>> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >>>> erratum that can cause problems. ?That you do not seem to see these >>>> in >>>> r151012, however, is very odd. >>>> >>> There is also E3-12xx v2 which is Ivy Bridge based. Are these >>> affected >>> by this erratum as well? >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From sjorge+ml at blackdot.be Mon Apr 6 17:54:25 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 06 Apr 2015 19:54:25 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: , , <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be>, <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: <5fe099cdfd557d8b192f184bb66c220f@blackdot.be> Yep I find it useful. Cons, euhm none come to mind actually. The developer is pretty good with feedback and input so all the cons there were are now gone due to me excessive bug opening haha. Pros: - json structure for configuring vm's - No messing around with custom scripts and smf wrappers Regards Jorge On 2015-04-06 19:50, Johan Kragsterman wrote: > Ahh, that one! > > Thanks again! I'll have a look at it! Since you use it, I guess you > find it useful? > > Any pro's and con's as you see it? > > > Rgrds Johan > > > -----Jorge Schrauwen skrev: ----- > Till: Johan Kragsterman > Fr?n: Jorge Schrauwen > Datum: 2015-04-06 19:44 > Kopia: Michael Rasmussen , > omnios-discuss at lists.omniti.com > ?rende: Re: Ang: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM > crash > > Nope :) > https://github.com/hadfl/kvmadm/ > > Regards > > Jorge > > On 2015-04-06 19:42, Johan Kragsterman wrote: >> Thnks, Jorge! >> >> Yeah, I'm the one with the problems... >> >> So you're using kvmadm...? Is that from smartOS, huh? How did you >> manage to get it to work on OmniOS? >> >> Rgrds Johan >> >> >> -----Jorge Schrauwen skrev: ----- >> Till: Johan Kragsterman >> Fr?n: Jorge Schrauwen >> Datum: 2015-04-06 19:25 >> Kopia: Michael Rasmussen , >> omnios-discuss at lists.omniti.com >> ?rende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash >> >> Who ever is having the problem :) >> It was a bit hard to follow, I'm using kvmadm and this is my config: >> { >> ?? ?"cosmos" : { >> ?? ? ? "nics" : [ >> ?? ? ? ? ?{ >> ?? ? ? ? ? ? "index" : "0", >> ?? ? ? ? ? ? "nic_name" : "vcosmos0", >> ?? ? ? ? ? ? "model" : "virtio", >> ?? ? ? ? ? ? "vlan_id" : "10" >> ?? ? ? ? ?}, >> ?? ? ? ? ?{ >> ?? ? ? ? ? ? "index" : "1", >> ?? ? ? ? ? ? "nic_name" : "vcosmos1", >> ?? ? ? ? ? ? "model" : "virtio" >> ?? ? ? ? ?} >> ?? ? ? ], >> ?? ? ? "cpu_type" : "qemu64,+aes,+sse4.2,+sse4.1,+ssse3", >> ?? ? ? "hpet" : "true", >> ?? ? ? "usb_tablet" : "true", >> ?? ? ? "disks" : [ >> ?? ? ? ? ?{ >> ?? ? ? ? ? ? "index" : "0", >> ?? ? ? ? ? ? "boot" : "true", >> ?? ? ? ? ? ? "disk_path" : "main/vms/hosts/cosmos/disk0", >> ?? ? ? ? ? ? "model" : "virtio" >> ?? ? ? ? ?} >> ?? ? ? ], >> ?? ? ? "shutdown" : "acpi_kill", >> ?? ? ? "boot_order" : "cd", >> ?? ? ? "vcpus" : "sockets=1,cores=4,threads=2", >> ?? ? ? "serials" : [ >> ?? ? ? ? ?{ >> ?? ? ? ? ? ? "index" : "0", >> ?? ? ? ? ? ? "serial_name" : "console" >> ?? ? ? ? ?} >> ?? ? ? ], >> ?? ? ? "cleanup" : "true", >> ?? ? ? "ram" : "6144", >> ?? ? ? "time_base" : "utc" >> ?? ?} >> } >> >> >> Which turns into: >> -(~)-[!]-{ pfexec pargs 616 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >> }-(sjorge at core)- >> 616: ? ?/usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144 >> -cpu qemu64,+aes,+ >> argv[0]: /usr/bin/qemu-system-x86_64 >> argv[1]: -name >> argv[2]: cosmos >> argv[3]: -enable-kvm >> argv[4]: -m >> argv[5]: 6144 >> argv[6]: -cpu >> argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 >> argv[8]: -smp >> argv[9]: sockets=1,cores=4,threads=2 >> argv[10]: -rtc >> argv[11]: base=utc,driftfix=slew >> argv[12]: -pidfile >> argv[13]: /var/run/kvm/cosmos.pid >> argv[14]: -monitor >> argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay >> argv[16]: -vga >> argv[17]: none >> argv[18]: -nographic >> argv[19]: -drive >> argv[20]: >> file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on >> argv[21]: -boot >> argv[22]: order=cd >> argv[23]: -device >> argv[24]: >> virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=200000,x-txburst=128,vlan=10 >> argv[25]: -net >> argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0 >> argv[27]: -device >> argv[28]: >> virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 >> argv[29]: -net >> argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1 >> argv[31]: -chardev >> argv[32]: >> socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait >> argv[33]: -serial >> argv[34]: chardev:serial0 >> argv[35]: -usb >> argv[36]: -usbdevice >> argv[37]: tablet >> argv[38]: -daemonize >> >> PS: shout out to dan for introducing me to pgrep and pargs! >> >> Regards >> >> Jorge >> >> On 2015-04-06 19:22, Johan Kragsterman wrote: >>> Jorge, I thought you would jump in on this thread! >>> >>> Are you asking me or Michael? >>> >>> I'm not running ivy bridge on this machine, it's an older westmere... >>> >>> Yeah, I pass --cpu=host >>> >>> Can you provide your config file, pls? >>> >>> Mine is like this: >>> >>> >>> >>> >>> root at omni2:/usr/bin# cat vmedu14041.sh >>> #!/usr/bin/bash >>> >>> # on omnios command is /usr/bin/qemu-system-x86_64 >>> >>> # configuration >>> NAME="EDU14041" >>> NUM=4 >>> VNIC0=ltsp0 >>> VNIC1=ltsp1 >>> VNIC2=ltsptl0 >>> HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os >>> HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt >>> CD=/mainpool/iso/edu14041.iso >>> HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home >>> HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap >>> MEM=8192 >>> >>> # don't change below here! >>> >>> TLN=`expr 7000 + $NUM` >>> mac0=`dladm show-vnic -po macaddress $VNIC0` >>> mac1=`dladm show-vnic -po macaddress $VNIC1` >>> mac2=`dladm show-vnic -po macaddress $VNIC2` >>> >>> /usr/bin/qemu-system-x86_64 \ >>> -name $NAME \ >>> -boot cd \ >>> -enable-kvm \ >>> -vnc 0.0.0.0:$NUM \ >>> -smp cores=2,threads=2 \ >>> -m $MEM \ >>> -no-hpet \ >>> -localtime \ >>> -drive file=$HDD0,if=virtio,index=0 \ >>> -drive file=$HDD1,if=virtio,index=2 \ >>> -drive file=$CD,media=cdrom,if=ide,index=1 \ >>> -drive file=$HDD2,if=virtio,index=3 \ >>> -drive file=$HDD3,if=virtio,index=4 \ >>> -net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \ >>> -net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \ >>> -net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \ >>> -net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \ >>> -net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \ >>> -net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \ >>> >>> -vga std \ >>> -cpu host \ >>> -pidfile /mainpool/vm/edu/pids/$NAME.pid \ >>> -monitor telnet:localhost:$TLN,server,nowait,nodelay \ >>> -daemonize >>> >>> if [ $? -gt 0 ]; then >>> ? ? echo "Failed to start VM" >>> ? ? exit >>> fi >>> >>> port=`expr 5900 + $NUM` >>> public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}') >>> public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') >>> >>> echo "Started VM: $NAME" >>> echo "VNC available at: host IP ${public_ip} port ${port}" >>> echo "QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] >>> to exit monitor before quit! >>> " >>> >>> >>> Rgrds Johan >>> >>> >>> -----"OmniOS-discuss" >>> skrev: >>> ----- >>> Till: Michael Rasmussen >>> Fr?n: Jorge Schrauwen >>> S?nt av: "OmniOS-discuss" >>> Datum: 2015-04-06 19:06 >>> Kopia: omnios-discuss at lists.omniti.com >>> ?rende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash >>> >>> Out of curiosity, are you passing --cpu=host? I had issues with that >>> on >>> my ivy bridge. >>> I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to >>> make >>> a lot of things smoother. >>> >>> I stil get these but qemu does not crash for me: >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff21ff94c000, id=0, base_msr= fee00100 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff21ff944000, id=1, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff21ff93c000, id=2, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff2201f14000, id=3, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff2201f0c000, id=4, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff2201f04000, id=5, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff2201efc000, id=6, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] >>> kvm_lapic_reset: vcpu=ffffff2201f54000, id=7, base_msr= fee00000 >>> PRIx64 >>> base_address=fee00000 >>> Apr ?1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs >>> revision_id = 10 >>> >>> >>> Regards >>> >>> Jorge >>> >>> >>> On 2015-04-06 18:03, Michael Rasmussen wrote: >>>> On Mon, 6 Apr 2015 11:55:27 -0400 >>>> Dan McDonald wrote: >>>> >>>>> I'm talking with the illumos KVM folks. ?They mentioned that Ivy >>>>> Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have >>>>> erratum that can cause problems. ?That you do not seem to see these >>>>> in >>>>> r151012, however, is very odd. >>>>> >>>> There is also E3-12xx v2 which is Ivy Bridge based. Are these >>>> affected >>>> by this erratum as well? >>>> >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> OmniOS-discuss at lists.omniti.com >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss From mir at miras.org Mon Apr 6 17:55:56 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 19:55:56 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: References: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be> <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> Message-ID: <20150406195556.3ca88208@sleipner.datanom.net> On Mon, 6 Apr 2015 19:22:08 +0200 Johan Kragsterman wrote: > -smp cores=2,threads=2 \ I would use: cores=1,threads=4 instead since smp tense to give problems if VM OS is having problems with smp. 99% of the time cores=1,threads=x performs smoother and better than cores=x,threads=y and without proper numa implementation using cores > 1 does not add anything to the picture. smp is first interesting in qemu-2.2 when numa is introduced. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: You work very hard. Don't try to think as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sjorge+ml at blackdot.be Mon Apr 6 17:56:36 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 06 Apr 2015 19:56:36 +0200 Subject: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash In-Reply-To: <20150406195556.3ca88208@sleipner.datanom.net> References: <683fcc9c6bc1bc4daa52e2d061f54664@blackdot.be> <577A1B47-7D9B-4F44-8C08-B761B056F172@omniti.com> <,> <40C8FD28-5F60-42AA-8B1F-A26271A8B683@omniti.com> <20150406180300.41cd70d5@sleipner.datanom.net> <20150406195556.3ca88208@sleipner.datanom.net> Message-ID: <6aad8098862bac6bc7a0715fbb082dc2@blackdot.be> On 2015-04-06 19:55, Michael Rasmussen wrote: > On Mon, 6 Apr 2015 19:22:08 +0200 > Johan Kragsterman wrote: > >> -smp cores=2,threads=2 \ > I would use: > cores=1,threads=4 Notable exception is for illumos, it barfs on that and dies. But yeah for other OS's that valid advice. > > instead since smp tense to give problems if VM OS is having problems > with smp. 99% of the time cores=1,threads=x performs smoother and > better than cores=x,threads=y and without proper numa implementation > using cores > 1 does not add anything to the picture. > > smp is first interesting in qemu-2.2 when numa is introduced. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From mir at miras.org Mon Apr 6 18:04:46 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 20:04:46 +0200 Subject: [OmniOS-discuss] New MB In-Reply-To: References: <20150404175743.6b504b61@sleipner.datanom.net> Message-ID: <20150406200446.6a7b7651@sleipner.datanom.net> On Mon, 6 Apr 2015 13:23:28 -0400 Eric Sproul wrote: > > Modulo actually being able to mount the weird form-factor in a > standard case (note that you need enough of the mounting holes to line > up, not just that the dimensions fit!), I would expect OmniOS to work. > This is my biggest concern since drilling hules in motherboards is not for the faint of heart;-) I think before making the final decision I will make an inquiry to the local Supermicro dealer. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: A classic is something that everyone wants to have read and nobody wants to read. -- Mark Twain, "The Disappearance of Literature" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From eric.sproul at circonus.com Mon Apr 6 18:16:38 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 6 Apr 2015 14:16:38 -0400 Subject: [OmniOS-discuss] New MB In-Reply-To: <20150406200446.6a7b7651@sleipner.datanom.net> References: <20150404175743.6b504b61@sleipner.datanom.net> <20150406200446.6a7b7651@sleipner.datanom.net> Message-ID: On Mon, Apr 6, 2015 at 2:04 PM, Michael Rasmussen wrote: > On Mon, 6 Apr 2015 13:23:28 -0400 > Eric Sproul wrote: > >> >> Modulo actually being able to mount the weird form-factor in a >> standard case (note that you need enough of the mounting holes to line >> up, not just that the dimensions fit!), I would expect OmniOS to work. >> > This is my biggest concern since drilling hules in motherboards is not > for the faint of heart;-) > > I think before making the final decision I will make an inquiry to the > local Supermicro dealer. The manual for that board "strongly suggests" that users only employ this board as part of the full system 5018A-AR12L http://www.supermicro.com/products/system/1U/5018/SSG-5018A-AR12L.cfm That should tell you something. ;) From vab at bb-c.de Mon Apr 6 18:26:08 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 6 Apr 2015 20:26:08 +0200 Subject: [OmniOS-discuss] IPS "group/feature" packages in 014: What to do with them? Message-ID: <21794.53184.12510.748143@glaurung.bb-c.de> Hi Dan! [I guess you don't receive my mails so I am CC'ing the list.] I see that you have included some "feature" IPS packages in 014: # pkg list -avf group/feature/\* FMRI IFO pkg://omnios/group/feature/amp at 0.5.11-0.151014:20150402T184306Z --- pkg://omnios/group/feature/developer-gnu at 0.5.11-0.151014:20150402T184306Z --- pkg://omnios/group/feature/multi-user-desktop at 0.5.11-0.151014:20150402T184307Z --- But they are obviously not in synch with the rest of the packages in the 014 repo. (There will not be a "multi-user-desktop" feature soon, I'd wager ;-). But some of them could be useful. Take "feature/developer-gnu". It would be nice to just install it and have a working environment with the "Gnu tools". However, it's just an upstream copy which does not map well to the OmniOS versions of the various packages: # pkg contents -rt depend -Ho fmri group/feature/developer-gnu developer/build/autoconf developer/build/automake-110 developer/build/automake-111 developer/build/automake-19 developer/build/gnu-make developer/build/libtool developer/build/make developer/debug/gdb developer/gcc-47 developer/gnu-binutils developer/lexer/flex developer/macro/gnu-m4 developer/parser/bison developer/versioning/cvs developer/versioning/git developer/versioning/mercurial developer/versioning/subversion system/header system/library/gcc-4-runtime Most of these packages do exist in the 014 repo but some have slightly different names and/or versions. An easy fix would be to just change the depends to developer/build/autoconf developer/build/automake developer/build/gnu-make developer/build/libtool developer/build/make developer/gcc48 developer/gnu-binutils developer/lexer/flex developer/macro/gnu-m4 developer/parser/bison developer/versioning/git developer/versioning/mercurial developer/versioning/subversion system/header system/library/gcc-4-runtime Missing are gdb, cvs, and subversion, if we don't include the pkgs on ms.omniti.com. Maybe gdb and SVN could even be brought over into 014 proper. :-) A similar change could be done for "group/feature/amp". So what are your plans with feature pkgs? Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From mir at miras.org Mon Apr 6 18:42:06 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 6 Apr 2015 20:42:06 +0200 Subject: [OmniOS-discuss] New MB In-Reply-To: References: <20150404175743.6b504b61@sleipner.datanom.net> <20150406200446.6a7b7651@sleipner.datanom.net> Message-ID: <20150406204206.5cddc010@sleipner.datanom.net> On Mon, 6 Apr 2015 14:16:38 -0400 Eric Sproul wrote: > > The manual for that board "strongly suggests" that users only employ > this board as part of the full system 5018A-AR12L > > http://www.supermicro.com/products/system/1U/5018/SSG-5018A-AR12L.cfm > > That should tell you something. ;) I know. Anyways, the inquiry has been send to support and when I receive an answer I will report back to the list. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: If in doubt, mumble. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From nsmith at careyweb.com Mon Apr 6 18:45:41 2015 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 06 Apr 2015 14:45:41 -0400 Subject: [OmniOS-discuss] =?utf-8?q?Best_infrastructure_for_VSphere/Hyper-?= =?utf-8?q?V?= Message-ID: <57413703-4516@mail.careyweb.com> Update: I disabled cstates and mwaits and that fixed the crashes i was getting when,the system was slow. But I still got the qlogic target dropouts during certain ios.after lots of research, I guessed that I was having a queuing problem. To alleviate that I did a couple things: 1. Reconfigured all my host and target views so that each host port only saw one target port. Formerly I had all four of my target ports mapped to both initiators on each host. This led to a situation where i had eight mpio paths on each host. 2. Assuming an incoming queue depth of 256 (right?) for each fibre target port, a round robin mpio infrastructure was bound to flood the target ports. Some documentation on qlogic indicated the default per lun outgoing queue depth was 32. After some calculations I dropped this to 16. As of now, each host only has two mpio paths in round robin with an outgoing queue depth of 16. I tried to test it under io load and was unable to get it to drop out in scenarios that would cause qlt to drop out in the past. (Multiple io operations while running a backup and destroying a hyperv checkpoint, etc.) system appears stable. So far. Thanks for the help everyone. Will update. -Nate From nsmith at careyweb.com Mon Apr 6 18:48:16 2015 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 06 Apr 2015 14:48:16 -0400 Subject: [OmniOS-discuss] =?utf-8?q?Best_infrastructure_for_VSphere/Hyper-?= =?utf-8?q?V?= Message-ID: <57569703-2316@mail.careyweb.com> From nsmith at careyweb.com Mon Apr 6 18:55:23 2015 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 06 Apr 2015 14:55:23 -0400 Subject: [OmniOS-discuss] =?utf-8?q?Best_infrastructure_for_VSphere/Hyper-?= =?utf-8?q?V?= Message-ID: <57995734-3928@mail.careyweb.com> Sorry. Screwed up the first time I tried to post. Here's the actual message: Update: I disabled cstates and mwaits in bios and that fixed the crashes i was getting when,the system was slow. But I still got the qlogic target dropouts during certain ios.after lots of research, I guessed that I was having a queuing problem.? To alleviate that I did a couple things:? 1. Reconfigured all my host and target views so that each host port only saw one target port. Formerly I had all four of my target ports mapped to both initiators on each host. This led to a situation where i had up to eight mpio paths on each lun on each host.? 2. Assuming an incoming queue depth of 256 (right?) for each fibre target port, a round robin mpio infrastructure was bound to flood the target ports. Some documentation on qlogic indicated the default per lun outgoing queue depth was 32. After some calculations I dropped this to 16.? As of now, each host lun only has two mpio paths in round robin with an outgoing queue depth of 16. I tried to test it under io load and was unable to get it to drop out in scenarios that would cause qlt to drop out in the past. (Multiple io operations while running a backup and destroying a hyperv checkpoint, etc.) system appears stable. So far. Thanks for the help everyone. Will update.? -Nate From danmcd at omniti.com Mon Apr 6 19:00:29 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 15:00:29 -0400 Subject: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V In-Reply-To: <57413703-4516@mail.careyweb.com> References: <57413703-4516@mail.careyweb.com> Message-ID: <1BA5BE7A-5BEF-4882-8A85-0EAC713E2C80@omniti.com> Pardon the top post. This is great work, THANK YOU for documenting your trials. If you've a blog, you should blog about it when all is said and done. Dan > On Apr 6, 2015, at 2:45 PM, Nate Smith wrote: > > Update: I disabled cstates and mwaits and that fixed the crashes i was getting when,the system was slow. But I still got the qlogic target dropouts during certain ios.after lots of research, I guessed that I was having a queuing problem. > > To alleviate that I did a couple things: > > 1. Reconfigured all my host and target views so that each host port only saw one target port. Formerly I had all four of my target ports mapped to both initiators on each host. This led to a situation where i had eight mpio paths on each host. > > 2. Assuming an incoming queue depth of 256 (right?) for each fibre target port, a round robin mpio infrastructure was bound to flood the target ports. Some documentation on qlogic indicated the default per lun outgoing queue depth was 32. After some calculations I dropped this to 16. > > As of now, each host only has two mpio paths in round robin with an outgoing queue depth of 16. I tried to test it under io load and was unable to get it to drop out in scenarios that would cause qlt to drop out in the past. (Multiple io operations while running a backup and destroying a hyperv checkpoint, etc.) system appears stable. So far. Thanks for the help everyone. Will update. > -Nate From eric.sproul at circonus.com Mon Apr 6 19:31:58 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 6 Apr 2015 15:31:58 -0400 Subject: [OmniOS-discuss] OmniOS r151014 is now out! In-Reply-To: <21790.40910.761210.766294@glaurung.bb-c.de> References: <15320A42-44DD-4800-B615-46BD6AA50EBC@omniti.com> <21790.40910.761210.766294@glaurung.bb-c.de> Message-ID: On Fri, Apr 3, 2015 at 10:12 AM, Volker A. Brandt wrote: > One info item for those of you who upgraded right away (like me :-). > If you have IPS pkg servers running on your system, they will be in > maintenance mode after you reboot into your new 151014 BE. > > You need to manually "refresh" and "clear" your server instances: > > # svcadm refresh svc:/application/pkg/server: > # svcadm clear svc:/application/pkg/server: > > This is because the name of the start method has changed in the > manifest (from "svc-pkg-depot" to "svc-pkg-server"). Thank you Volker, for pointing this out. I've added this info to http://omnios.omniti.com/wiki.php/Upgrade_to_r151014#Post-Upgrade Much appreciated! Eric From cks at cs.toronto.edu Mon Apr 6 19:38:27 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 06 Apr 2015 15:38:27 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade Message-ID: <20150406193827.CD8B37A07BD@apps0.cs.toronto.edu> I just tried a test upgrade of a (VMWare) virtual machine from r151010 to r151014 and got an internal Python error in pkg(5). The machine is freshly installed with the latest r151010 package sets and our internal customizations, which include additional packages from both http://pkg.omniti.com/omniti-ms/ and pkgsrc packages from http://pkgsrc.joyent.com/. (This is how our existing OmniOS r151010 machines are installed, so I wanted an exact duplicate of them to test the upgrade for obvious reasons.) Upgrade steps I did, taken basically intact from http://omnios.omniti.com/wiki.php/Upgrade_to_r151014: - make a snapshot of the current r151010 boot environment, just in case - update publisher: /usr/bin/pkg unset-publisher omnios /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g http://pkg.omniti.com/omnios/r151014/ omnios - try initial upgrade, which complained: /usr/bin/pkg update --be-name=omnios-cslab-r151014 entire at 11,5.11-0.151014 Creating Plan | pkg update: No matching version of entire can be installed: Reject: pkg://omnios/entire at 11,5.11-0.151014:20150402T192159Z Reason: This version is excluded by installed incorporation pkg://ms.omniti.com/omniti/system/storage/smartmontools at 6.2,5.11-0.151010:20140523T190549Z - remove the smartmontools package for now: pkg uninstall smartmontools - rerun the identical 'pkg update' command, which died: # /usr/bin/pkg update --be-name=omnios-cslab-r151014 entire at 11,5.11-0.151014 Packages to remove: 1 Packages to install: 8 Packages to update: 395 Mediators to change: 1 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) Completed 404/404 16625/16625 454.3/454.3 PHASE ACTIONS Removal Phase 4230/4230 Install Phase 5392/5392 Update Phase 3141/16901Action upgrade failed for 'opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py' (pkg://omnios/developer/gcc48): TypeError: 'NoneType' object is not callable The running system has not been modified. Modifications were only made to a clone of the running system. This clone is mounted at /tmp/tmp_nIZ1J should you wish to inspect it. pkg: An unexpected error happened during update: 'NoneType' object is not callable Traceback (most recent call last): File "/usr/bin/pkg", line 5954, in handle_errors __ret = func(*args, **kwargs) File "/usr/bin/pkg", line 5937, in main_func pargs=pargs, **opts) File "/usr/bin/pkg", line 2323, in update reject_list=reject_pats, update_index=update_index) File "/usr/bin/pkg", line 1583, in __api_op ret_code = __api_execute_plan(_op, _api_inst) File "/usr/bin/pkg", line 1269, in __api_execute_plan api_inst.execute_plan() File "/usr/lib/python2.6/vendor-packages/pkg/client/api.py", line 2156, in execute_plan self._img.imageplan.execute() File "/usr/lib/python2.6/vendor-packages/pkg/client/imageplan.py", line 2963, in execute p.execute_update(src, dest) File "/usr/lib/python2.6/vendor-packages/pkg/client/pkgplan.py", line 441, in execute_update dest.install(self, src) File "/usr/lib/python2.6/vendor-packages/pkg/actions/file.py", line 193, in install stream = self.data() TypeError: 'NoneType' object is not callable pkg: This is an internal error in pkg(5) version 1382373239. Please log a Service Request about this issue including the information above and this message. ---- I have this virtual machine still running at the moment so I can poke around inside the mounted clone for people. Although I haven't tested yet for obvious reasons, I also have a virtual-disk snapshot from before I started my test so I expect this is going to be fully reproducable. If people want I can make our customization scripts available so people can see exactly what we do to our poor OmniOS r151010 systems. (Some of the bits are probably slightly gory and improper.) - cks From danmcd at omniti.com Mon Apr 6 20:01:42 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 16:01:42 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150406193827.CD8B37A07BD@apps0.cs.toronto.edu> References: <20150406193827.CD8B37A07BD@apps0.cs.toronto.edu> Message-ID: <90649030-A9A6-4125-8B52-7CC54B51303F@omniti.com> We've had one other person complain about update problems, and his was a false-positive hit on an anti-virus middlebox. You don't have such beasts in your network, do you? > On Apr 6, 2015, at 3:38 PM, Chris Siebenmann wrote: > Update Phase 3141/16901Action upgrade failed for 'opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py' (pkg://omnios/developer/gcc48): > TypeError: 'NoneType' object is not callable It's like you got an empty file for this one. My 014 box does have it: -bash-4.3$ pkg list -v gcc48 FMRI IFO pkg://omnios/developer/gcc48 at 4.8.1-0.151014:20150402T205830Z i-- -bash-4.3$ pkg contents gcc48 | grep /libstdc++.so.6.0.18-gdb.py opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py opt/gcc-4.8.1/lib/libstdc++.so.6.0.18-gdb.py -bash-4.3$ But that just means I got it the time I tried it. > File "/usr/lib/python2.6/vendor-packages/pkg/client/pkgplan.py", line 441, in execute_update > dest.install(self, src) > File "/usr/lib/python2.6/vendor-packages/pkg/actions/file.py", line 193, in install > stream = self.data() That's with the old file.py, BTW. It's barfing because self.data() is being hinky. > I have this virtual machine still running at the moment so I can poke > around inside the mounted clone for people. Although I haven't tested > yet for obvious reasons, I also have a virtual-disk snapshot from before > I started my test so I expect this is going to be fully reproducable. > > If people want I can make our customization scripts available so people > can see exactly what we do to our poor OmniOS r151010 systems. (Some of > the bits are probably slightly gory and improper.) I doubt your "improper" behavior changes the version of python the pkg(5) system uses, but if it does, that's one other possibility. Dan From vab at bb-c.de Mon Apr 6 20:13:37 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 6 Apr 2015 22:13:37 +0200 Subject: [OmniOS-discuss] 014 NGZ: beadm problems Message-ID: <21794.59633.431298.345374@glaurung.bb-c.de> Hello all! I have a strange problem with using beadm in NGZs on a freshly installed 014 box. I have created the following zone: GZ# zonecfg -z omnit1 info zonename: omnit1 zonepath: /zones/omnit1 brand: lipkg autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: fs-allowed: net: address: 192.168.99.21/24 allowed-address not specified physical: zone0 defrouter: 192.168.99.254 attr: name: comment type: string value: "OmniOS Test Zone 1" The zone works fine. However, when I look at the current BEs inside the NGZ I get this: omnit1# beadm list BE Active Mountpoint Space Policy Created zbe xNb2015-04-06 18:35 / 510M static 2015-04-06 18:35 Note the strange output format. A verbose listing does display the dataset properly, but fails with an error message: omnit1# beadm list -av be_zone_get_parent_uuid: failed to parse parentuuid be_zone_compare_uuids: failed to get parentbe uuid from the given BE BE/Dataset/Snapshot Active Mountpoint Space Policy Created zbe rpool/zones/omnit1/ROOT/zbe NR / 510M static 2015-04-06 18:35 On a NGZ running on another 014 box that was updated from 012, and the NGZ was converted from the ipkg to the lipkg brand, beadm works just fine: otherzone# beadm list BE Active Mountpoint Space Policy Created zbe NR / 3.78G static 2015-03-29 20:17 otherzone# beadm list -av BE/Dataset/Snapshot Active Mountpoint Space Policy Created zbe rpool/zones/kayak/ROOT/zbe NR / 3.06G static 2015-03-29 20:17 What's worse, creating a new BE produces the same error: omnit1# beadm create -va zbe-test1 be_zone_get_parent_uuid: failed to parse parentuuid be_zone_compare_uuids: failed to get parentbe uuid from the given BE be_create_snapshot: creating snapshot for the zone root dataset from non-active global BE is not supported be_copy: failed to create auto named snapshot Unable to create zbe-test1. Operation not supported. For completeness, here is the BE list for the GZ: GZ# beadm list -av BE/Dataset/Snapshot Active Mountpoint Space Policy Created omnios rpool/ROOT/omnios NR / 999M static 2015-04-05 20:56 To make a long story short, testing on another zone with the "ipkg" as opposed to the "lipkg" brand produces the same result. The only relevant bug I could find is #3845 but that is marked resolved: https://www.illumos.org/issues/3845 What am I doing wrong? How could I tackle this? I have checked the obvious, i.e. a missing libuuid, but it is there and gets pulled in properly. Thanks for any pointers! Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From cks at cs.toronto.edu Mon Apr 6 20:31:17 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 06 Apr 2015 16:31:17 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: danmcd's message of Mon, 06 Apr 2015 16:01:42 -0400. <90649030-A9A6-4125-8B52-7CC54B51303F@omniti.com> Message-ID: <20150406203117.632677A093C@apps0.cs.toronto.edu> > We've had one other person complain about update problems, and his was > a false-positive hit on an anti-virus middlebox. > > You don't have such beasts in your network, do you? We don't. I'm confident that my test machine is pulling things directly from the repos. > > Update Phase 3141/16901Action upgrade failed for 'opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py' (pkg://omnios/developer/gcc48): > > TypeError: 'NoneType' object is not callable > > It's like you got an empty file for this one. Looking at the Python code a bit, this seems to specifically be that self.data is None, which seems to happen if the FileAction object is initialized without a data argument and then nothing gets set up for it later. > > If people want I can make our customization scripts available > > so people can see exactly what we do to our poor OmniOS r151010 > > systems. (Some of the bits are probably slightly gory and improper.) > > I doubt your "improper" behavior changes the version of python the > pkg(5) system uses, but if it does, that's one other possibility. /usr/bin/pkg specifies /usr/bin/python2.6, which as far as I know is unaltered by our install stuff. It certainly should be standard; we don't even install alternate Python versions from eg pkgsrc. - cks From danmcd at omniti.com Mon Apr 6 20:59:50 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 16:59:50 -0400 Subject: [OmniOS-discuss] 014 NGZ: beadm problems In-Reply-To: <21794.59633.431298.345374@glaurung.bb-c.de> References: <21794.59633.431298.345374@glaurung.bb-c.de> Message-ID: <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> On Apr 6, 2015, at 4:13 PM, Volker A. Brandt wrote: > > The zone works fine. However, when I look at the current BEs inside the NGZ I > get this: > > omnit1# beadm list > BE Active Mountpoint Space Policy Created > zbe xNb2015-04-06 18:35 / 510M static 2015-04-06 18:35 Yeah, that's very odd. I just created a zone on one of my 014 vms, and didn't see your problem. I *did* have an old zone from 012 previously on that particular one. So I tried again on one I'm pretty sure never saw a zone prior to a fresh-from-ISO-or-kayak installation. No problems there either. > To make a long story short, testing on another zone with the "ipkg" as opposed > to the "lipkg" brand produces the same result. > > The only relevant bug I could find is #3845 but that is marked resolved: > > https://www.illumos.org/issues/3845 > > What am I doing wrong? How could I tackle this? I have checked the obvious, > i.e. a missing libuuid, but it is there and gets pulled in properly. I'm honestly not sure what you're doing wrong. I noticed only one difference just now, but that really shouldn't matter: I use exclusive-stack zones... exclusively. You used shared-stack. I can't believe that'd make a difference... ... and it didn't. It's working for me. I'll try a fresh install on this VM, just to make sure it's all good. Thanks, Dan From vab at bb-c.de Mon Apr 6 21:22:21 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 6 Apr 2015 23:22:21 +0200 Subject: [OmniOS-discuss] 014 NGZ: beadm problems In-Reply-To: <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> References: <21794.59633.431298.345374@glaurung.bb-c.de> <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> Message-ID: <21794.63757.279415.386282@glaurung.bb-c.de> Dan McDonald writes: > I noticed only one difference just now, but that really shouldn't > matter: I use exclusive-stack zones... exclusively. You used > shared-stack. I can't believe that'd make a difference... > > ... and it didn't. It's working for me. > > I'll try a fresh install on this VM, just to make sure it's all > good. Just to cross-check, I'll try an ip-type=exclusive zone... tomorrow. :-) Thanks for looking into this. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Mon Apr 6 21:23:17 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 17:23:17 -0400 Subject: [OmniOS-discuss] 014 NGZ: beadm problems In-Reply-To: <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> References: <21794.59633.431298.345374@glaurung.bb-c.de> <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> Message-ID: <046B7DC4-26E4-450F-AF99-754608F0070D@omniti.com> > On Apr 6, 2015, at 4:59 PM, Dan McDonald wrote: > > I'll try a fresh install on this VM, just to make sure it's all good. I couldn't reproduce your bug installing my VM from the r151014 ISO. I got this upon zone login (exclusive-stack, though): root at danmcd-ob:/root# zlogin -C tz2 [Connected to zone 'tz2' console] 111/111 Hostname: tz2 tz2 console login: root Password: Apr 6 21:16:01 tz2 login: Solaris_audit getaddrinfo(tz2) failed[node name or service name not known]: Error 0 Apr 6 21:16:01 tz2 login: Solaris_audit adt_get_local_address failed, no Audit IP address available, faking loopback and error: Network is down Apr 6 21:16:01 tz2 login: pam_unix_cred: cannot load ttyname: Network is down, continuing. Apr 6 21:16:01 tz2 login: ROOT LOGIN /dev/console OmniOS 5.11 omnios-a708424 April 2015 root at tz2:/root# beadm list BE Active Mountpoint Space Policy Created zbe NR / 1.04G static 2015-04-06 21:12 root at tz2:/root# beadm create zbe-69 Created successfully root at tz2:/root# beadm list BE Active Mountpoint Space Policy Created zbe NR / 1.04G static 2015-04-06 21:12 zbe-69 - - 1.00K static 2015-04-06 21:16 root at tz2:/root# beadm destroy zbe-69 Are you sure you want to destroy zbe-69? This action cannot be undone (y/[n]): y 'Destroyed successfully root at tz2:/root# exit logout tz2 console login: tz2 console login: Connection to danmcd-ob closed. I'm not sure what you can or should do. Maybe your pool has some corruption? (Long shot I know, but perhaps zpool scrub might be in order?) Dan From cks at cs.toronto.edu Mon Apr 6 21:46:38 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 06 Apr 2015 17:46:38 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: danmcd's message of Mon, 06 Apr 2015 16:01:42 -0400. <90649030-A9A6-4125-8B52-7CC54B51303F@omniti.com> Message-ID: <20150406214638.456787A093C@apps0.cs.toronto.edu> > > Update Phase 3141/16901Action upgrade failed for 'opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py' (pkg://omnios/developer/gcc48): > > TypeError: 'NoneType' object is not callable > > It's like you got an empty file for this one. I found the locus of the problem (I can't say I found the problem itself). We have /opt as a separate ZFS filesystem, and here pkg update is trying to update files in /opt in the new boot environment, which of course only has the root filesystem and so is missing everything in /opt. This appears to make some internal bits of pkg go badly off-course. Even if the pkg(5) code survived this particular mishap, updating packages that live in /opt in a new boot environment is fatal in general if the new boot environment does not actually contain the real /opt, because pkg will create files and directories in /opt and then on reboot ZFS will refuse to mount the 'real' /opt filesystem over the newly-populated root filesystem /opt. As far as I can see there is no simple way out of this (at least none that preserves the spirit of separate boot environments). My modest proposal would be that pkg refuse to update packages with paths outside the root filesystem if it's making a new boot environment. If this causes the update to fail due to dependency issues, well, I guess people get to clean things up by hand somehow (eg temporarily remove the 'cannot be updated' packages, which pkg should obviously report). What I think is happening in the code is that in /usr/lib/python2.6/vendor-packages/pkg/actions/file.py part of the check for 'do we need to actually install a new copy of this' (in install()'s 'if do_content and ...' code) is whether or not the file currently exists on disk. Since there is no (old) /opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py file present in the new boot environment, this check says 'yes, we need to' (in needsdata()). However I suspect that earlier the code said 'no, we don't need data for this, it's there on disk (in the real system)' so didn't set up the FileAction object's self.data attribute since it theoretically wasn't going to be needed. - cks From omnios at citrus-it.net Mon Apr 6 22:05:25 2015 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 6 Apr 2015 22:05:25 +0000 (UTC) Subject: [OmniOS-discuss] Problem with VNIC in KVM Message-ID: Evening all, I'm having a problem with network interfaces inside KVM and wondered if anyone has any ideas? The problem is that the virtual machine doesn't receive any traffic on the network interface. It can send it ok though. The VM is OpenIndiana and a snoop on the sole network interface within the VM shows outbound ARP requests but no inbound traffic at all. root at oi:~# snoop Using device e1000g0 (promiscuous mode) x.x.x.x -> (broadcast) ARP C Who is y.y.y.y, y.y.y.y ? (repeated) Snooping on the vnic in the global zone shows the outbound ARPs and responses. global# snoop -d oi0 x.x.x.x -> (broadcast) ARP C Who is y.y.y.y, y.y.y.y ? y.y.y.y -> x.x.x.x ARP R y.y.y.y, y.y.y.y is 0:0:5e:0:1:1 global# dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID oi0 igb0 100 2:8:20:62:d7:d9 random 0 global# pargs `pgrep qemu` 1843: /usr/bin/qemu-system-x86_64 -name oi -enable-kvm -nodefaults -vnc :1 -monitor t argv[0]: /usr/bin/qemu-system-x86_64 argv[1]: -name argv[2]: oi argv[3]: -enable-kvm argv[4]: -nodefaults argv[5]: -vnc argv[6]: :1 argv[7]: -monitor argv[8]: telnet:localhost:7001,server,nowait,nodelay argv[9]: -cpu argv[10]: host argv[11]: -smp argv[12]: 2 argv[13]: -m argv[14]: 4G argv[15]: -vga argv[16]: std argv[17]: -no-hpet argv[18]: -localtime argv[19]: -drive argv[20]: file=/dev/zvol/rdsk/data/vm/oi/hdd0,if=ide argv[21]: -daemonize argv[22]: -net argv[23]: nic,vlan=0,name=net0,model=e1000,macaddr=2:8:20:62:d7:d9 argv[24]: -net argv[25]: vnic,vlan=0,name=net0,ifname=oi0,macaddr=2:8:20:62:d7:d9 Any pointers on how to diagnose the problem further? Thanks, Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From mir at miras.org Mon Apr 6 22:25:21 2015 From: mir at miras.org (Michael Rasmussen) Date: Tue, 7 Apr 2015 00:25:21 +0200 Subject: [OmniOS-discuss] Problem with VNIC in KVM In-Reply-To: References: Message-ID: <20150407002521.713d74e2@sleipner.datanom.net> On Mon, 6 Apr 2015 22:05:25 +0000 (UTC) Andy Fiddaman wrote: > Evening all, > > I'm having a problem with network interfaces inside KVM and wondered if > anyone has any ideas? > Is hardware checksum offloading on for the nic? Hardware checksum offloading is a notorious problem for virtualized environments. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan & Plaugher) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mir at miras.org Mon Apr 6 23:11:20 2015 From: mir at miras.org (Michael Rasmussen) Date: Tue, 7 Apr 2015 01:11:20 +0200 Subject: [OmniOS-discuss] zfs performance vis-a-vis cpu cores Message-ID: <20150407011120.1e8b7650@sleipner.datanom.net> Hi all, Any benchmarks available which profes coherence between number of cpu cores and zfs performance? And does it matter whether it is real cores or threads? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: So much food; so little time! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From chip at innovates.com Mon Apr 6 23:24:51 2015 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 6 Apr 2015 18:24:51 -0500 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <5496C3F5-2194-4936-847A-950BD8AAAF55@omniti.com> References: <1070639246.2109450.1428313800852.JavaMail.zimbra@cantekstil.com.tr> <5496C3F5-2194-4936-847A-950BD8AAAF55@omniti.com> Message-ID: On Mon, Apr 6, 2015 at 9:30 AM, Dan McDonald wrote: > > > On Apr 6, 2015, at 5:50 AM, Hafiz Rafiyev wrote: > > > > > > only log I see from omnios side is: > > > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local > hostname binding for transport tcp6 - delegations will not be available on > this transport > > Are you having DNS problems? > > This error is in an unchanged subsystem, the NFSv4 callback daemon. The > error looks like something caused by a naming-services failure. > I'd say this is a red-herring. ESXi 5.5 will only use NFSv3. However, DNS resolution is critical for ESXi NFS mounts even when mounting via IP address. I always put host entries in /etc/hosts on each ESXi host for all other hosts, vCenter and NFS servers. The same on the NFS server side. I learned this years ago on a 3 AM call to VMware support. :) -Chip > > I'll forward your note along to an illumos-community NFS expert, I may > find out more. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Tue Apr 7 00:11:12 2015 From: mir at miras.org (Michael Rasmussen) Date: Tue, 7 Apr 2015 02:11:12 +0200 Subject: [OmniOS-discuss] Problem with VNIC in KVM In-Reply-To: References: <20150407002521.713d74e2@sleipner.datanom.net> Message-ID: <20150407021112.3801b691@sleipner.datanom.net> On Mon, 6 Apr 2015 23:42:55 +0000 (UTC) Andy Fiddaman wrote: > > I've just tried it on and off and no difference (host and VM). > The annoying thing is that I've had this working fine in the lab before > the machine was rebuilt and put into production. Must be missing > something! Ok. Could it be some missing ipf? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: OH MY GOD NOT A RANDOM QUOTE GENERATOR surely you didnt think that was static? how lame would that be? :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From fwp at deepthought.com Tue Apr 7 01:26:13 2015 From: fwp at deepthought.com (Frank Pittel) Date: Mon, 6 Apr 2015 20:26:13 -0500 Subject: [OmniOS-discuss] Realtek ethernet driver In-Reply-To: References: <20150404043154.GA2630@warlock.deepthought.com> Message-ID: <20150407012612.GB2630@warlock.deepthought.com> I'm sorry for not replying earlier but the nic is working. I went out on Saturday and bought an intel nic and after installing the new card I tried the Realtek nic again and it worked fine. No idea of what happened and why. Frank On Mon, Apr 06, 2015 at 10:08:12AM -0400, Eric Sproul wrote: > On Sat, Apr 4, 2015 at 12:31 AM, Frank Pittel wrote: > > I have an addon ethernet board in my machine that uses a RTL8169 chip. The driver loads and I am able to configure it and assign the nic an IP > > address. However when I connect a cable to it the nic doesn't respond to ping, ssh, etc. The intel onboard nic works without issue. > > > > The relevent entry from lspci is: > > Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) > > > > Is there a known issue with the driver? > > > > Frank, > This chip is ostensibly supported by rge(7D), but there are many > revisions of that chip, used in a wide variety of adapters. These are > usually found more on desktop/enthusiast systems than server hardware, > so the driver, rge, doesn't get a whole lot of attention. The last > substantive update to it was back in the OpenSolaris days, when Sun > thought that developer laptops were a good distro target. :/ > > It's possible there are newer revisions of the chip that have > different enough PHYs that the driver doesn't know how to initialize > the link. If you could share the PCI ID of that part (`prtconf -d | > grep RTL8169`), that would be helpful, but my guess would be that > someone will have to take up the task of updating rge(7D) to support > more parts. > > And.. if it were me, I'd just forget about it and use the Intel port. > If you need a second NIC, go Intel. > > Eric From danmcd at omniti.com Tue Apr 7 01:32:23 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 6 Apr 2015 21:32:23 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150406214638.456787A093C@apps0.cs.toronto.edu> References: <20150406214638.456787A093C@apps0.cs.toronto.edu> Message-ID: Thank you for that detailed analysis. I have massive context switching happening later this week, and again next week, but I want to remember this so I can do something about it. Thank you again, Dan From jimklimov at cos.ru Tue Apr 7 04:51:47 2015 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 07 Apr 2015 06:51:47 +0200 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: References: <20150406214638.456787A093C@apps0.cs.toronto.edu> Message-ID: <9FBF6237-5299-4493-B025-D1E0A3B2FDD7@cos.ru> 7 ?????? 2015??. 3:32:23 CEST, Dan McDonald ?????: >Thank you for that detailed analysis. I have massive context switching >happening later this week, and again next week, but I want to remember >this so I can do something about it. > >Thank you again, >Dan > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss Chris, about a month or two ago i replied on an illumos-related list regarding a similar problem (maybe this popped up for hipster users more than once). Searching for those might add more details to your context ;) Short story is that /opt is part of a namespace managed by the Solaris packaging and as such is part of a BE fs tree. If you have privately managed packages under certain subdirs, turn those sub-dirs into separate datasets instead. Alternately see my write-up on split-root installs (in OI wiki), i have some script scaffolding (now on github) to manage similar setups and explain that in the wiki. For now this is a bolt-on workaround. I'd be happy if someone ported that into illumos-gate properly, bugs were filed years ago ;) HTH, Jim Klimov -- Typos courtesy of K-9 Mail on my Samsung Android From johan.kragsterman at capvert.se Tue Apr 7 08:08:35 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Tue, 7 Apr 2015 10:08:35 +0200 Subject: [OmniOS-discuss] Ang: Re: Best infrastructure for VSphere/Hyper-V In-Reply-To: <57413703-4516@mail.careyweb.com> References: <57413703-4516@mail.careyweb.com> Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: danmcd at omniti.com, thomas.wiese at ovis-consulting.de Fr?n: "Nate Smith" S?nt av: "OmniOS-discuss" Datum: 2015-04-06 20:46 Kopia: omnios-discuss at lists.omniti.com ?rende: Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V Update: I disabled cstates ?and mwaits ?and that fixed the crashes i was getting when,the system was slow. But I still got the qlogic target dropouts during certain ios.after lots of research, I guessed that I was having a queuing problem. To alleviate that I did a couple things: 1. Reconfigured all my host and target views ?so that each host port only saw one target port. Formerly I had all four of my target ports mapped to both initiators on each host. This led to a situation ?where i had eight mpio paths on each host. 2. Assuming an incoming queue depth of 256 (right?) for each fibre target port, a round robin mpio infrastructure ?was bound ?to flood the target ports. Some documentation on qlogic indicated the default per lun outgoing queue depth ?was 32. After some calculations I dropped this to 16. As of now, each host only has two mpio paths in round robin with an outgoing queue depth of 16. I tried to test it under io load and was unable to get it to drop out in scenarios that would cause qlt to drop out in the past. (Multiple io operations while running a backup and destroying a hyperv checkpoint, etc.) system appears stable. So far. Thanks for the help everyone. ?Will update. -Nate Thanks, Nate! VERY HELPFUL, indeed! For all of us maintaining storage infrastructure. Looking forward to any update on this subject! Regards Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Apr 7 14:13:08 2015 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 7 Apr 2015 10:13:08 -0400 Subject: [OmniOS-discuss] NTP update (now to 4.2.8p2) is now available Message-ID: Time to utter "pkg update", NTP 4.2.8p2 has been released. I didn't want to hold up r151014 for it (even though I knew it was coming... I was under CERT embargo). It's not a reboot-required patch, and it will only create a backup BE by default. This update is available for r151006, r151012, and r151014. Bloody is in its current post-release torpor, and when bloody becomes r151015, it will have 4.2.8p2 for NTP. Happy updating! Dan From nagele at wildbit.com Tue Apr 7 14:38:43 2015 From: nagele at wildbit.com (Chris Nagele) Date: Tue, 7 Apr 2015 10:38:43 -0400 Subject: [OmniOS-discuss] Fwd: All SSD pool advice In-Reply-To: References: <5520712E.6030207@will.to> Message-ID: That helps a lot. That SC216BA-R1K28LPB chassis looks really nice, especially the two extra bays in the back for the rpool. Thanks everyone! Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Mon, Apr 6, 2015 at 10:04 AM, Schweiss, Chip wrote: > > On Mon, Apr 6, 2015 at 8:53 AM, F?bio Rabelo > wrote: >> >> Sorry, forget to forward to the list ... >> >> >> ---------- Forwarded message ---------- >> From: F?bio Rabelo >> Date: 2015-04-06 10:51 GMT-03:00 >> Subject: Re: [OmniOS-discuss] All SSD pool advice >> To: Chris Nagele >> >> >> I never get my hands at that 4U model ... >> >> I have 2 of this babys in a customer of mine : >> >> http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm >> >> Each one with 24 1TB Samsung 850PRO for a litle over an year, >> OminOS+Napp-it , no issue whatsoever ... >> >> Expanded Chassis brings me lots and lots of headaches ... > > > The system I've built with interposers has SAS expanders and gives me no > problems. Samsung SSDs are the only SSD I've found that works well with the > interposer. > > -Chip >> >> >> >> F?bio Rabelo >> >> 2015-04-06 10:41 GMT-03:00 Chris Nagele : >> >>> Thanks everyone. Regarding the expanders, our 4U servers are on the >>> following chassis: >>> >>> http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm >>> >>> We are using all SAS disks, except for the SSDs. How big is the risk >>> here when it comes to SAS -> SATA conversion? Our newer servers have >>> direct connections on each lane to the disk. >>> >>> Chris >>> >>> Chris Nagele >>> Co-founder, Wildbit >>> Beanstalk, Postmark, dploy.io >>> >>> >>> On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: >>> > >>> > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro >>> > is the >>> > current favorite). They work great for IOPS. Here's my take. >>> > 1) you don't need a dedicated zil. Just let the zpool intersperse it >>> > amongst >>> > the existing zpool devices. They are plenty fast enough. >>> > 2) you don't need an L2arc for the same reason. a smaller number of >>> > dedicated devices would likely cause more of a bottleneck than serving >>> > off >>> > the existing pool devices (unless you were to put it on one of those >>> > giant >>> > RDRAM things or similar, but that adds a lot of expense) >>> > >>> > >>> > >>> > >>> > >>> > On 4/4/2015 3:07 PM, Chris Nagele wrote: >>> > >>> > We've been running a few 4U Supermicro servers using ZeusRAM for zil >>> > and >>> > SSDs for L2. The main disks are regular 1TB SAS. >>> > >>> > I'm considering moving to all SSD since the pricing has dropped so >>> > much. >>> > What things should I know or do when moving to all SSD pools? I'm >>> > assuming I >>> > don't need L2 and that I should keep the ZeusRAM. Should I only use >>> > certain >>> > types of SSDs? >>> > >>> > Thanks, >>> > Chris >>> > >>> > >>> > -- >>> > >>> > Chris Nagele >>> > Co-founder, Wildbit >>> > Beanstalk, Postmark, dploy.io >>> > >>> > >>> > >>> > _______________________________________________ >>> > OmniOS-discuss mailing list >>> > OmniOS-discuss at lists.omniti.com >>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> > >>> > >>> > >>> > _______________________________________________ >>> > OmniOS-discuss mailing list >>> > OmniOS-discuss at lists.omniti.com >>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> > >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From fabio at fabiorabelo.wiki.br Tue Apr 7 14:46:30 2015 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Tue, 7 Apr 2015 11:46:30 -0300 Subject: [OmniOS-discuss] Fwd: All SSD pool advice In-Reply-To: References: <5520712E.6030207@will.to> Message-ID: And no expander !!!! ;- ))) I use 3 IBM SAS1015 flashed to IT, the only quality SAS controller with afordable price that I can find here in Brasil . F?bio Rabelo 2015-04-07 11:38 GMT-03:00 Chris Nagele : > That helps a lot. That SC216BA-R1K28LPB chassis looks really nice, > especially the two extra bays in the back for the rpool. > > Thanks everyone! > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > On Mon, Apr 6, 2015 at 10:04 AM, Schweiss, Chip > wrote: > > > > On Mon, Apr 6, 2015 at 8:53 AM, F?bio Rabelo > > wrote: > >> > >> Sorry, forget to forward to the list ... > >> > >> > >> ---------- Forwarded message ---------- > >> From: F?bio Rabelo > >> Date: 2015-04-06 10:51 GMT-03:00 > >> Subject: Re: [OmniOS-discuss] All SSD pool advice > >> To: Chris Nagele > >> > >> > >> I never get my hands at that 4U model ... > >> > >> I have 2 of this babys in a customer of mine : > >> > >> http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm > >> > >> Each one with 24 1TB Samsung 850PRO for a litle over an year, > >> OminOS+Napp-it , no issue whatsoever ... > >> > >> Expanded Chassis brings me lots and lots of headaches ... > > > > > > The system I've built with interposers has SAS expanders and gives me no > > problems. Samsung SSDs are the only SSD I've found that works well with > the > > interposer. > > > > -Chip > >> > >> > >> > >> F?bio Rabelo > >> > >> 2015-04-06 10:41 GMT-03:00 Chris Nagele : > >> > >>> Thanks everyone. Regarding the expanders, our 4U servers are on the > >>> following chassis: > >>> > >>> http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm > >>> > >>> We are using all SAS disks, except for the SSDs. How big is the risk > >>> here when it comes to SAS -> SATA conversion? Our newer servers have > >>> direct connections on each lane to the disk. > >>> > >>> Chris > >>> > >>> Chris Nagele > >>> Co-founder, Wildbit > >>> Beanstalk, Postmark, dploy.io > >>> > >>> > >>> On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > >>> > > >>> > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro > >>> > is the > >>> > current favorite). They work great for IOPS. Here's my take. > >>> > 1) you don't need a dedicated zil. Just let the zpool intersperse it > >>> > amongst > >>> > the existing zpool devices. They are plenty fast enough. > >>> > 2) you don't need an L2arc for the same reason. a smaller number of > >>> > dedicated devices would likely cause more of a bottleneck than > serving > >>> > off > >>> > the existing pool devices (unless you were to put it on one of those > >>> > giant > >>> > RDRAM things or similar, but that adds a lot of expense) > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > On 4/4/2015 3:07 PM, Chris Nagele wrote: > >>> > > >>> > We've been running a few 4U Supermicro servers using ZeusRAM for zil > >>> > and > >>> > SSDs for L2. The main disks are regular 1TB SAS. > >>> > > >>> > I'm considering moving to all SSD since the pricing has dropped so > >>> > much. > >>> > What things should I know or do when moving to all SSD pools? I'm > >>> > assuming I > >>> > don't need L2 and that I should keep the ZeusRAM. Should I only use > >>> > certain > >>> > types of SSDs? > >>> > > >>> > Thanks, > >>> > Chris > >>> > > >>> > > >>> > -- > >>> > > >>> > Chris Nagele > >>> > Co-founder, Wildbit > >>> > Beanstalk, Postmark, dploy.io > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > OmniOS-discuss mailing list > >>> > OmniOS-discuss at lists.omniti.com > >>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > OmniOS-discuss mailing list > >>> > OmniOS-discuss at lists.omniti.com > >>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss > >>> > > >>> _______________________________________________ > >>> OmniOS-discuss mailing list > >>> OmniOS-discuss at lists.omniti.com > >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss > >> > >> > >> > >> > >> _______________________________________________ > >> OmniOS-discuss mailing list > >> OmniOS-discuss at lists.omniti.com > >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > >> > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cks at cs.toronto.edu Tue Apr 7 15:49:14 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 07 Apr 2015 11:49:14 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: jimklimov's message of Tue, 07 Apr 2015 06:51:47 +0200. <9FBF6237-5299-4493-B025-D1E0A3B2FDD7@cos.ru> Message-ID: <20150407154914.A8D597A00D3@apps0.cs.toronto.edu> > Short story is that /opt is part of a namespace managed by the Solaris > packaging and as such is part of a BE fs tree. If you have privately > managed packages under certain subdirs, turn those sub-dirs into > separate datasets instead. If this is the case for OmniOS, I believe that it should be strongly and visibly documented in the OmniOS wiki as part of the install instructions and so on. It is not intuitive to me at all, and in fact I would strongly expect that it would not be the case as /opt is where people have traditionally put *third party* software. We explicitly made /opt a separate ZFS filesystem because we did not want the various parts of /opt that we add (through various mechanisms) to be captured in the boot environment and thus to chew up space (as changes in third-party packages in /opt are normally totally decoupled from changes in the boot environment). As far as making subtrees of /opt into their own ZFS filesystems: this is something that doesn't scale at an administrative level. It's quite possible to have any number of subdirectories in /opt (one per vendor, one per relatively separate package, etc etc). Having to carefully make each of these a separate ZFS filesystem is a lot of work, and then of course you have to carefully *not* make the ones that are part of the core system into separate ZFS filesystems because then they'll blow up on package upgrades. (So how do you know which /opt package directories are safe to make into separate filesystems so they won't be incorporated into your BEs when you don't want them to be? Good question! I have no idea. Documentation on this would be good too.) Overall, I very strongly believe that either /opt needs to be safe as a whole or it needs to be entirely off limits. In that /opt has been 'put your stuff here freely', I believe that it is a serious mistake to claim it arbitrarily for the operating system (which is what saying '/opt and random sub-parts of it must be in the BE' amounts to). - cks From richard.elling at richardelling.com Tue Apr 7 16:25:11 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Tue, 7 Apr 2015 09:25:11 -0700 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150407154914.A8D597A00D3@apps0.cs.toronto.edu> References: <20150407154914.A8D597A00D3@apps0.cs.toronto.edu> Message-ID: > On Apr 7, 2015, at 8:49 AM, Chris Siebenmann wrote: > >> Short story is that /opt is part of a namespace managed by the Solaris >> packaging and as such is part of a BE fs tree. If you have privately >> managed packages under certain subdirs, turn those sub-dirs into >> separate datasets instead. > > If this is the case for OmniOS, I believe that it should be strongly > and visibly documented in the OmniOS wiki as part of the install > instructions and so on. It is not intuitive to me at all, and in fact > I would strongly expect that it would not be the case as /opt is where > people have traditionally put *third party* software. See filesystem(5) History lesson: until people could afford to purchase more than one disk and before Sun invented the diskless workstation (with shared /usr), everything was under /. Indeed, many other wildly successful OSes (MS-DOS, MS-Windows, OSX, Android) do likewise. As such, having separate filesystems is actually detrimental to systems management and only arrived at the marketplace when the OS outgrew the drives available at the time *and* people could start to afford buying more than one drive. RAID-0 came later. In other words, it is a bad idea to manage many filesystems under the pretense that there is some magical contract regarding their stability. Today, we have more options available: pooled storage, snapshots, etc. that make managing multiple filesystems almost as easy as managing one. -- richard From cks at cs.toronto.edu Tue Apr 7 16:40:08 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 07 Apr 2015 12:40:08 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: richard.elling's message of Tue, 07 Apr 2015 09:25:11 -0700. Message-ID: <20150407164008.9956A7A00D3@apps0.cs.toronto.edu> > History lesson: until people could afford to purchase more than one > disk and before Sun invented the diskless workstation (with shared > /usr), everything was under /. As Richard knows but other people may not, this is ahistorical on Unix. From almost the beginning[*] Unix had a split between the root filesystem and the /usr filesystem, based (as far as I understand it) on the physical disks involved at Bell Labs CSRG on their Unix machine. This is part of why the split of commands between /bin and /usr/bin existed for years. Sun's diskless machines did not invent a split /usr, they just took advantage of existing practice and made it read-only and shared. (Even that read-only'ing took some amount of re-engineering, because of course originally /var did not exist and there was, for example, /usr/tmp, /usr/spool, /usr/adm, and /usr/log. SunOS created /var and relocated those via symlinks (and eventually program changes) in order to make /usr read-only.) - cks [*: Historical evidence available via www.tuhs.org suggests no later than the Third Edition in 1973. ] From vab at bb-c.de Tue Apr 7 18:04:18 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Tue, 7 Apr 2015 20:04:18 +0200 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150407164008.9956A7A00D3@apps0.cs.toronto.edu> References: <20150407164008.9956A7A00D3@apps0.cs.toronto.edu> Message-ID: <21796.7202.415970.356918@glaurung.bb-c.de> Chris Siebenmann writes: > > History lesson: until people could afford to purchase more than > > one disk and before Sun invented the diskless workstation (with > > shared /usr), everything was under /. > > As Richard knows but other people may not, this is ahistorical on > Unix. While history discussions are fun, this one distracts from the problem at hand a bit. :-) Your problem (/opt is expected to be a part of the BE and things break when it isn't) is a case of "works as designed". Oracle has had the same problem, albeit with /var. In recent 11.2 versions, they have documented that behavior, and introduced a new separate dataset for all those things you *don't* want to have under BE management. The dataset is called rpool/VARSHARE and mounted under /var/share. There is a surprising amount of stuff in there, and most of it makes sense, too. If your boot hangs because of some failing binary, you will still have the core dump in /var/share/cores when you go back to the last BE. The audit logs are still there, etc. etc. Even the mail spool now is in /var/share/mail. Symlinks are provided for the legacy locations (like /var/mail). So one way would be to follow that example and create an OPTSHARE dataset, mount it under /opt/share, and symlink all the stuff you need to be outside the BE into it. We have considered this idea, as we build our software for the /opt/local tree, for precisely the same reasons you cite for your separate /opt dataset. However, in the end it is not worth it, due to the amount of extra work it causes. A better way is to IPS package everything properly, and add proper metadata to your packages, so that those packages that should go into a new BE do ask for one in their manifest. That way, there is no distinction between any "system" package living in /usr (or wherever) and your package living in /opt. You can leverage the tight integration of IPS, BEs, and ZFS for your stuff. Updating and rolling back becomes very easy. Disk space is not really an issue; ZFS snapshots are relatively cheap. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Tue Apr 7 18:09:28 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Tue, 7 Apr 2015 20:09:28 +0200 Subject: [OmniOS-discuss] 014 NGZ: beadm problems In-Reply-To: <21794.63757.279415.386282@glaurung.bb-c.de> References: <21794.59633.431298.345374@glaurung.bb-c.de> <26FD8716-2DF6-47AB-9696-9CA740A5E73E@omniti.com> <21794.63757.279415.386282@glaurung.bb-c.de> Message-ID: <21796.7512.790938.753525@glaurung.bb-c.de> Volker A. Brandt writes: > Dan McDonald writes: > > I noticed only one difference just now, but that really shouldn't > > matter: I use exclusive-stack zones... exclusively. You used > > shared-stack. I can't believe that'd make a difference... > > > > ... and it didn't. It's working for me. > > > > I'll try a fresh install on this VM, just to make sure it's all > > good. > > Just to cross-check, I'll try an ip-type=exclusive zone... And I did. Same result. I did some other tests (log in via root and go on to the zone using zlogin, in case it was something in my user environment, etc), but nothing changed. All pools and datasets involved are healthy. The intended use for that server was to test software in zones with new BEs for each test. Not being able to create BEs is a bit of a problem. So I will re-kayak the box when I find the time, and hope that the problem goes away, in true M$ Windows fashion. :-) Regards -- Volker A. Brandt -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From omnios at citrus-it.net Tue Apr 7 18:30:02 2015 From: omnios at citrus-it.net (Andy Fiddaman) Date: Tue, 7 Apr 2015 18:30:02 +0000 (UTC) Subject: [OmniOS-discuss] Problem with VNIC in KVM In-Reply-To: <20150407021112.3801b691@sleipner.datanom.net> References: <20150407002521.713d74e2@sleipner.datanom.net> <20150407021112.3801b691@sleipner.datanom.net> Message-ID: On Tue, 7 Apr 2015, Michael Rasmussen wrote: ; On Mon, 6 Apr 2015 23:42:55 +0000 (UTC) ; Andy Fiddaman wrote: ; ; > ; > I've just tried it on and off and no difference (host and VM). ; > The annoying thing is that I've had this working fine in the lab before ; > the machine was rebuilt and put into production. Must be missing ; > something! ; Ok. Could it be some missing ipf? Kstat in the OI VM was showing packets being received, they just weren't making it through the IP stack for some reason. Wasn't IPF but it has started working since I increased the number of virtual CPUs allocated to the VM. I haven't conclusively proven the link but I have a working system now so I'm going to leave it at that as I have some Illumos builds to get done! Thanks for the suggestions. If I work out any conclusive links I'll post back. Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From cks at cs.toronto.edu Tue Apr 7 18:54:03 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 07 Apr 2015 14:54:03 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: vab's message of Tue, 07 Apr 2015 20:04:18 +0200. <21796.7202.415970.356918@glaurung.bb-c.de> Message-ID: <20150407185403.CB6537A01A8@apps0.cs.toronto.edu> > A better way is to IPS package everything properly, and add proper > metadata to your packages, so that those packages that should go > into a new BE do ask for one in their manifest. That way, there > is no distinction between any "system" package living in /usr (or > wherever) and your package living in /opt. You can leverage the tight > integration of IPS, BEs, and ZFS for your stuff. Updating and rolling > back becomes very easy. > > Disk space is not really an issue; ZFS snapshots are relatively cheap. I fundamentally disagree with this view of disk space. ZFS snapshots are only cheap if you do not have data churn. To the extent that you have churn in files, snapshots use up increasing amounts of space over time (because an increasing amount of old data has been removed in the current version of the filesystem and is preserved only by the snapshot). The reason we made /opt a separate ZFS filesystem and I'd certainly prefer to keep it that way is that we're concerned about churn in non-OmniOS parts of /opt (which I thought was basically 'all of them') affecting space used by BEs. To the very limited extent that we care about the equivalent of BEs for 'our' portions of /opt[*], we'll manage that explicitly ourselves instead of relying on BEs, because we consider the two to be decoupled. Saving 'our' /opt's state or switching around has almost nothing to do with saving and switching core OS state. Trying to manage the two through the same mechanism would in fact be an anti-feature for us. And to answer the next question: with relatively small SSDs as the root drives and relatively large amounts of physical memory (and thus relatively large crash dumps if/when we need them), disk space really is a limited quantity. We've already had to reduce OmniOS's rpool/dump space well below what the system would have preferred to have. - cks [*: most of our usage of /opt actually comes from third parties, such as pkgsrc. ] From svavar at pipar-tbwa.is Wed Apr 8 09:36:20 2015 From: svavar at pipar-tbwa.is (=?iso-8859-1?Q?Svavar_=D6rn_Eysteinsson?=) Date: Wed, 8 Apr 2015 09:36:20 +0000 Subject: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? Message-ID: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> Hello List. I recently upgraded my OmniOS installation from 1012 to 1014 on my HP Microserver N40L. Everything went smooth and everything seems OK and solid. There are tho, these messages that appear in my logs every now and then regarding the network controller (bge0) : Apr 7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2c - not updated? Apr 7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x86 - not updated? Apr 7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x94 - not updated? Apr 7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc2 - not updated? Apr 7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6a - not updated? Apr 7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4b - not updated? Apr 7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x68 - not updated? Apr 7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? Apr 7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6 - not updated? Apr 7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa8 - not updated? Apr 7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? Apr 7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? Apr 7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? Apr 7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x62 - not updated? Apr 7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x26 - not updated? Apr 7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? Apr 7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? Apr 7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe8 - not updated? Apr 7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe2 - not updated? Apr 7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xab - not updated? Apr 7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x1c - not updated? Apr 7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? Apr 7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x65 - not updated? Apr 7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd7 - not updated? Apr 7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xea - not updated? Apr 7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb - not updated? Apr 7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xaf - not updated? Apr 7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3d - not updated? Apr 7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? Apr 7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? Apr 7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa4 - not updated? Apr 7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xae - not updated? Apr 7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? Apr 7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? Apr 7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x50 - not updated? Apr 7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x80 - not updated? Apr 7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x30 - not updated? Apr 7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? Apr 7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb2 - not updated? Apr 7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? Apr 7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x41 - not updated? Apr 7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8 - not updated? Apr 7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? Apr 7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? Apr 7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5b - not updated? Apr 7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe9 - not updated? Apr 7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x88 - not updated? Apr 7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xfb - not updated? Apr 7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? Apr 7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? Apr 7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5c - not updated? Apr 8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2e - not updated? Apr 8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd2 - not updated? Apr 8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? Apr 8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x24 - not updated? Apr 8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcd - not updated? Apr 8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x48 - not updated? Does anyone know what these interrupt - not updates messages mean ? I have never seen them before, until after the 1014 update. dladm shows : LINK MEDIA STATE SPEED DUPLEX DEVICE bge0 Ethernet up 1000 full bge0 dladm show-link -s : LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORS bge0 13344422 2915541511 0 15403475 1025837411 0 Thanks in advance. Best regards, Svavar O Reykjavik - Iceland From davide.poletto at gmail.com Wed Apr 8 10:39:44 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Wed, 8 Apr 2015 12:39:44 +0200 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? Message-ID: Hello list, I'm planning to use OmniOS 151014 as base OS for a Web Server in order to deploy a little "Intranet-in-a-Box" project based on a Drupal 7 distribution called "Open Atrium 2" (other required mandatory components are PHP and MySQL). This is the very first time for me in using OmniOS to provide web services considering I used OmniOS basically only as base OS to provide NFS storage. I'm trying to understand (1st issue) what web server to use (both apache and nginx are good candidates for Drupal, as far as I can see) and (2nd issue) how to perform its installation (relying on specific repositories that provide those packages or via pkgsrc as happens with SmartOS) considering also the idea (hope that it will not be too silly) that (3rd issue) it would be great to have the web server document root in a separate ZFS dataset (so not into the root pool). >From the hardware perspective my plan is to use a mirrored root pool for OmniOS and another mirrored data pool especially dedicated to web server's document root (which, by default, varies when using apache or nginx) OR to have a dedicated dataset for the whole path in which the web server application will be installed (I guess under /opt for both apache and nginx?). Not sure if my 3rd issue above is more (I presume less) important than not using a NGZ (Non Global Zone) approach: actually I'm not planning to run the web server into a dedicated NGZ (Non Global Zone) even if - I've read - that should be the only right way to follow leaving the GZ (Global Zone) practically untouched just for administrative maintenance (good practice). I'm ready to change my plan if someone will show me benefits in doing so (I'm a little bit worried on the networking part of the NGZ approach). Both the ideas of dataset separation on /opt or just the one of a dataset dedicated to the web server's document root don't appear so new...but, very recently in this list, I've also read something related to /opt (when in a separate dataset than root pool) that is scaring me a lot. Any guidance/help is really appreciated (consider I'm a noob among experts). Kind regards, Davide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Wed Apr 8 10:51:52 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Wed, 8 Apr 2015 12:51:52 +0200 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: References: Message-ID: <21797.2120.109778.692414@glaurung.bb-c.de> Hi Davide! > I'm trying to understand (1st issue) what web server to use (both > apache and nginx are good candidates for Drupal, as far as I can > see) and (2nd issue) how to perform its installation (relying on > specific repositories that provide those packages or via pkgsrc as > happens with SmartOS) considering also the idea (hope that it will > not be too silly) that (3rd issue) it would be great to have the web > server document root in a separate ZFS dataset (so not into the root > pool). I am using the apache22 from the OmniOS "add-on" repository at ms.omnios.com. It works perfectly and is absolutely good enough. Apache was installed on the server while it was running 012, but the server is now updated to 014. Apache still works fine under 014. However, it serves only static content here, no Drupal. As document root, I created a separate ZFS dataset, called it /www, and edited httpd.conf accordingly. HTH and regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Wed Apr 8 10:57:59 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Wed, 8 Apr 2015 12:57:59 +0200 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150407185403.CB6537A01A8@apps0.cs.toronto.edu> References: <21796.7202.415970.356918@glaurung.bb-c.de> <20150407185403.CB6537A01A8@apps0.cs.toronto.edu> Message-ID: <21797.2487.651153.700023@glaurung.bb-c.de> > I fundamentally disagree with this view of disk space. ZFS > snapshots are only cheap if you do not have data churn. To the > extent that you have churn in files, snapshots use up increasing > amounts of space over time (because an increasing amount of old data > has been removed in the current version of the filesystem and is > preserved only by the snapshot). > > The reason we made /opt a separate ZFS filesystem and I'd certainly > prefer to keep it that way is that we're concerned about churn in > non-OmniOS parts of /opt (which I thought was basically 'all of > them') affecting space used by BEs. > > To the very limited extent that we care about the equivalent of BEs > for 'our' portions of /opt[*], we'll manage that explicitly > ourselves instead of relying on BEs, because we consider the two to > be decoupled. Saving 'our' /opt's state or switching around has > almost nothing to do with saving and switching core OS state. Trying > to manage the two through the same mechanism would in fact be an > anti-feature for us. > > And to answer the next question: with relatively small SSDs as the > root drives and relatively large amounts of physical memory (and > thus relatively large crash dumps if/when we need them), disk space > really is a limited quantity. We've already had to reduce OmniOS's > rpool/dump space well below what the system would have preferred to > have. So, to summarize, your /opt is: - confined in a small rpool - subject to high turnover in a subdirectory (e.g. "/opt/pkg") - managed completely separately from the rest of the rpool - independent of any BE I would hazard a guess that this is not "standard" /opt usage. :-) However, it is clear why you want a separate /opt in this case. If you can confine the "churn" to a subdirectory ("pkg" or whereever your pkgsrc-delivered apps live), then you might want to consider just making that subdirectory a separate dataset. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Wed Apr 8 14:33:27 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Apr 2015 10:33:27 -0400 Subject: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> References: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> Message-ID: <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> What does "prtconf -d" say about which model number your Broadcom/bge is? There was a massive bge update in the 014 release. Perhaps some error path should be less chatty? I'm including the illumos developer's list, just in case. Pardon the top-post, Dan > On Apr 8, 2015, at 5:36 AM, Svavar ?rn Eysteinsson wrote: > > > Hello List. > > I recently upgraded my OmniOS installation from 1012 to 1014 on my HP Microserver N40L. > Everything went smooth and everything seems OK and solid. > > There are tho, these messages that appear in my logs every now and then regarding the network controller (bge0) : > > Apr 7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2c - not updated? > Apr 7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x86 - not updated? > Apr 7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x94 - not updated? > Apr 7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc2 - not updated? > Apr 7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6a - not updated? > Apr 7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4b - not updated? > Apr 7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x68 - not updated? > Apr 7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? > Apr 7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6 - not updated? > Apr 7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa8 - not updated? > Apr 7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? > Apr 7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? > Apr 7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? > Apr 7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x62 - not updated? > Apr 7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x26 - not updated? > Apr 7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? > Apr 7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? > Apr 7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe8 - not updated? > Apr 7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe2 - not updated? > Apr 7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xab - not updated? > Apr 7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x1c - not updated? > Apr 7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? > Apr 7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x65 - not updated? > Apr 7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd7 - not updated? > Apr 7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xea - not updated? > Apr 7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb - not updated? > Apr 7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xaf - not updated? > Apr 7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3d - not updated? > Apr 7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? > Apr 7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? > Apr 7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa4 - not updated? > Apr 7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xae - not updated? > Apr 7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? > Apr 7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? > Apr 7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x50 - not updated? > Apr 7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x80 - not updated? > Apr 7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x30 - not updated? > Apr 7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? > Apr 7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb2 - not updated? > Apr 7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? > Apr 7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x41 - not updated? > Apr 7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8 - not updated? > Apr 7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? > Apr 7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? > Apr 7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5b - not updated? > Apr 7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe9 - not updated? > Apr 7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x88 - not updated? > Apr 7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xfb - not updated? > Apr 7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? > Apr 7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? > Apr 7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5c - not updated? > Apr 8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2e - not updated? > Apr 8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd2 - not updated? > Apr 8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? > Apr 8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x24 - not updated? > Apr 8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcd - not updated? > Apr 8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x48 - not updated? > > Does anyone know what these interrupt - not updates messages mean ? > I have never seen them before, until after the 1014 update. > > dladm shows : > LINK MEDIA STATE SPEED DUPLEX DEVICE > bge0 Ethernet up 1000 full bge0 > > dladm show-link -s : > LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORS > bge0 13344422 2915541511 0 15403475 1025837411 0 > > > Thanks in advance. > > Best regards, > > Svavar O > Reykjavik - Iceland > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Apr 8 14:35:14 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Apr 2015 10:35:14 -0400 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: References: Message-ID: There's no problem using an NGZ to host a webserver. Just make sure that zone has all of the relevant packages. Using an NGZ means that zone only has control over ZFS datasets that the global zone lets it control. The zonecfg(1M) command man page has details on this. I use apache in a zone on my Home Server: http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html Dan From danmcd at omniti.com Wed Apr 8 14:37:24 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Apr 2015 10:37:24 -0400 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <21797.2487.651153.700023@glaurung.bb-c.de> References: <21796.7202.415970.356918@glaurung.bb-c.de> <20150407185403.CB6537A01A8@apps0.cs.toronto.edu> <21797.2487.651153.700023@glaurung.bb-c.de> Message-ID: > On Apr 8, 2015, at 6:57 AM, Volker A. Brandt wrote: > > > So, to summarize, your /opt is: > > - confined in a small rpool > > - subject to high turnover in a subdirectory (e.g. "/opt/pkg") > > - managed completely separately from the rest of the rpool > > - independent of any BE > > I would hazard a guess that this is not "standard" /opt usage. :-) > However, it is clear why you want a separate /opt in this case. > If you can confine the "churn" to a subdirectory ("pkg" or whereever > your pkgsrc-delivered apps live), then you might want to consider > just making that subdirectory a separate dataset. If you place /opt in the BE/root filesystem, you CAN instantiate each /opt/ as a ZFS filesystem. I do this with the old Sun compiler set: rpool/spro 1.82G 14.9G 1.82G /opt/SUNWspro for example. Dan From doug at will.to Wed Apr 8 14:53:29 2015 From: doug at will.to (Doug Hughes) Date: Wed, 8 Apr 2015 10:53:29 -0400 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: References: Message-ID: My take to summarize the two choices: 1) use a NGZ in its on pool and you have complete isolation and you can move it from machine to machine as needed. More setup required, but doable. 2) use a pre-packaged apache or nginx that installs all of the read-only stuff in your regular root pool (this should be fine). You have to keep a small set of files in thie configuration under revision control, and they are the configuration files that describe your instances. You then define your DocumentRoot with all of the important stuff to be in your non-root zpool. (You can use the pre-packaged apache in either configuration, but you may achieve slightly better isolation with the NGZ if that is valuable. But, putting apache config files under revision control has been done for years and is pretty standard way to accomplish the same thing) On Wed, Apr 8, 2015 at 10:35 AM, Dan McDonald wrote: > There's no problem using an NGZ to host a webserver. Just make sure that > zone has all of the relevant packages. > > Using an NGZ means that zone only has control over ZFS datasets that the > global zone lets it control. The zonecfg(1M) command man page has details > on this. > > I use apache in a zone on my Home Server: > > > http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svavar at pipar-tbwa.is Wed Apr 8 14:54:13 2015 From: svavar at pipar-tbwa.is (=?utf-8?B?U3ZhdmFyIMOWcm4gRXlzdGVpbnNzb24=?=) Date: Wed, 8 Apr 2015 14:54:13 +0000 Subject: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> References: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> Message-ID: <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> Thanks for the quick reply. Here's my prtconf from the HP microserver : System Configuration: Oracle Corporation i86pc Memory size: 16352 Megabytes System Peripherals (Software Nodes): i86pc scsi_vhci, instance #0 pci, instance #0 pci103c,1609 (pciex1022,9601) [Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge] (driver not attached) pci103c,9602 (pciex103c,9602) [Hewlett-Packard Company unknown device], instance #0 display (pci1002,9712) [Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]], instance #0 pci1022,9606 (pciex1022,9606) [Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)], instance #0 pci103c,705d (pciex14e4,165b) [Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe], instance #0 Thanks again. BR, Svavar O > On 8. apr. 2015, at 14:33, Dan McDonald wrote: > > What does "prtconf -d" say about which model number your Broadcom/bge is? > > There was a massive bge update in the 014 release. Perhaps some error path should be less chatty? > > I'm including the illumos developer's list, just in case. > > Pardon the top-post, > Dan > > >> On Apr 8, 2015, at 5:36 AM, Svavar ?rn Eysteinsson wrote: >> >> >> Hello List. >> >> I recently upgraded my OmniOS installation from 1012 to 1014 on my HP Microserver N40L. >> Everything went smooth and everything seems OK and solid. >> >> There are tho, these messages that appear in my logs every now and then regarding the network controller (bge0) : >> >> Apr 7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2c - not updated? >> Apr 7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x86 - not updated? >> Apr 7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x94 - not updated? >> Apr 7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc2 - not updated? >> Apr 7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6a - not updated? >> Apr 7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4b - not updated? >> Apr 7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x68 - not updated? >> Apr 7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >> Apr 7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6 - not updated? >> Apr 7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa8 - not updated? >> Apr 7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >> Apr 7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >> Apr 7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >> Apr 7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x62 - not updated? >> Apr 7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x26 - not updated? >> Apr 7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >> Apr 7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr 7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe8 - not updated? >> Apr 7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe2 - not updated? >> Apr 7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xab - not updated? >> Apr 7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x1c - not updated? >> Apr 7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >> Apr 7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x65 - not updated? >> Apr 7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd7 - not updated? >> Apr 7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xea - not updated? >> Apr 7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb - not updated? >> Apr 7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xaf - not updated? >> Apr 7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3d - not updated? >> Apr 7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >> Apr 7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr 7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa4 - not updated? >> Apr 7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xae - not updated? >> Apr 7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? >> Apr 7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >> Apr 7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x50 - not updated? >> Apr 7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x80 - not updated? >> Apr 7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x30 - not updated? >> Apr 7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >> Apr 7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb2 - not updated? >> Apr 7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >> Apr 7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x41 - not updated? >> Apr 7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8 - not updated? >> Apr 7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >> Apr 7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? >> Apr 7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5b - not updated? >> Apr 7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe9 - not updated? >> Apr 7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x88 - not updated? >> Apr 7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xfb - not updated? >> Apr 7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? >> Apr 7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr 7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5c - not updated? >> Apr 8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2e - not updated? >> Apr 8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd2 - not updated? >> Apr 8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >> Apr 8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x24 - not updated? >> Apr 8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcd - not updated? >> Apr 8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x48 - not updated? >> >> Does anyone know what these interrupt - not updates messages mean ? >> I have never seen them before, until after the 1014 update. >> >> dladm shows : >> LINK MEDIA STATE SPEED DUPLEX DEVICE >> bge0 Ethernet up 1000 full bge0 >> >> dladm show-link -s : >> LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES OERRORS >> bge0 13344422 2915541511 0 15403475 1025837411 0 >> >> >> Thanks in advance. >> >> Best regards, >> >> Svavar O >> Reykjavik - Iceland >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > From omnios at citrus-it.net Wed Apr 8 14:54:09 2015 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 8 Apr 2015 14:54:09 +0000 (UTC) Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: References: Message-ID: On Wed, 8 Apr 2015, Davide Poletto wrote: ; Hello list, ; ; I'm planning to use OmniOS 151014 as base OS for a Web Server in order to ; deploy a little "Intranet-in-a-Box" project based on a Drupal 7 ; distribution called "Open Atrium 2" (other required mandatory components ; are PHP and MySQL). I run web servers on OmniOS using Apache 2.2 in NGZs - no problems*. I package apache for /opt/apache with the configuration files in /etc/opt/apache (--prefix=/opt/apache --sysconfdir=/etc/opt/apache) which puts both in the BE. I have mixed feelings about that but as long as you are aware of the implications it isn't a problem either way. The data is on a separate delegated ZFS data-set outside of the BE and mounted elsewhere and I set exec=off, setuid=off, devices=off for that. Apache is configured to write log files to the same data-set. Andy * - I did see performance issues the last time I tried Apache 2.4 but haven't had the time to go back and investigate. -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From davide.poletto at gmail.com Wed Apr 8 15:04:01 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Wed, 8 Apr 2015 17:04:01 +0200 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: <21797.2120.109778.692414@glaurung.bb-c.de> References: <21797.2120.109778.692414@glaurung.bb-c.de> Message-ID: Hi Volker! Thanks for your reassuring answer! Regarding the apache22 I'm little bit inclined to use apache24 if I could not use nginx instead (neither specifically due to Drupal 7 requirements nor because apache24 is more updated than apache22 <- looking at various publishers this isn't the case since both apache's packages refer to older versions with respect to current Apache 2.4.12 - at least regarding the Apache 2.4 software line). The nginx package looks a little bit updated (looking at pkgsrc) but, really, it's still at nginx-1.7.4 (August 2014) which is not the latest available (nginx-1.7.12, released yesterday) What I wrote above is not valid if I look at OpenCSW: in that case both Apache and Nginx packages look quite updated. Regarding the Document Root I'm glad to read that is possible to use a dedicated ZFS dataset (in a data pool) editing the web server's configuration file accordingly, that's what I want to do. Kind regards, Davide. On Wed, Apr 8, 2015 at 12:51 PM, Volker A. Brandt wrote: > Hi Davide! > > > > I'm trying to understand (1st issue) what web server to use (both > > apache and nginx are good candidates for Drupal, as far as I can > > see) and (2nd issue) how to perform its installation (relying on > > specific repositories that provide those packages or via pkgsrc as > > happens with SmartOS) considering also the idea (hope that it will > > not be too silly) that (3rd issue) it would be great to have the web > > server document root in a separate ZFS dataset (so not into the root > > pool). > > I am using the apache22 from the OmniOS "add-on" repository at > ms.omnios.com. It works perfectly and is absolutely good enough. > Apache was installed on the server while it was running 012, but > the server is now updated to 014. Apache still works fine under 014. > However, it serves only static content here, no Drupal. > > As document root, I created a separate ZFS dataset, called it > /www, and edited httpd.conf accordingly. > > > HTH and regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Wed Apr 8 15:09:30 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Wed, 8 Apr 2015 17:09:30 +0200 Subject: [OmniOS-discuss] OmniOS as web server: what good/best practices to follow? In-Reply-To: References: Message-ID: Hi Doug, I think I'm starting to understand what type of scenario could be deployed...both paths look good to me...maybe the NGZ way, as you say, make me feel that the configuration is a little bit cleaner than the second solution (and not to mention the portability from machine to machine, like exporting/importing a zpool dedicated to data). Thanks. On Wed, Apr 8, 2015 at 4:53 PM, Doug Hughes wrote: > My take to summarize the two choices: > > 1) use a NGZ in its on pool and you have complete isolation and you can > move it from machine to machine as needed. More setup required, but doable. > 2) use a pre-packaged apache or nginx that installs all of the read-only > stuff in your regular root pool (this should be fine). You have to keep a > small set of files in thie configuration under revision control, and they > are the configuration files that describe your instances. You then define > your DocumentRoot with all of the important stuff to be in your non-root > zpool. > > (You can use the pre-packaged apache in either configuration, but you may > achieve slightly better isolation with the NGZ if that is valuable. But, > putting apache config files under revision control has been done for years > and is pretty standard way to accomplish the same thing) > > > On Wed, Apr 8, 2015 at 10:35 AM, Dan McDonald wrote: > >> There's no problem using an NGZ to host a webserver. Just make sure that >> zone has all of the relevant packages. >> >> Using an NGZ means that zone only has control over ZFS datasets that the >> global zone lets it control. The zonecfg(1M) command man page has details >> on this. >> >> I use apache in a zone on my Home Server: >> >> >> http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html >> >> Dan >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Wed Apr 8 16:04:23 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Wed, 8 Apr 2015 18:04:23 +0200 Subject: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> References: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> Message-ID: Hi Svavar, that's interesting; Just for reference/comparison I'm too have a (spare machine with only its 2GB ECC HP factory RAM module and 20131001 ROM BIOS) HP MicroServer G7 - N40L - with the same onboard Broadcom Ethernet chip and I too upgraded flawlessly from OmniOS 151012 to 151014 the day before yesterday but, AFAIK, I can't see those bge0 notice logs. Here latest (bge0 related) logs after a cold start: Apr 8 17:20:40 nas01 genunix: [ID 469746 kern.info] NOTICE: bge0 registered Apr 8 17:20:40 nas01 genunix: [ID 586369 kern.info] PCIE-device: pci103c,705d at 0, bge0 Apr 8 17:20:40 nas01 genunix: [ID 236367 kern.info] PCI Express-device: pci103c,705d at 0, bge0 Apr 8 17:20:40 nas01 genunix: [ID 936769 kern.info] bge0 is /pci at 0 ,0/pci1022,9606 at 6/pci103c,705d at 0 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 580 us; 0x24208000->0x4208000 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 580 us; 0x243ca821->0x43ca821 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set after transaction; 0x8390000->0x24370f08 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 570 us; 0x24370f08->0x4370f08 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 580 us; 0x24290300->0x4290300 Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 630 us; 0x24201200->0x4201200 Apr 8 17:20:43 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_check_copper: link now down speed 0 duplex 0 Apr 8 17:20:44 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_check_copper: link now up speed 1000 duplex 2 Apr 8 17:20:44 nas01 genunix: [ID 435574 kern.info] NOTICE: bge0 link up, 1000 Mbps, full duplex prtconf -d System Configuration: Oracle Corporation i86pc Memory size: 2016 Megabytes System Peripherals (Software Nodes): i86pc scsi_vhci, instance #0 pci, instance #0 pci103c,1609 (pciex1022,9601) [Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge] (driver not attached) pci103c,9602 (pciex103c,9602) [Hewlett-Packard Company unknown device], instance #0 display (pci1002,9712) [Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]], instance #0 pci1022,9606 (pciex1022,9606) [Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)], instance #0 pci103c,705d (pciex14e4,165b) [Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe], instance #0 pci103c,1609 (pciex1002,4391) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]], instance #0 disk, instance #2 pci103c,1609 (pciex1002,4397) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller], instance #0 pci103c,1609 (pciex1002,4396) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller], instance #0 pci103c,1609 (pciex1002,4397) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller], instance #1 pci103c,1609 (pciex1002,4396) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller], instance #1 pci1002,4385 (pciex1002,4385) [Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller] (driver not attached) isa (pciex1002,439d) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller], instance #0 motherboard (driver not attached) pci1002,4384 (pciex1002,4384) [Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge], instance #1 pci103c,1609 (pciex1002,4397) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller], instance #2 pci103c,1609 (pciex1002,4396) [Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller], instance #2 pci1022,1200 (pciex1022,1200) [Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration] (driver not attached) pci1022,1201 (pciex1022,1201) [Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map] (driver not attached) pci1022,1202 (pciex1022,1202) [Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller] (driver not attached) pci1022,1203 (pciex1022,1203) [Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control] (driver not attached) pci1022,1204 (pciex1022,1204) [Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control] (driver not attached) fw, instance #0 cpu, instance #0 cpu, instance #1 sb (driver not attached) used-resources (driver not attached) iscsi, instance #0 agpgart, instance #0 (driver not attached) options, instance #0 pseudo, instance #0 dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE bge0 Ethernet up 1000 full bge0 dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE bge0 Ethernet up 1000 full bge0 dladm show-linkprop LINK PROPERTY PERM VALUE DEFAULT POSSIBLE bge0 speed r- 1000 1000 -- bge0 autopush rw -- -- -- bge0 zone rw -- -- -- bge0 duplex r- full full half,full bge0 state r- up up up,down bge0 adv_autoneg_cap rw 1 1 1,0 bge0 mtu rw 1500 1500 1500 bge0 flowctrl rw bi bi no,tx,rx,bi bge0 adv_10gfdx_cap r- -- 0 1,0 bge0 en_10gfdx_cap -- -- 0 1,0 bge0 adv_1000fdx_cap r- 1 0 1,0 bge0 en_1000fdx_cap rw 1 1 1,0 bge0 adv_1000hdx_cap r- 1 0 1,0 bge0 en_1000hdx_cap rw 1 1 1,0 bge0 adv_100fdx_cap r- 1 0 1,0 bge0 en_100fdx_cap rw 1 1 1,0 bge0 adv_100hdx_cap r- 1 0 1,0 bge0 en_100hdx_cap rw 1 1 1,0 bge0 adv_10fdx_cap r- 1 0 1,0 bge0 en_10fdx_cap rw 1 1 1,0 bge0 adv_10hdx_cap r- 1 0 1,0 bge0 en_10hdx_cap rw 1 1 1,0 bge0 maxbw rw -- -- -- bge0 cpus rw -- -- -- bge0 cpus-effective r- 0-1 -- -- bge0 pool rw -- -- -- bge0 pool-effective r- -- -- -- bge0 priority rw high high low,medium,high bge0 tagmode rw vlanonly vlanonly normal,vlanonly bge0 forward rw 1 1 1,0 bge0 default_tag rw 1 1 -- bge0 learn_limit rw 1000 1000 -- bge0 learn_decay rw 200 200 -- bge0 stp rw 1 1 1,0 bge0 stp_priority rw 128 128 -- bge0 stp_cost rw auto auto -- bge0 stp_edge rw 1 1 1,0 bge0 stp_p2p rw auto auto true,false,auto bge0 stp_mcheck rw 0 0 1,0 bge0 protection rw -- -- mac-nospoof,restricted,ip-nospoof,dhcp-nospoof bge0 allowed-ips rw -- -- -- bge0 allowed-dhcp-cids rw -- -- -- bge0 rxrings rw -- -- -- bge0 rxrings-effective r- -- -- -- bge0 txrings rw -- -- -- bge0 txrings-effective r- -- -- -- bge0 txrings-available r- 0 -- -- bge0 rxrings-available r- 0 -- -- bge0 rxhwclnt-available r- 0 -- -- bge0 txhwclnt-available r- 0 -- -- All looks OK to me. Regards, Davide. On Wed, Apr 8, 2015 at 4:54 PM, Svavar ?rn Eysteinsson wrote: > Thanks for the quick reply. > > Here's my prtconf from the HP microserver : > > System Configuration: Oracle Corporation i86pc > Memory size: 16352 Megabytes > System Peripherals (Software Nodes): > > i86pc > scsi_vhci, instance #0 > pci, instance #0 > pci103c,1609 (pciex1022,9601) [Advanced Micro Devices, Inc. [AMD] > RS880 Host Bridge] (driver not attached) > pci103c,9602 (pciex103c,9602) [Hewlett-Packard Company unknown > device], instance #0 > display (pci1002,9712) [Advanced Micro Devices, Inc. [AMD/ATI] > RS880M [Mobility Radeon HD 4225/4250]], instance #0 > pci1022,9606 (pciex1022,9606) [Advanced Micro Devices, Inc. [AMD] > RS780 PCI to PCI bridge (PCIE port 2)], instance #0 > pci103c,705d (pciex14e4,165b) [Broadcom Corporation NetXtreme > BCM5723 Gigabit Ethernet PCIe], instance #0 > > > Thanks again. > > BR, > > Svavar O > > > > > > On 8. apr. 2015, at 14:33, Dan McDonald wrote: > > > > What does "prtconf -d" say about which model number your Broadcom/bge is? > > > > There was a massive bge update in the 014 release. Perhaps some error > path should be less chatty? > > > > I'm including the illumos developer's list, just in case. > > > > Pardon the top-post, > > Dan > > > > > >> On Apr 8, 2015, at 5:36 AM, Svavar ?rn Eysteinsson < > svavar at pipar-tbwa.is> wrote: > >> > >> > >> Hello List. > >> > >> I recently upgraded my OmniOS installation from 1012 to 1014 on my HP > Microserver N40L. > >> Everything went smooth and everything seems OK and solid. > >> > >> There are tho, these messages that appear in my logs every now and then > regarding the network controller (bge0) : > >> > >> Apr 7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x2c - not updated? > >> Apr 7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x86 - not updated? > >> Apr 7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x94 - not updated? > >> Apr 7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xc2 - not updated? > >> Apr 7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x6a - not updated? > >> Apr 7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x4b - not updated? > >> Apr 7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x68 - not updated? > >> Apr 7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x38 - not updated? > >> Apr 7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x6 - not updated? > >> Apr 7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xa8 - not updated? > >> Apr 7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xbb - not updated? > >> Apr 7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xde - not updated? > >> Apr 7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xb9 - not updated? > >> Apr 7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x62 - not updated? > >> Apr 7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x26 - not updated? > >> Apr 7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x57 - not updated? > >> Apr 7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x3e - not updated? > >> Apr 7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xe8 - not updated? > >> Apr 7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xe2 - not updated? > >> Apr 7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xab - not updated? > >> Apr 7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x1c - not updated? > >> Apr 7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x2a - not updated? > >> Apr 7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x65 - not updated? > >> Apr 7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xd7 - not updated? > >> Apr 7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xea - not updated? > >> Apr 7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xb - not updated? > >> Apr 7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xaf - not updated? > >> Apr 7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x3d - not updated? > >> Apr 7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xbb - not updated? > >> Apr 7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x3e - not updated? > >> Apr 7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xa4 - not updated? > >> Apr 7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xae - not updated? > >> Apr 7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xdd - not updated? > >> Apr 7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x57 - not updated? > >> Apr 7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x50 - not updated? > >> Apr 7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x80 - not updated? > >> Apr 7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x30 - not updated? > >> Apr 7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x2a - not updated? > >> Apr 7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xb2 - not updated? > >> Apr 7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xde - not updated? > >> Apr 7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x41 - not updated? > >> Apr 7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x8 - not updated? > >> Apr 7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xb9 - not updated? > >> Apr 7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xe6 - not updated? > >> Apr 7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x5b - not updated? > >> Apr 7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xe9 - not updated? > >> Apr 7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x88 - not updated? > >> Apr 7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xfb - not updated? > >> Apr 7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xb4 - not updated? > >> Apr 7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x3e - not updated? > >> Apr 7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x5c - not updated? > >> Apr 8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x2e - not updated? > >> Apr 8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xd2 - not updated? > >> Apr 8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x38 - not updated? > >> Apr 8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x24 - not updated? > >> Apr 8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0xcd - not updated? > >> Apr 8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: > interrupt: flags 0x48 - not updated? > >> > >> Does anyone know what these interrupt - not updates messages mean ? > >> I have never seen them before, until after the 1014 update. > >> > >> dladm shows : > >> LINK MEDIA STATE SPEED DUPLEX DEVICE > >> bge0 Ethernet up 1000 full bge0 > >> > >> dladm show-link -s : > >> LINK IPACKETS RBYTES IERRORS OPACKETS OBYTES > OERRORS > >> bge0 13344422 2915541511 0 15403475 1025837411 0 > >> > >> > >> Thanks in advance. > >> > >> Best regards, > >> > >> Svavar O > >> Reykjavik - Iceland > >> > >> _______________________________________________ > >> OmniOS-discuss mailing list > >> OmniOS-discuss at lists.omniti.com > >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Wed Apr 8 17:57:57 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Wed, 8 Apr 2015 10:57:57 -0700 Subject: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade In-Reply-To: <20150407164008.9956A7A00D3@apps0.cs.toronto.edu> References: <20150407164008.9956A7A00D3@apps0.cs.toronto.edu> Message-ID: > On Apr 7, 2015, at 9:40 AM, Chris Siebenmann wrote: > >> History lesson: until people could afford to purchase more than one >> disk and before Sun invented the diskless workstation (with shared >> /usr), everything was under /. > > As Richard knows but other people may not, this is ahistorical on > Unix. From almost the beginning[*] Unix had a split between the root > filesystem and the /usr filesystem, based (as far as I understand > it) on the physical disks involved at Bell Labs CSRG on their Unix > machine. This is part of why the split of commands between /bin and > /usr/bin existed for years. Sun's diskless machines did not invent a > split /usr, they just took advantage of existing practice and made it > read-only and shared. Splitting some hairs... originally the OS was in / and user programs in /usr (hence the name) It was later that the thing we now call the "OS" moved to /usr. Now the "OS" is moving elsewhere, invading as it goes, as Volker described rather well. The key point is that trying to use filesystem(5) as written only works if everyone uses it, and they don't :-( with /opt being the perfect example of organizational dysfunction. The packaging system doesn't matter as it just sweeps the dust under the rug. IMHO the companies that solve this take the reductionist path: one file system. When done well, upgrades and installation are painless and my grandmother has no problem upgrading her phone without assistance. My approach to creating filesystems is based on policies to be applied, where those policies are fundamental to filesystems. Harkening back to the diskless workstation example or the more modern SmartOS model, there can be a readonly policy for the fixed OS bits that are replaced en masse. Other common policy knobs include: quota, reservation, backup, dedup, compression. Back to the problems at hand: 1. BE managing /opt as if it was its own, exclusive, waterfront resort. IMHO trying to assert an upgrade en masse policy to /opt is futile. Oracle's hack in Solaris 11.2 just kicks the can down the street. 2. Saving space for dumps. Don't waste time dumping to ZFS, setup a dump device on a raw partition somewhere. No need to mirror it or back it up. -- richard From johan.kragsterman at capvert.se Wed Apr 8 18:19:28 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Wed, 8 Apr 2015 20:19:28 +0200 Subject: [OmniOS-discuss] Ang: [developer] Re: Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> References: <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is>, <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> Message-ID: Hi! -----Svavar ?rn Eysteinsson skrev: ----- Till: Dan McDonald Fr?n: Svavar ?rn Eysteinsson Datum: 2015-04-08 17:41 Kopia: "omnios-discuss at lists.omniti.com" , _illumos-dev ?rende: [developer] Re: [OmniOS-discuss] Strange bge0 messages in syslog. interrupt, flags - not updated? Thanks for the quick reply. Here's my prtconf from the HP microserver : System Configuration: ?Oracle Corporation ?i86pc Memory size: 16352 Megabytes System Peripherals (Software Nodes): i86pc ?? ?scsi_vhci, instance #0 ?? ?pci, instance #0 ?? ? ? ?pci103c,1609 (pciex1022,9601) [Advanced Micro Devices, Inc. [AMD] RS880 Host Bridge] (driver not attached) ?? ? ? ?pci103c,9602 (pciex103c,9602) [Hewlett-Packard Company unknown device], instance #0 ?? ? ? ? ? ?display (pci1002,9712) [Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250]], instance #0 ?? ? ? ?pci1022,9606 (pciex1022,9606) [Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)], instance #0 ?? ? ? ? ? ?pci103c,705d (pciex14e4,165b) [Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe], instance #0 ? Thanks again. BR, Svavar O I actually got the same msg on one of my boxes, a Dell T5500 workstation, westmere CPU's. The machine was running for a couple of hours, before I started som heavier work, involving the bge interface. There were no logs about this before I started the more serious work. After I started it, they showed up, but not in great numbers. Like this: pr 8 20:04:33 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x33 - not updated? Apr 8 20:05:09 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd8 - not updated? Apr 8 20:06:01 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4 - not updated? Apr 8 20:06:33 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x7e - not updated? Apr 8 20:10:04 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xac - not updated? Apr 8 20:10:22 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x22 - not updated? Apr 8 20:10:25 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x54 - not updated? Apr 8 20:19:55 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? Apr 8 20:20:46 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xf1 - not updated? Apr 8 20:20:51 omni2 genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x59 - not updated? > On 8. apr. 2015, at 14:33, Dan McDonald wrote: > > What does "prtconf -d" say about which model number your Broadcom/bge is? > > There was a massive bge update in the 014 release. ?Perhaps some error path should be less chatty? > > I'm including the illumos developer's list, just in case. > > Pardon the top-post, > Dan > > >> On Apr 8, 2015, at 5:36 AM, Svavar ?rn Eysteinsson wrote: >> >> >> Hello List. >> >> I recently upgraded my OmniOS installation from 1012 to 1014 on my HP Microserver N40L. >> Everything went smooth and everything seems OK and solid. >> >> There are tho, these messages that appear in my logs every now and then regarding the network controller (bge0) : >> >> Apr ?7 15:12:33 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2c - not updated? >> Apr ?7 15:15:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x86 - not updated? >> Apr ?7 15:17:13 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x94 - not updated? >> Apr ?7 15:22:46 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xc2 - not updated? >> Apr ?7 15:36:25 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6a - not updated? >> Apr ?7 15:37:57 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x4b - not updated? >> Apr ?7 15:42:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x68 - not updated? >> Apr ?7 15:42:14 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >> Apr ?7 15:42:38 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x6 - not updated? >> Apr ?7 15:44:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa8 - not updated? >> Apr ?7 15:45:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >> Apr ?7 15:48:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >> Apr ?7 15:50:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >> Apr ?7 15:50:58 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x62 - not updated? >> Apr ?7 15:52:08 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x26 - not updated? >> Apr ?7 15:52:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >> Apr ?7 15:53:10 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr ?7 15:54:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe8 - not updated? >> Apr ?7 15:54:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe2 - not updated? >> Apr ?7 15:55:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xab - not updated? >> Apr ?7 16:01:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x1c - not updated? >> Apr ?7 17:53:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >> Apr ?7 18:24:48 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x65 - not updated? >> Apr ?7 18:51:17 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd7 - not updated? >> Apr ?7 18:51:27 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xea - not updated? >> Apr ?7 18:52:07 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb - not updated? >> Apr ?7 18:57:35 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xaf - not updated? >> Apr ?7 18:58:22 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3d - not updated? >> Apr ?7 18:58:50 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xbb - not updated? >> Apr ?7 18:59:37 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr ?7 19:00:23 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xa4 - not updated? >> Apr ?7 19:01:02 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xae - not updated? >> Apr ?7 19:01:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xdd - not updated? >> Apr ?7 19:15:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x57 - not updated? >> Apr ?7 19:19:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x50 - not updated? >> Apr ?7 19:59:40 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x80 - not updated? >> Apr ?7 20:00:31 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x30 - not updated? >> Apr ?7 20:01:30 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2a - not updated? >> Apr ?7 20:06:51 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb2 - not updated? >> Apr ?7 20:17:15 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xde - not updated? >> Apr ?7 20:30:29 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x41 - not updated? >> Apr ?7 21:11:20 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x8 - not updated? >> Apr ?7 21:33:05 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb9 - not updated? >> Apr ?7 21:39:59 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe6 - not updated? >> Apr ?7 21:51:03 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5b - not updated? >> Apr ?7 21:59:47 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xe9 - not updated? >> Apr ?7 22:05:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x88 - not updated? >> Apr ?7 22:30:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xfb - not updated? >> Apr ?7 22:52:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xb4 - not updated? >> Apr ?7 22:56:43 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x3e - not updated? >> Apr ?7 23:03:00 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x5c - not updated? >> Apr ?8 00:34:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x2e - not updated? >> Apr ?8 01:00:39 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xd2 - not updated? >> Apr ?8 03:20:28 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x38 - not updated? >> Apr ?8 03:55:45 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x24 - not updated? >> Apr ?8 05:00:06 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0xcd - not updated? >> Apr ?8 08:42:54 blackbox genunix: [ID 801725 kern.info] NOTICE: bge0: interrupt: flags 0x48 - not updated? >> >> Does anyone know what these interrupt - not updates messages mean ? >> I have never seen them before, until after the 1014 update. >> >> dladm shows : >> LINK ? ? ? ? MEDIA ? ? ? ? ? ? ? ?STATE ? ? ?SPEED ?DUPLEX ? ?DEVICE >> bge0 ? ? ? ? Ethernet ? ? ? ? ? ? up ? ? ? ? 1000 ? full ? ? ?bge0 >> >> dladm show-link -s : >> LINK ? ? ? ? ? IPACKETS ?RBYTES ?IERRORS ? OPACKETS ? ?OBYTES ? ? ?OERRORS >> bge0 ? ? ? ? ? 13344422 ?2915541511 0 ? ? ?15403475 ? ?1025837411 ?0 >> >> >> Thanks in advance. >> >> Best regards, >> >> Svavar O >> Reykjavik - Iceland >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > ------------------------------------------- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/23755348-1998767f Modify Your Subscription: https://www.listbox.com/member/?member_id=23755348&id_secret=23755348-0bb51dcb Powered by Listbox: http://www.listbox.com From eric.sproul at circonus.com Wed Apr 8 18:39:20 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Wed, 8 Apr 2015 14:39:20 -0400 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version Message-ID: FYI, just something I noticed that I've discovered I have to account for as I work on Circonus support for r151014... The updated pkg(5) in 014 changes the default format for versions in `pkg list -v` output. Previously, the format was: component,build-branch:timestamp now it appears to be: component-branch:timestamp For example, here's one of our packages on 006 vs. 014. I've omitted the timestamps for clarity: pkg://circonus/platform/runtime/nodejs at 0.10.38,5.11-0.151006 pkg://circonus/platform/runtime/nodejs at 0.10.38-0.151014 The build version ("5.11") is now omitted. This is fine, as it rarely, if ever changes, and we usually care much more about the other two. This did, however, spoil some regexes I use to determine installed versions of dependent packages (for things that pkgdepend(1) doesn't cover). If you do something similar in your own packaging builds, watch out for this. I haven't dug into the commit history on current pkg(5) to find out when/why it changed, but if anyone knows, I'd be interested, just to satisfy my curiosity. Eric From lotheac at iki.fi Wed Apr 8 18:59:38 2015 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 8 Apr 2015 21:59:38 +0300 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version In-Reply-To: References: Message-ID: <20150408185938.GA25397@gutsman.lotheac.fi> On Wed, Apr 08 2015 14:39:20 -0400, Eric Sproul wrote: > The updated pkg(5) in 014 changes the default format for versions in > `pkg list -v` output. Previously, the format was: > > component,build-branch:timestamp > > now it appears to be: > > component-branch:timestamp Good catch, thanks for the heads up. The build version has also been removed from pkg info output (both the separate line as well as the version in the FMRI). I'm also interested in the history; pkg(5) does still document that the build version is part of the FMRI. -- Lauri Tirkkonen | lotheac @ IRCnet From danmcd at omniti.com Wed Apr 8 19:01:19 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Apr 2015 15:01:19 -0400 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version In-Reply-To: References: Message-ID: <36FA2B93-24A3-4C5E-B319-5D9CFDEFA754@omniti.com> We took a LOT of changes in modernizing. The new pkg5 repo is github.com/omniti-labs/pkg5. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 8, 2015, at 2:39 PM, Eric Sproul wrote: > > FYI, just something I noticed that I've discovered I have to account > for as I work on Circonus support for r151014... > > The updated pkg(5) in 014 changes the default format for versions in > `pkg list -v` output. Previously, the format was: > > component,build-branch:timestamp > > now it appears to be: > > component-branch:timestamp > > For example, here's one of our packages on 006 vs. 014. I've omitted > the timestamps for clarity: > > pkg://circonus/platform/runtime/nodejs at 0.10.38,5.11-0.151006 > pkg://circonus/platform/runtime/nodejs at 0.10.38-0.151014 > > The build version ("5.11") is now omitted. This is fine, as it > rarely, if ever changes, and we usually care much more about the other > two. This did, however, spoil some regexes I use to determine > installed versions of dependent packages (for things that pkgdepend(1) > doesn't cover). If you do something similar in your own packaging > builds, watch out for this. > > I haven't dug into the commit history on current pkg(5) to find out > when/why it changed, but if anyone knows, I'd be interested, just to > satisfy my curiosity. > > Eric > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Apr 8 20:03:44 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 8 Apr 2015 16:03:44 -0400 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version In-Reply-To: <20150408185938.GA25397@gutsman.lotheac.fi> References: <20150408185938.GA25397@gutsman.lotheac.fi> Message-ID: <20A497D9-FDF4-4CF3-896A-D941A31EA9B6@omniti.com> > On Apr 8, 2015, at 2:59 PM, Lauri Tirkkonen wrote: > > On Wed, Apr 08 2015 14:39:20 -0400, Eric Sproul wrote: >> The updated pkg(5) in 014 changes the default format for versions in >> `pkg list -v` output. Previously, the format was: >> >> component,build-branch:timestamp >> >> now it appears to be: >> >> component-branch:timestamp > > Good catch, thanks for the heads up. The build version has also been > removed from pkg info output (both the separate line as well as the > version in the FMRI). I'm also interested in the history; pkg(5) does > still document that the build version is part of the FMRI. THE BIG QUESTION is whether or not it's something worth fixing, or just something worth documenting more. Alas, we don't have insight into Oracle's thinking here, but somebody thought it would be a good idea. Here's the commit: commit 70a649f9f2f9702950b250e1add20d2732df6b94 Author: Yiteng Zhang Date: Fri Sep 27 11:38:34 2013 -0700 16851082 build_release (aka build version) should not be displayed src/client.py | 31 ++++++++++++++++++++++--------- src/modules/actions/depend.py | 10 ++++------ src/modules/catalog.py | 29 +++++++++-------------------- src/modules/client/api.py | 37 ++++++++++++++----------------------- src/modules/client/image.py | 23 +++++++---------------- src/modules/client/imageplan.py | 39 +++++++++++++-------------------------- src/modules/client/linkedimage/common.py | 5 +---- src/modules/client/pkg_solver.py | 15 +++++++-------- src/modules/config.py | 2 +- src/modules/fmri.py | 7 ++++--- src/modules/lint/engine.py | 3 +-- src/modules/lint/pkglint_action.py | 8 +++----- src/modules/lint/pkglint_manifest.py | 5 ++--- src/modules/manifest.py | 3 +-- src/modules/mediator.py | 6 +++--- src/modules/publish/dependencies.py | 25 ++++++++++++------------- src/modules/server/api.py | 6 +++--- src/modules/version.py | 35 +++++++++++++++-------------------- src/pkgrepo.py | 15 ++++++++++++--- src/publish.py | 2 +- src/pull.py | 7 ++++--- src/sign.py | 3 ++- src/tests/api/t_api_list.py | 10 ++++------ src/tests/api/t_catalog.py | 8 ++++---- src/tests/api/t_fmri.py | 19 +++++++------------ src/tests/api/t_p5i.py | 2 +- src/tests/api/t_pkg_api_install.py | 2 +- src/tests/api/t_version.py | 8 +------- src/tests/cli/t_depot_config.py | 4 +++- src/tests/cli/t_fix.py | 2 +- src/tests/cli/t_pkg_composite.py | 3 +-- src/tests/cli/t_pkg_info.py | 47 +++++++++++++++++------------------------------ src/tests/cli/t_pkg_install.py | 4 ++-- src/tests/cli/t_pkg_linked.py | 6 +++--- src/tests/cli/t_pkg_temp_sources.py | 24 ++++++++++++------------ src/tests/cli/t_pkgdep_resolve.py | 2 +- src/tests/cli/t_pkgmerge.py | 8 ++++---- src/tests/cli/t_pkgrecv.py | 16 ++++++++++------ src/tests/cli/t_pkgrepo.py | 49 ++++++++++++++++++++++++++++++++++++++----------- src/tests/cli/t_pkgsend.py | 8 ++++---- src/tests/cli/t_publish_api.py | 4 ++-- src/tests/cli/t_util_merge.py | 2 +- src/tests/perf/fmribench.py | 6 +++--- src/tests/perf/membench.py | 4 ++-- src/util/publish/pkglint.py | 3 +-- src/util/publish/pkgmerge.py | 14 ++++---------- src/util/publish/pkgsurf.py | 8 ++++---- src/web/en/catalog.shtml | 2 +- src/web/en/search.shtml | 2 +- 49 files changed, 274 insertions(+), 309 deletions(-) That's a LOT of changes. A quick "git revert" test showed only one file in conflict, oddly enough. It might be worth trying to build this change and generate a webrev for inspection. Dan From lotheac at iki.fi Wed Apr 8 20:12:39 2015 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 8 Apr 2015 23:12:39 +0300 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version In-Reply-To: <20A497D9-FDF4-4CF3-896A-D941A31EA9B6@omniti.com> References: <20150408185938.GA25397@gutsman.lotheac.fi> <20A497D9-FDF4-4CF3-896A-D941A31EA9B6@omniti.com> Message-ID: <20150408201239.GB25397@gutsman.lotheac.fi> On Wed, Apr 08 2015 16:03:44 -0400, Dan McDonald wrote: > THE BIG QUESTION is whether or not it's something worth fixing, or > just something worth documenting more. Yeah, I don't think it's worth reverting, especially if there are conflicts; the build version, like Eric said, doesn't really change. pkg(5) from 151006 as well as 151014 also has this to say: Many parts of the system, when appropriate, abridge FMRIs when displaying them, and accept input in shorter forms to reduce the volume of information displayed or required. Typically, the scheme, publisher, build version, and timestamp can be elided. It's just something to be aware of. I do remember testing whether it was possible to publish packages which omit branch and release versions back when I was patching a certain piece of configuration management software to handle pkg versions properly, and on 151006 pkg it was, so I built my regexes accordingly. Luckily, it seems. -- Lauri Tirkkonen | lotheac @ IRCnet From eric.sproul at circonus.com Wed Apr 8 20:25:59 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Wed, 8 Apr 2015 16:25:59 -0400 Subject: [OmniOS-discuss] Newer pkg list -v no longer displays build version In-Reply-To: <20150408201239.GB25397@gutsman.lotheac.fi> References: <20150408185938.GA25397@gutsman.lotheac.fi> <20A497D9-FDF4-4CF3-896A-D941A31EA9B6@omniti.com> <20150408201239.GB25397@gutsman.lotheac.fi> Message-ID: On Wed, Apr 8, 2015 at 4:12 PM, Lauri Tirkkonen wrote: > It's just something to be aware of. I do remember testing whether it was > possible to publish packages which omit branch and release versions back > when I was patching a certain piece of configuration management software > to handle pkg versions properly, and on 151006 pkg it was, so I built my > regexes accordingly. Luckily, it seems. I concur. No need to rebuild or maintain a difference from upstream for that. Since the number of components in the version can now vary, I opted for a series of substring operations in bash rather than a single sed invocation, e.g. pkgver=`pkg list -Hv $pkg 2>/dev/null` pkgver=${pkgver#*@} # trim up thru '@' pkgver=${pkgver%:*} # trim off ':' and after pkgver=${pkgver//,5.11/} # eliminate build version, if present This works on both 006 and 014. Eric From KBruene at simmonsperrine.com Thu Apr 9 19:00:18 2015 From: KBruene at simmonsperrine.com (Kyle Bruene) Date: Thu, 9 Apr 2015 19:00:18 +0000 Subject: [OmniOS-discuss] SMART info Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> Could anyone give me info on getting SMART info about SATA SSD's connected via expanders to an LSI controller in IT mode? I am trying to find how worn these are. Thanks. From danmcd at omniti.com Thu Apr 9 19:05:58 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Apr 2015 15:05:58 -0400 Subject: [OmniOS-discuss] SMART info In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> Message-ID: > On Apr 9, 2015, at 3:00 PM, Kyle Bruene wrote: > > Could anyone give me info on getting SMART info about SATA SSD's connected via expanders to an LSI controller in IT mode? I am trying to find how worn these are. Thanks. Collected wisdom generally is do not plug in SATA drives into an expander. Expanders don't know how to forward SATA commands, which causes the problems you're seeing. Save yourself pain and either use directly-attached AHCI SATA, or get SAS drives. Sorry for being blunt, but too many people have been burned this way. Dan From lkateley at kateley.com Thu Apr 9 19:34:28 2015 From: lkateley at kateley.com (Linda Kateley) Date: Thu, 09 Apr 2015 14:34:28 -0500 Subject: [OmniOS-discuss] SMART info In-Reply-To: References: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> Message-ID: <5526D444.6070809@kateley.com> There isn't smartctl in omni, is there Dan? Omni uses it's own fault management tools. fmadm faulty or repaired or iostat -e might give some hints on disk errors, but i am not aware of any disk querying tools like smart. format might also be able to give you some data. lk On 4/9/15 2:05 PM, Dan McDonald wrote: >> On Apr 9, 2015, at 3:00 PM, Kyle Bruene wrote: >> >> Could anyone give me info on getting SMART info about SATA SSD's connected via expanders to an LSI controller in IT mode? I am trying to find how worn these are. Thanks. > Collected wisdom generally is do not plug in SATA drives into an expander. Expanders don't know how to forward SATA commands, which causes the problems you're seeing. Save yourself pain and either use directly-attached AHCI SATA, or get SAS drives. > > Sorry for being blunt, but too many people have been burned this way. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Thu Apr 9 19:50:00 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Apr 2015 15:50:00 -0400 Subject: [OmniOS-discuss] SMART info In-Reply-To: <5526D444.6070809@kateley.com> References: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> <5526D444.6070809@kateley.com> Message-ID: <15426FAE-B33B-4E4E-9064-1682F101D342@omniti.com> > On Apr 9, 2015, at 3:34 PM, Linda Kateley wrote: > > There isn't smartctl in omni, is there Dan? In the optional, used by us internally, but not officially supported, omniti-ms publisher: bloody(usr/src)[0]% pkg search smartctl INDEX ACTION VALUE PACKAGE basename file opt/omni/sbin/i386/smartctl pkg:/omniti/system/storage/smartmontools at 6.2-0.151010 . . . Dan From omnios at citrus-it.net Thu Apr 9 20:13:41 2015 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 9 Apr 2015 20:13:41 +0000 (UTC) Subject: [OmniOS-discuss] SMART info In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> Message-ID: On Thu, 9 Apr 2015, Kyle Bruene wrote: ; Could anyone give me info on getting SMART info about SATA SSD's connected via expanders to an LSI controller in IT mode? I am trying to find how worn these are. Thanks. I've found the need to add '-d sat,12' to the smartctl arguments in the past. That might be able to get some more information from the drive. Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at omniti.com Thu Apr 9 20:52:19 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 9 Apr 2015 16:52:19 -0400 Subject: [OmniOS-discuss] r151014 KVM crash In-Reply-To: References: Message-ID: > On Apr 6, 2015, at 4:20 AM, Johan Kragsterman wrote: > > > One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. I've been running KVM on my 014 build box for the past day or two. I've encountered one problem similar to your so far. It manifests in boot time, where I will see this message while the guest kernel (OpenIndiana in this case) loads: microfind: cpu is too fast and get an instant, no-core-dump reboot. I can catch this in KMDB and have the debugger available to me. In illumos this can occur one of two places: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/io/microfind.c#117 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/io/microfind.c#193 Both are in the microfind areas. I don't know this area of the kernel very well, but I know people who do. One thing *I* did was restart my qemu process. Once I did that things *appeared* to be back to normal. I'm running my KVM in the global zone currently, with this script (a variation of the one we provide on the OmniOS wiki): -------------- r151014(~)[0]% cat oi-start.sh #!/usr/bin/bash ## NOTE: This must be run as super user. # configuration VNIC=oi0 # Sample zvol path. ROOTHDD=/dev/zvol/dsk/rpool/oi-disk DATAHDD=/dev/zvol/dsk/data/oi-data-disk CD=/export/home/danmcd/isos/oi-dev-151a8-text-x86.iso VNC=1 # Memory for the KVM instance, in Megabytes (2^20 bytes). MEM=8192 MAC=`dladm show-vnic -po macaddress $VNIC` #NOTE: Add # -boot cd \ # between -name and -enable-kvm if need be. /usr/bin/qemu-system-x86_64 \ -name "$(basename $CD)" \ -enable-kvm \ -vnc 0.0.0.0:$VNC \ -smp 4 \ -m $MEM \ -no-hpet \ -localtime \ -drive file=$ROOTHDD,if=ide,index=0 \ -drive file=$DATAHDD,if=ide,index=1 \ -drive file=$CD,media=cdrom,if=ide,index=2 \ -net nic,vlan=0,name=net0,model=e1000,macaddr=$MAC \ -net vnic,vlan=0,name=net0,ifname=$VNIC \ -vga std \ -daemonize if [ $? -gt 0 ]; then echo "Failed to start VM" fi # UDP port for VNC connections to the KVM instance. 5900 is added in the command. port=`expr 5900 + $VNC` public_nic=$(dladm show-vnic|grep vnic1|awk '{print $2}') public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') echo "Started VM:" echo "Public: ${public_ip}:${port}" ----------------- I did not directly correspond these to error messages of your sort, but the times looks right. I'm curious myself as to what these might be. Dan From brogyi at gmail.com Fri Apr 10 06:32:40 2015 From: brogyi at gmail.com (=?windows-1252?Q?Brogy=E1nyi_J=F3zsef?=) Date: Fri, 10 Apr 2015 08:32:40 +0200 Subject: [OmniOS-discuss] SMART info In-Reply-To: References: <202C92988C5CF249BD3F9F21B2B199CB33EC4B06@SPMAIL1.spae.local> Message-ID: <55276E88.6010504@gmail.com> Why not compile the smart? It's so simple. Our system it's working but not omni. I used it on Openindiana and Hipster. I tested our SSD in short time then I give up it uses. My system used 150GB/day. I decided I give up the usage. The 199 error message shows me the bad IT version. Definitely not HDD error. Now that counter is stopped. This command is working too: root at hipster:/home/brogyi# smartctl -A -d sat,12 /dev/rdsk/c8t50014EE003CCD190d0 smartctl 6.3 2014-07-26 r3976 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 178 176 021 Pre-fail Always - 6075 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 78 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 5921 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 78 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 77 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 0 194 Temperature_Celsius 0x0022 112 105 000 Old_age Always - 38 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 195 000 Old_age Always - 14542 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 > > On Thu, 9 Apr 2015, Kyle Bruene wrote: > > ; Could anyone give me info on getting SMART info about SATA SSD's connected via expanders to an LSI controller in IT mode? I am trying to find how worn these are. Thanks. > > I've found the need to add '-d sat,12' to the smartctl arguments in the > past. That might be able to get some more information from the drive. > > Andy > From johan.kragsterman at capvert.se Fri Apr 10 07:06:17 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Fri, 10 Apr 2015 09:06:17 +0200 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: References: , Message-ID: Hi Dan and list! I've been doing some more research on this, see further down. -----Dan McDonald skrev: ----- Till: Johan Kragsterman Fr?n: Dan McDonald Datum: 2015-04-09 22:52 Kopia: "omnios-discuss at lists.omniti.com" , Dan McDonald ?rende: Re: [OmniOS-discuss] r151014 KVM crash > On Apr 6, 2015, at 4:20 AM, Johan Kragsterman wrote: > > > One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. I've been running KVM on my 014 build box for the past day or two. I've encountered one problem similar to your so far. ?It manifests in boot time, where I will see this message while the guest kernel (OpenIndiana in this case) loads: microfind: cpu is too fast and get an instant, no-core-dump reboot. ?I can catch this in KMDB and have the debugger available to me. ?In illumos this can occur one of two places: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/io/microfind.c#117 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/io/microfind.c#193 Both are in the microfind areas. ?I don't know this area of the kernel very well, but I know people who do. ?One thing *I* did was restart my qemu process. ?Once I did that things *appeared* to be back to normal. ?I'm running my KVM in the global zone currently, with this script (a variation of the one we provide on the OmniOS wiki): -------------- r151014(~)[0]% cat oi-start.sh #!/usr/bin/bash ## NOTE: ?This must be run as super user. # configuration VNIC=oi0 # Sample zvol path. ROOTHDD=/dev/zvol/dsk/rpool/oi-disk DATAHDD=/dev/zvol/dsk/data/oi-data-disk CD=/export/home/danmcd/isos/oi-dev-151a8-text-x86.iso VNC=1 # Memory for the KVM instance, in Megabytes (2^20 bytes). MEM=8192 MAC=`dladm show-vnic -po macaddress $VNIC` #NOTE: Add # -boot cd \ # between -name and -enable-kvm if need be. /usr/bin/qemu-system-x86_64 \ -name "$(basename $CD)" \ -enable-kvm \ -vnc 0.0.0.0:$VNC \ -smp 4 \ -m $MEM \ -no-hpet \ -localtime \ -drive file=$ROOTHDD,if=ide,index=0 \ -drive file=$DATAHDD,if=ide,index=1 \ -drive file=$CD,media=cdrom,if=ide,index=2 ?\ -net nic,vlan=0,name=net0,model=e1000,macaddr=$MAC \ -net vnic,vlan=0,name=net0,ifname=$VNIC \ -vga std \ -daemonize if [ $? -gt 0 ]; then ?? ?echo "Failed to start VM" fi # UDP port for VNC connections to the KVM instance. ?5900 is added in the command. port=`expr 5900 + $VNC` public_nic=$(dladm show-vnic|grep vnic1|awk '{print $2}') public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}') echo "Started VM:" echo "Public: ${public_ip}:${port}" ----------------- I did not directly correspond these to error messages of your sort, but the times looks right. ?I'm curious myself as to what these might be. Dan These pair of lines here under,were written to /var/adm/messages a little bit more than 1000 times/second, when I was on r151014. I'm not sure exactly when in the process they were written, but I guess it was under the quite heavy load of bulding chroot's and images in the VM, while the KVM process crashed. There doesn't seem to be a problem under more easy load. Apr ?4 16:26:09 omni2 genunix: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 16:26:09 omni2 genunix: [ID 391722 kern.info] unhandled wrmsr: 0x526dc5 d If it logs this much of the same, it looks serious to me, and it must effect the system, imho. It doesn't log this much at all under r151012, even on heavy load, and no crashes at all under r151012. There are no core dumps. I will do some further investigations, like building a new chroot, and follow the messages, and also pay attention to what the console say's after the VM have crashed(if it crashes again under the same conditions). Rgrds Johan Later.... I have now changed back again to r151014, and I seem to not be able to repete this behaviour. I have been building several chroot's and images, and doing updates in the way that earlier chrashed the KVM process, but I see no problem now, and no extensive logging. And therefore I don't have access to the consol messages I saw earlier, as well, unfortunatly... I don't know wether this is good or bad, that it seem to work now. It would have been good to know what caused the problems, but it is nice that it seems to work without problems now... Rgrds Johan From matej at zunaj.si Fri Apr 10 10:11:15 2015 From: matej at zunaj.si (Matej Zerovnik) Date: Fri, 10 Apr 2015 12:11:15 +0200 Subject: [OmniOS-discuss] iSCSI target hang, no way to restart but server reboot In-Reply-To: References: <5515562B.9090900@zunaj.si> <55156F23.2010300@zunaj.si> <17BBA672-FDF1-4F36-8011-79212B0EFD97@omniti.com> <55157137.2010909@zunaj.si> <9E6B85F8-7454-4DE2-87AF-28A5BAAF6A33@omniti.com> Message-ID: <5527A1C3.1070807@zunaj.si> On Wednesday, the server crashed again. We switched to a new server(same model xServer 3550 M4), installed OmniOS r14 and updates LSI firmware from P15 to P19. So far, everything is humming nicely, there are also no more errors in the logs (errors were from SAS expander and not from a particular drive, at least according to the target number). New SAS drives are in order, since we want to go HA as well. Thanks everyone for help and answers, Matej On 28. 03. 2015 04:51, Dave Pooser wrote: >> Having been on the receiving end of similar advice, it is a frustrating >> situation to be in, since you have (and will likely continue to have) the >> hardware in production, without much option for replacement. >> When we had systems like this, we had a lot of success being aggressive in >> swapping out disks that were showing signs of going bad, even before >> critical failures occurred. Also looking at SMART statistics, and >> aggressively replacing those as well. > > >> Aggressively replace devices implicated by these, and hope for the best. >> The best may or may not be what you're hoping for, but may be livable; it >> was for us. > Also bear in mind it's entirely possible to mix SAS and SATA drives in the > same enclosure and even the same vdev-- so as you're aggressively > replacing SATA drives replace them with SAS drives and your system will > become less brittle. Assuming you're using enterprise SATA drives, their > SAS siblings are not much more expensive (often about $20 difference) and > the reliability gains will be significant. From matej at zunaj.si Fri Apr 10 10:17:27 2015 From: matej at zunaj.si (Matej Zerovnik) Date: Fri, 10 Apr 2015 12:17:27 +0200 Subject: [OmniOS-discuss] Building a new storage Message-ID: <5527A337.5060405@zunaj.si> We are currently thinking of rebuilding our SAN, since we did some mistakes on the first build. But before we begin, we would like to plan accordingly, so I'm wondering how to measure some data(l2arc and zil usage, current iops,...) the right way. We currently have a single raidz2 pool build out of 50 SATA drives(Seagate Constellation, 2x Intel S3700 100GB as ZIL and 2x Intel S3700 100GB as L2ARC. For the new system, we plan to use a IBM 3550 M4 server with 256GB of memory and LSI SAS 9207-8e HBA. We will have around 70-80 SAS 4TB drives in JBOD cases and, if we need, some SSD's for ZIL and L2ARC. Questions: *1.)* How to measure average IOPS of the current system? 'zpool iostat poolname 1' gives me weird numbers saying current drives perform around 300 read ops and 100 write ops per second. Drives are 7200 SATA drives, so I know they can't perform that much IOPS. Output from iostat -vx (only some drives are pasted): Code: device r/s w/s kr/s kw/s wait actv svc_t %w %b data 36621,9 25740,2 19288,6 66191,0 197,6 25,9 3,6 40 77 sd18 276,3 104,8 145,2 83,3 0,0 0,6 1,5 0 36 sd19 283,3 106,7 152,1 83,3 0,0 0,6 1,5 0 24 sd20 281,3 101,8 146,7 79,8 0,0 0,5 1,4 0 35 sd21 286,3 117,7 146,7 84,3 0,0 0,3 0,7 0 21 sd22 283,3 85,8 144,2 81,3 0,0 0,5 1,3 0 32 sd23 275,3 116,7 139,7 82,8 0,0 0,3 0,8 0 21 sd24 280,3 106,7 155,6 84,3 0,0 0,6 1,6 0 25 sd25 288,3 106,7 148,6 86,3 0,0 0,4 1,0 0 24 sd26 269,4 110,7 137,2 91,8 0,0 0,5 1,3 0 24 sd27 272,4 87,8 141,7 78,3 0,0 0,7 1,8 0 34 sd28 236,4 115,7 219,0 84,8 0,0 0,9 2,5 0 26 sd29 235,4 108,7 228,5 83,8 0,0 0,9 2,7 0 33 Output of 'zpool iostat -v data 1 | grep drive_id' Code: capacity operations bandwidth pool alloc free read write read write c8t5000C5004FD18DE9d0 - - 573 220 663K 607K c8t5000C5004FD18DE9d0 - - 563 0 318K 0 c8t5000C5004FD18DE9d0 - - 586 314 361K 806K c8t5000C5004FD18DE9d0 - - 567 445 373K 1,02M c8t5000C5004FD18DE9d0 - - 464 25 299K 17,9K c8t5000C5004FD18DE9d0 - - 552 2 326K 3,68K c8t5000C5004FD18DE9d0 - - 421 41 249K 31,3K c8t5000C5004FD18DE9d0 - - 492 400 391K 944K c8t5000C5004FD18DE9d0 - - 313 148 242K 337K c8t5000C5004FD18DE9d0 - - 330 163 360K 390K c8t5000C5004FD18DE9d0 - - 655 23 577K 21,5K Is it just me, or are there too much IOPS for those drive to handle even in theory, let alone in practice? How to get the right measurement? *2.)* Current ARC utilization on our system: Code: ARC Efficency: Cache Access Total: 2134027465 Cache Hit Ratio: 64% 1381755042 [Defined State for buffer] Cache Miss Ratio: 35% 752272423 [Undefined State for Buffer] REAL Hit Ratio: 56% 1199175179 [MRU/MFU Hits Only] Code: ./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 1 2>/dev/null read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size 1 1 0 100 0 0 0 0 213G 235G 4.8K 3.0K 1.9K 61 1.9K 40 1.8K 2 213G 235G 4.3K 2.7K 1.6K 62 1.6K 35 1.5K 2 213G 235G 2.5K 853 1.6K 34 1.6K 45 1.6K 2 213G 235G 5.1K 3.0K 2.2K 57 2.2K 49 2.1K 2 213G 235G 6.5K 4.4K 2.1K 68 2.1K 30 2.0K 1 213G 235G 5.0K 2.5K 2.5K 49 2.5K 44 2.5K 1 213G 235G 11K 8.5K 2.8K 75 2.8K 13 2.8K 0 213G 235G 6.4K 4.8K 1.6K 74 1.6K 57 1.6K 3 213G 235G 2.3K 1.1K 1.2K 46 1.2K 88 1.1K 7 213G 235G 1.9K 532 1.3K 28 1.3K 83 1.2K 6 213G 235G As we can see, there are almost no L2ARC cache hits. What can be the reason for that? Is our L2ARC cache too small or are the data on our storage just too much random to be cached? I don't know what is on our iscsi shares, since they are for outside customers, but as far as I know, it's mostly backups and some live data. *3.)* As far as ZIL goes, do we need it? I think I read somewhere, that ZIL can only store 8k blocks and that you have to 'format' iscsi drives accordingly. Is that still the case? Output from 'zilstat': Code: N-Bytes N-Bytes/s N-Max-Rate B-Bytes B-Bytes/s B-Max-Rate ops <=4kB 4-32kB >=32kB 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 178352 178352 178352 262144 262144 262144 2 0 0 2 134823992 134823992 134823992 221380608 221380608 221380608 1689 0 0 1689 102893848 102893848 102893848 168427520 168427520 168427520 1285 0 0 1285 0 0 0 0 0 0 0 0 0 0 4472 4472 4472 131072 131072 131072 1 0 0 1 0 0 0 0 0 0 0 0 0 0 41904 41904 41904 262144 262144 262144 2 0 0 2 134963824 134963824 134963824 221511680 221511680 221511680 1690 0 0 1690 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 32789896 32789896 32789896 53346304 53346304 53346304 407 0 0 407 25467912 25467912 25467912 41811968 41811968 41811968 319 0 0 319 Given the stats, is ZIL even necessary? When I'm running zilstat, I see big ops every 5s. Why is that? I know system is suppose to flush data from memory to spindles every 5s, but that shouldn't be seen as ZIL flush, is that correct? *4.)* How to put drives together, to get the best IOPS/capacity ratio out of them? We were thinking of 7 RAIDZ2 vdev's with 10 drives each. That way we would get around 224TB pool. *5.)* In case we decide to go with 4 JBOD cases, would it be better to build 2 pools, just so that in case 1 pool has a hickup, we won't loose all data? What else am I not considering? Thanks, Matej -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasslerd at gmx.li Fri Apr 10 11:37:18 2015 From: hasslerd at gmx.li (Dominik Hassler) Date: Fri, 10 Apr 2015 13:37:18 +0200 Subject: [OmniOS-discuss] Manage SMF instances for (installed but not running) NGZ from GZ Message-ID: An HTML attachment was scrubbed... URL: From peter.tribble at gmail.com Fri Apr 10 12:00:30 2015 From: peter.tribble at gmail.com (Peter Tribble) Date: Fri, 10 Apr 2015 13:00:30 +0100 Subject: [OmniOS-discuss] Manage SMF instances for (installed but not running) NGZ from GZ In-Reply-To: References: Message-ID: Dominik, On Fri, Apr 10, 2015 at 12:37 PM, Dominik Hassler wrote: > Hi, > > I would like to manage (i.e. add/change properties) SMF instances for > non-global zones from the global zone. > > This works fine using '/usr/sbin/zlogin my-ngz /usr/sbin/svccfg...'. > However this only works if the NGZ is running. > > Afaik, there is no '-z' option for svccfg (there is one for svcadm > however...). > > Is it possible at all to manage SMF instances for non-global zones if the > NGZ is not running? > Sure. There's no command line option for this, but if you run svccfg interactively or with an input file of commands (via the -f option), use the repository subcommand to tell it to use the zone's repository (ie ${ZONEROOT}/etc/svc/repository.db) rather than the default. (Although my usual trick is to save the repository from a zone that's configured the way I want, and drop that into a new zone as I build it.) The other way would be to create a service profile, and then drop that into the zone ready to be picked up when the zone boots. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafibeyli at gmail.com Fri Apr 10 12:51:18 2015 From: rafibeyli at gmail.com (Hafiz Rafiyev) Date: Fri, 10 Apr 2015 15:51:18 +0300 (EEST) Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: References: Message-ID: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> I tested all suggested solutions(reset filesystems everyone@=modify,edited hosts files on esxi and omnios) but nothing changed , I have same random not connected NFS share problem(also pached esxi 5.5 to last release 2638301), I think something changed in r151014 nfs stack,because when I restored to r151012 everythink running smooth Now I'm back to r151012, Hafiz ----- Original Message ----- From: omnios-discuss-request at lists.omniti.com To: "omnios-discuss" Sent: Monday, 6 April, 2015 16:41:22 Subject: OmniOS-discuss Digest, Vol 37, Issue 16 Send OmniOS-discuss mailing list submissions to omnios-discuss at 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-request at lists.omniti.com You can reach the person managing the list at omnios-discuss-owner at 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. r151014 KVM crash (Johan Kragsterman) 2. Re: OmniOS r151014 is now out! (Natxo Asenjo) 3. pkgrecv r151014 (Al Slater) 4. esxi 5.5 to omnios r151014 nfs server issue (Hafiz Rafiyev) 5. Re: pkgrecv r151014 (Al Slater) 6. Re: esxi 5.5 to omnios r151014 nfs server issue (G?nther Alka) 7. Re: All SSD pool advice (Chris Nagele) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Apr 2015 10:20:56 +0200 From: Johan Kragsterman To: "omnios-discuss at lists.omniti.com" Subject: [OmniOS-discuss] r151014 KVM crash Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi! I switched one of my development ?machines over to r151014. On that machine I got a few KVM VM's. One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. The following msg is from /var/adm/messages: 40b0000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff0614236000 , id=3, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x1010101 data fffffd 7fffdfe8e0 Apr ?4 20:45:52 omni2 last message repeated 3 times Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0xff3d0f9c data fffff d7fffdfe8b0 Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x0 data 0 Apr ?4 20:45:52 omni2 last message repeated 6 times Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 1 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 2 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 3 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140b0000 , id=1, base_msr= fee00800 PRIx64 base_address=fee00000 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00800 PRIx64 base_address=fee00000 Then it goes on like this: Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 2000000 And like this: Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 10 Apr I switched back to r151012, and there everything is working fine... I do a rollback of the volumes I used for the chroots in the VM, because they've been messed up of the repetedly interupted upgrade attemts, so I run new updates/upgrades on the chroots, and even build new ones, and no problems here in r151012. So the problem seem to be exclusively in r151014. I got some messages on the omnios console after the VM crashes that I didn't record, unfortunatly. What I remember was that it was complaining about a bus, and it was also complains about either ps or pthread as well. I will go back to r151014 again, and run more tests like this, to get this clarified, and record the exact msg on the consol. Any suggestion? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert ------------------------------ Message: 2 Date: Mon, 6 Apr 2015 11:32:16 +0200 From: Natxo Asenjo To: omnios-discuss Subject: Re: [OmniOS-discuss] OmniOS r151014 is now out! Message-ID: Content-Type: text/plain; charset="utf-8" On Fri, Apr 3, 2015 at 3:58 AM, Dan McDonald wrote: > Say hello to OmniOS r151014: > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 upgrade succesful on my home microserver :-) Congrats on the good work! -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Mon, 06 Apr 2015 11:03:47 +0100 From: Al Slater To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] pkgrecv r151014 Message-ID: <55225A03.7020102 at scluk.com> Content-Type: text/plain; charset=utf-8 Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? -- Al Slater ------------------------------ Message: 4 Date: Mon, 6 Apr 2015 12:50:00 +0300 (EEST) From: Hafiz Rafiyev To: omnios-discuss Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue Message-ID: <1070639246.2109450.1428313800852.JavaMail.zimbra at cantekstil.com.tr> Content-Type: text/plain; charset=windows-1254 After upgrade from r151012 to r151014 i have issue with nfs server, after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, and it's being randomly,after omnios restart again some datastores connected and some not when looking omnios side,nfs server up and running, note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport regards Hafiz. ------------------------------ Message: 5 Date: Mon, 06 Apr 2015 11:24:30 +0100 From: Al Slater To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] pkgrecv r151014 Message-ID: <55225EDE.2010902 at scluk.com> Content-Type: text/plain; charset=windows-1252 On 06/04/15 11:03, Al Slater wrote: > Hi, > > I am trying to pkgrecv r151014 into my own repository and keep bumping > into this: > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > Is there a problem with this package in the repository? Same happens with pkg install... # pkg install pkg:/developer/sunstudio12.1 at 12.1-0.151014 Packages to install: 1 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 3.0M/s Errors were encountered while attempting to retrieve package or file data for the requested operation. Details follow: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) regards -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 ------------------------------ Message: 6 Date: Mon, 6 Apr 2015 12:34:30 +0200 From: G?nther Alka To: omnios-discuss Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue Message-ID: <4700B3B3-2CED-407D-A131-62FE1E392B53 at hfg-gmuend.de> Content-Type: text/plain; charset=us-ascii just to rule out a permission problem can you recursively reset permissions of that filesystem to a everyone@=modify setting. > Am 06.04.2015 um 11:50 schrieb Hafiz Rafiyev : > > > After upgrade from r151012 to r151014 i have issue with nfs server, > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > and it's being randomly,after omnios restart again some datastores connected and some not > > when looking omnios side,nfs server up and running, > > note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport > > > regards > > Hafiz. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ Message: 7 Date: Mon, 6 Apr 2015 09:41:19 -0400 From: Chris Nagele To: "omnios-discuss at lists.omniti.com" Subject: Re: [OmniOS-discuss] All SSD pool advice Message-ID: Content-Type: text/plain; charset=UTF-8 Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS -> SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the > current favorite). They work great for IOPS. Here's my take. > 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst > the existing zpool devices. They are plenty fast enough. > 2) you don't need an L2arc for the same reason. a smaller number of > dedicated devices would likely cause more of a bottleneck than serving off > the existing pool devices (unless you were to put it on one of those giant > RDRAM things or similar, but that adds a lot of expense) > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > SSDs for L2. The main disks are regular 1TB SAS. > > I'm considering moving to all SSD since the pricing has dropped so much. > What things should I know or do when moving to all SSD pools? I'm assuming I > don't need L2 and that I should keep the ZeusRAM. Should I only use certain > types of SSDs? > > Thanks, > Chris > > > -- > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ------------------------------ Subject: Digest Footer _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ End of OmniOS-discuss Digest, Vol 37, Issue 16 ********************************************** From danmcd at omniti.com Fri Apr 10 12:59:45 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 10 Apr 2015 08:59:45 -0400 Subject: [OmniOS-discuss] Ang: Re: r151014 KVM crash In-Reply-To: References: Message-ID: <6DFD3573-9D57-4D46-97F9-9324B3D18259@omniti.com> > On Apr 10, 2015, at 3:06 AM, Johan Kragsterman wrote: > > > I have now changed back again to r151014, and I seem to not be able to repete this behaviour. I have been building several chroot's and images, and doing updates in the way that earlier chrashed the KVM process, but I see no problem now, and no extensive logging. And therefore I don't have access to the consol messages I saw earlier, as well, unfortunatly... > > I don't know wether this is good or bad, that it seem to work now. It would have been good to know what caused the problems, but it is nice that it seems to work without problems now... I see two potential sources of a problem, neither of which I can easily test because nobody can easily reproduce the problem: 1.) The qemu/userland bits have missing pieces that should've been forward-ported. NOTE: We aren't matching the joyent upstream's kvm-cmd because we don't have their Virtual Network Driver (VND) in illumos-omnios or upstream in illumos-gate yet. I was helping Joyent to upstream it, but both Joyent and I got slammed with other things, so it didn't make it for r151014. We have one of their security fixes, but we are missing a few commits from upstream. 2.) There's some kernel problem that perhaps upstream isn't seeing because their illumos has additional fixes. I think this one is less likely, but the possibility exists. Either one will require dedicated effort, which I don't have cycles for at the moment. Thank you for the followup, Johan. My suspicion is it's a race, or other hard to synchronize and therefore reproduce problem. Dan From chip at innovates.com Fri Apr 10 13:11:49 2015 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 10 Apr 2015 08:11:49 -0500 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> Message-ID: On Fri, Apr 10, 2015 at 7:51 AM, Hafiz Rafiyev wrote: > I tested all suggested solutions(reset filesystems everyone@=modify,edited > hosts files on esxi and omnios) but nothing changed , > > > I have same random not connected NFS share problem(also pached esxi 5.5 to > last release 2638301), > > I think something changed in r151014 nfs stack,because when I restored to > r151012 everythink running smooth > > Now I'm back to r151012, > > Hafiz > > Have you adjusted the NFS heartbeats on ESXi? I can't seem to located the best practices paper I found a few years ago. I think it was on Oracle or Nexenta, but you need to adjust your heart beats from ESXi or it will think your storage is offline. Here's my settings: [image: Inline image 1] My data stores are still on r151012, so I can't say for sure this has anything to do with the problem you are seeing. But I have definitely seen your problems before. I figured out the heart beat problem by analyzing tcpdumps while the datastores went off and online. -Chip > > > > ----- Original Message ----- > From: omnios-discuss-request at lists.omniti.com > To: "omnios-discuss" > Sent: Monday, 6 April, 2015 16:41:22 > Subject: OmniOS-discuss Digest, Vol 37, Issue 16 > > Send OmniOS-discuss mailing list submissions to > omnios-discuss at 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-request at lists.omniti.com > > You can reach the person managing the list at > omnios-discuss-owner at 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. r151014 KVM crash (Johan Kragsterman) > 2. Re: OmniOS r151014 is now out! (Natxo Asenjo) > 3. pkgrecv r151014 (Al Slater) > 4. esxi 5.5 to omnios r151014 nfs server issue (Hafiz Rafiyev) > 5. Re: pkgrecv r151014 (Al Slater) > 6. Re: esxi 5.5 to omnios r151014 nfs server issue (G?nther Alka) > 7. Re: All SSD pool advice (Chris Nagele) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Apr 2015 10:20:56 +0200 > From: Johan Kragsterman > To: "omnios-discuss at lists.omniti.com" > > Subject: [OmniOS-discuss] r151014 KVM crash > Message-ID: > < > OF8C4EC57F.10747AAD-ONC1257E1F.0027F11B-C1257E1F.002DDCA2 at inse.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi! > > I switched one of my development ?machines over to r151014. On that > machine I got a few KVM VM's. > > One of them is a Linux terminal server, and when I wanted to > update/upgrade it, both the general OS and the chroot environments I got in > it, it crashed. I tried several times, and every time I did it, it crashed. > It seems to run without problems when I don't do any heavy work on it, but > with this update/upgrade, it runs for about ~5 min, then it crashes. It > can't get started again, until I reboot the server. > > The following msg is from /var/adm/messages: > > > 40b0000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f > Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: > vcpu=ffffff06140a8000 > , id=2, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f > Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: > vcpu=ffffff0614236000 > , id=3, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x1010101 data fffffd > 7fffdfe8e0 > Apr ?4 20:45:52 omni2 last message repeated 3 times > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0xff3d0f9c data fffff > d7fffdfe8b0 > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x0 > data 0 > Apr ?4 20:45:52 omni2 last message repeated 6 times > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 1 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 2 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 3 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: > vcpu=ffffff06140b0000 > , id=1, base_msr= fee00800 PRIx64 base_address=fee00000 > Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: > vcpu=ffffff06140a8000 > , id=2, base_msr= fee00800 PRIx64 base_address=fee00000 > > > Then it goes on like this: > > > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x525f2f data 2000000 > > > > And like this: > > > > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: > 0x526835 data 10 > Apr > > > I switched back to r151012, and there everything is working fine... > > I do a rollback of the volumes I used for the chroots in the VM, because > they've been messed up of the repetedly interupted upgrade attemts, so I > run new updates/upgrades on the chroots, and even build new ones, and no > problems here in r151012. > > So the problem seem to be exclusively in r151014. > > I got some messages on the omnios console after the VM crashes that I > didn't record, unfortunatly. What I remember was that it was complaining > about a bus, and it was also complains about either ps or pthread as well. > > I will go back to r151014 again, and run more tests like this, to get this > clarified, and record the exact msg on the consol. > > Any suggestion? > > > > Best regards from/Med v?nliga h?lsningar fr?n > > Johan Kragsterman > > Capvert > > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Apr 2015 11:32:16 +0200 > From: Natxo Asenjo > To: omnios-discuss > Subject: Re: [OmniOS-discuss] OmniOS r151014 is now out! > Message-ID: > < > CAHBEJzUN7-4L0AyYxBLTxUXQbUsjmb0N7oOtWpx0uGPL0i7S5Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Apr 3, 2015 at 3:58 AM, Dan McDonald wrote: > > > Say hello to OmniOS r151014: > > > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > > upgrade succesful on my home microserver :-) > > Congrats on the good work! > > -- > regards, > natxo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://omniosce.org/ml-archive/attachments/20150406/ef8ee9b8/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 06 Apr 2015 11:03:47 +0100 > From: Al Slater > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] pkgrecv r151014 > Message-ID: <55225A03.7020102 at scluk.com> > Content-Type: text/plain; charset=utf-8 > > Hi, > > I am trying to pkgrecv r151014 into my own repository and keep bumping > into this: > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > Is there a problem with this package in the repository? > > -- > Al Slater > > > > > ------------------------------ > > Message: 4 > Date: Mon, 6 Apr 2015 12:50:00 +0300 (EEST) > From: Hafiz Rafiyev > To: omnios-discuss > Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue > Message-ID: > < > 1070639246.2109450.1428313800852.JavaMail.zimbra at cantekstil.com.tr> > Content-Type: text/plain; charset=windows-1254 > > > After upgrade from r151012 to r151014 i have issue with nfs server, > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > and it's being randomly,after omnios restart again some datastores > connected and some not > > when looking omnios side,nfs server up and running, > > note:before upgrade all esxi datastores were connected and running,omnios > running as VM,disks connected with HBA passthruogh mode > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local > hostname binding for transport tcp6 - delegations will not be available on > this transport > > > regards > > Hafiz. > > > ------------------------------ > > Message: 5 > Date: Mon, 06 Apr 2015 11:24:30 +0100 > From: Al Slater > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] pkgrecv r151014 > Message-ID: <55225EDE.2010902 at scluk.com> > Content-Type: text/plain; charset=windows-1252 > > On 06/04/15 11:03, Al Slater wrote: > > Hi, > > > > I am trying to pkgrecv r151014 into my own repository and keep bumping > > into this: > > > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > > > Is there a problem with this package in the repository? > > Same happens with pkg install... > > # pkg install pkg:/developer/sunstudio12.1 at 12.1-0.151014 > Packages to install: 1 > Create boot environment: No > Create backup boot environment: No > > DOWNLOAD PKGS FILES XFER (MB) > SPEED > developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 > 3.0M/s > > > > Errors were encountered while attempting to retrieve package or file > data for > the requested operation. > Details follow: > > Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash > failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: > 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > > regards > > -- > Al Slater > > Technical Director > SCL > > Phone : +44 (0)1273 666607 > Fax : +44 (0)1273 666601 > email : al.slater at scluk.com > > Stanton Consultancy Ltd > > Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU > > Registered in England Company number: 1957652 VAT number: GB 760 2433 55 > > > > ------------------------------ > > Message: 6 > Date: Mon, 6 Apr 2015 12:34:30 +0200 > From: G?nther Alka > To: omnios-discuss > Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server > issue > Message-ID: <4700B3B3-2CED-407D-A131-62FE1E392B53 at hfg-gmuend.de> > Content-Type: text/plain; charset=us-ascii > > just to rule out a permission problem > > can you recursively reset permissions of that filesystem to a > everyone@=modify setting. > > > > > Am 06.04.2015 um 11:50 schrieb Hafiz Rafiyev : > > > > > > After upgrade from r151012 to r151014 i have issue with nfs server, > > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > > > and it's being randomly,after omnios restart again some datastores > connected and some not > > > > when looking omnios side,nfs server up and running, > > > > note:before upgrade all esxi datastores were connected and > running,omnios running as VM,disks connected with HBA passthruogh mode > > > > only log I see from omnios side is: > > > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local > hostname binding for transport tcp6 - delegations will not be available on > this transport > > > > > > regards > > > > Hafiz. > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > ------------------------------ > > Message: 7 > Date: Mon, 6 Apr 2015 09:41:19 -0400 > From: Chris Nagele > To: "omnios-discuss at lists.omniti.com" > > Subject: Re: [OmniOS-discuss] All SSD pool advice > Message-ID: > < > CAHfYOdUN_CWsmPVDCZGRh3pCUoSkRkWThwBj7khkj+ztiwC5Zg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Thanks everyone. Regarding the expanders, our 4U servers are on the > following chassis: > > http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm > > We are using all SAS disks, except for the SSDs. How big is the risk > here when it comes to SAS -> SATA conversion? Our newer servers have > direct connections on each lane to the disk. > > Chris > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes wrote: > > > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is > the > > current favorite). They work great for IOPS. Here's my take. > > 1) you don't need a dedicated zil. Just let the zpool intersperse it > amongst > > the existing zpool devices. They are plenty fast enough. > > 2) you don't need an L2arc for the same reason. a smaller number of > > dedicated devices would likely cause more of a bottleneck than serving > off > > the existing pool devices (unless you were to put it on one of those > giant > > RDRAM things or similar, but that adds a lot of expense) > > > > > > > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > > SSDs for L2. The main disks are regular 1TB SAS. > > > > I'm considering moving to all SSD since the pricing has dropped so much. > > What things should I know or do when moving to all SSD pools? I'm > assuming I > > don't need L2 and that I should keep the ZeusRAM. Should I only use > certain > > types of SSDs? > > > > Thanks, > > Chris > > > > > > -- > > > > Chris Nagele > > Co-founder, Wildbit > > Beanstalk, Postmark, dploy.io > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > ------------------------------ > > End of OmniOS-discuss Digest, Vol 37, Issue 16 > ********************************************** > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 8184 bytes Desc: not available URL: From tobi at oetiker.ch Fri Apr 10 13:52:19 2015 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 10 Apr 2015 15:52:19 +0200 (CEST) Subject: [OmniOS-discuss] kvm network performance survey Message-ID: Hi, For the past few months I have been struggling with bad KVM nework performance on omnios R12 and R14. Especially under bidirectional load things are looking terrible (factor 1000). Every now and then there is a report on the mailinglist about such problems, but we have not yet seen anything really helpful. In my tests I have been using iperf to collect streaming tcp network performance on verious configurations. I realy want to see this solved. As an initial effort, I have setup a google spreadsheet to collect performance data. The sheet includes instructions on how to test and lets you record your test results: http://goo.gl/Vr1tC6 Please add your test results, or even better, figure out what is going wrong! cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From rafibeyli at gmail.com Fri Apr 10 13:55:24 2015 From: rafibeyli at gmail.com (Hafiz Rafiyev) Date: Fri, 10 Apr 2015 16:55:24 +0300 (EEST) Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> Chip thank you for quick answer,I think you mean these Oracle parameters: I changed them as yours and as oracle's but same result on r151014 system:( again datasources on r151014 connecting randomly,and some not connected TABLE 6. RECOMMENDED NFS AND TCP/IP ADVANCED SETTINGS FOR VMWARE VSPHERE 5.1 DATASTORES ON ORACLE ZFS STORAGE APPLIANCE OPTION VALUE NFS.HeartbeatTimeout 5 Nfs.Sendbuffersize 264 Nfs.Receivebuffersize 256 Nfs.MaxVolumes 256 Net.TcpipHeapMax 128 Net.TcpipHeapsize 32 Nfs.heartbeatfrequency 20 Nfs.heartbeatdelta 12 Nfs.heartbeatmaxfailures 10 ----- Original Message ----- From: "Schweiss, Chip" To: "Hafiz Rafibeyli" Cc: "omnios-discuss" , "G?nther Alka" Sent: Friday, 10 April, 2015 16:11:49 Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue On Fri, Apr 10, 2015 at 7:51 AM, Hafiz Rafiyev < rafibeyli at gmail.com > wrote: I tested all suggested solutions(reset filesystems everyone@=modify,edited hosts files on esxi and omnios) but nothing changed , I have same random not connected NFS share problem(also pached esxi 5.5 to last release 2638301), I think something changed in r151014 nfs stack,because when I restored to r151012 everythink running smooth Now I'm back to r151012, Hafiz Have you adjusted the NFS heartbeats on ESXi? I can't seem to located the best practices paper I found a few years ago. I think it was on Oracle or Nexenta, but you need to adjust your heart beats from ESXi or it will think your storage is offline. Here's my settings: My data stores are still on r151012, so I can't say for sure this has anything to do with the problem you are seeing. But I have definitely seen your problems before. I figured out the heart beat problem by analyzing tcpdumps while the datastores went off and online. -Chip BQ_BEGIN ----- Original Message ----- From: omnios-discuss-request at lists.omniti.com To: "omnios-discuss" < omnios-discuss at lists.omniti.com > Sent: Monday, 6 April, 2015 16:41:22 Subject: OmniOS-discuss Digest, Vol 37, Issue 16 Send OmniOS-discuss mailing list submissions to omnios-discuss at 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-request at lists.omniti.com You can reach the person managing the list at omnios-discuss-owner at 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. r151014 KVM crash (Johan Kragsterman) 2. Re: OmniOS r151014 is now out! (Natxo Asenjo) 3. pkgrecv r151014 (Al Slater) 4. esxi 5.5 to omnios r151014 nfs server issue (Hafiz Rafiyev) 5. Re: pkgrecv r151014 (Al Slater) 6. Re: esxi 5.5 to omnios r151014 nfs server issue (G?nther Alka) 7. Re: All SSD pool advice (Chris Nagele) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Apr 2015 10:20:56 +0200 From: Johan Kragsterman < johan.kragsterman at capvert.se > To: " omnios-discuss at lists.omniti.com " < omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] r151014 KVM crash Message-ID: < OF8C4EC57F.10747AAD-ONC1257E1F.0027F11B-C1257E1F.002DDCA2 at inse.com > Content-Type: text/plain; charset=ISO-8859-1 Hi! I switched one of my development ?machines over to r151014. On that machine I got a few KVM VM's. One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. The following msg is from /var/adm/messages: 40b0000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: vcpu=ffffff0614236000 , id=3, base_msr= fee00000 PRIx64 base_address=fee00000 Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x1010101 data fffffd 7fffdfe8e0 Apr ?4 20:45:52 omni2 last message repeated 3 times Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0xff3d0f9c data fffff d7fffdfe8b0 Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x0 data 0 Apr ?4 20:45:52 omni2 last message repeated 6 times Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 1 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 2 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 3 received sipi with vector # 10 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: vcpu=ffffff06140b0000 , id=1, base_msr= fee00800 PRIx64 base_address=fee00000 Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: vcpu=ffffff06140a8000 , id=2, base_msr= fee00800 PRIx64 base_address=fee00000 Then it goes on like this: Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 8000000 01 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 001 Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x525f2f data 2000000 And like this: Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 8 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: 0xff311c4c Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x526835 data 10 Apr I switched back to r151012, and there everything is working fine... I do a rollback of the volumes I used for the chroots in the VM, because they've been messed up of the repetedly interupted upgrade attemts, so I run new updates/upgrades on the chroots, and even build new ones, and no problems here in r151012. So the problem seem to be exclusively in r151014. I got some messages on the omnios console after the VM crashes that I didn't record, unfortunatly. What I remember was that it was complaining about a bus, and it was also complains about either ps or pthread as well. I will go back to r151014 again, and run more tests like this, to get this clarified, and record the exact msg on the consol. Any suggestion? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert ------------------------------ Message: 2 Date: Mon, 6 Apr 2015 11:32:16 +0200 From: Natxo Asenjo < natxo.asenjo at gmail.com > To: omnios-discuss < omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] OmniOS r151014 is now out! Message-ID: < CAHBEJzUN7-4L0AyYxBLTxUXQbUsjmb0N7oOtWpx0uGPL0i7S5Q at mail.gmail.com > Content-Type: text/plain; charset="utf-8" On Fri, Apr 3, 2015 at 3:58 AM, Dan McDonald < danmcd at omniti.com > wrote: > Say hello to OmniOS r151014: > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 upgrade succesful on my home microserver :-) Congrats on the good work! -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: < https://omniosce.org/ml-archive/attachments/20150406/ef8ee9b8/attachment-0001.html > ------------------------------ Message: 3 Date: Mon, 06 Apr 2015 11:03:47 +0100 From: Al Slater < al.slater at scluk.com > To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] pkgrecv r151014 Message-ID: < 55225A03.7020102 at scluk.com > Content-Type: text/plain; charset=utf-8 Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? -- Al Slater ------------------------------ Message: 4 Date: Mon, 6 Apr 2015 12:50:00 +0300 (EEST) From: Hafiz Rafiyev < rafibeyli at gmail.com > To: omnios-discuss < omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue Message-ID: < 1070639246.2109450.1428313800852.JavaMail.zimbra at cantekstil.com.tr > Content-Type: text/plain; charset=windows-1254 After upgrade from r151012 to r151014 i have issue with nfs server, after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, and it's being randomly,after omnios restart again some datastores connected and some not when looking omnios side,nfs server up and running, note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport regards Hafiz. ------------------------------ Message: 5 Date: Mon, 06 Apr 2015 11:24:30 +0100 From: Al Slater < al.slater at scluk.com > To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] pkgrecv r151014 Message-ID: < 55225EDE.2010902 at scluk.com > Content-Type: text/plain; charset=windows-1252 On 06/04/15 11:03, Al Slater wrote: > Hi, > > I am trying to pkgrecv r151014 into my own repository and keep bumping > into this: > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > Is there a problem with this package in the repository? Same happens with pkg install... # pkg install pkg:/developer/sunstudio12.1 at 12.1-0.151014 Packages to install: 1 Create boot environment: No Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 3.0M/s Errors were encountered while attempting to retrieve package or file data for the requested operation. Details follow: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) regards -- Al Slater Technical Director SCL Phone : +44 (0)1273 666607 Fax : +44 (0)1273 666601 email : al.slater at scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 ------------------------------ Message: 6 Date: Mon, 6 Apr 2015 12:34:30 +0200 From: G?nther Alka < alka at hfg-gmuend.de > To: omnios-discuss < omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue Message-ID: < 4700B3B3-2CED-407D-A131-62FE1E392B53 at hfg-gmuend.de > Content-Type: text/plain; charset=us-ascii just to rule out a permission problem can you recursively reset permissions of that filesystem to a everyone@=modify setting. > Am 06.04.2015 um 11:50 schrieb Hafiz Rafiyev < rafibeyli at gmail.com >: > > > After upgrade from r151012 to r151014 i have issue with nfs server, > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > and it's being randomly,after omnios restart again some datastores connected and some not > > when looking omnios side,nfs server up and running, > > note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport > > > regards > > Hafiz. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ Message: 7 Date: Mon, 6 Apr 2015 09:41:19 -0400 From: Chris Nagele < nagele at wildbit.com > To: " omnios-discuss at lists.omniti.com " < omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] All SSD pool advice Message-ID: < CAHfYOdUN_CWsmPVDCZGRh3pCUoSkRkWThwBj7khkj+ztiwC5Zg at mail.gmail.com > Content-Type: text/plain; charset=UTF-8 Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS -> SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes < doug at will.to > wrote: > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the > current favorite). They work great for IOPS. Here's my take. > 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst > the existing zpool devices. They are plenty fast enough. > 2) you don't need an L2arc for the same reason. a smaller number of > dedicated devices would likely cause more of a bottleneck than serving off > the existing pool devices (unless you were to put it on one of those giant > RDRAM things or similar, but that adds a lot of expense) > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > SSDs for L2. The main disks are regular 1TB SAS. > > I'm considering moving to all SSD since the pricing has dropped so much. > What things should I know or do when moving to all SSD pools? I'm assuming I > don't need L2 and that I should keep the ZeusRAM. Should I only use certain > types of SSDs? > > Thanks, > Chris > > > -- > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ------------------------------ Subject: Digest Footer _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ------------------------------ End of OmniOS-discuss Digest, Vol 37, Issue 16 ********************************************** _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss BQ_END From chip at innovates.com Fri Apr 10 14:10:44 2015 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 10 Apr 2015 09:10:44 -0500 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> Message-ID: This information certainly puts the pause on me moving to r151014 for my systems serving ESXi. My next suspicion would be that this would be an NFS locking issue. There were updates to the lock manager in r151014. Tcpdumps will reveal if that is the problem. I've seen numerous lockd problems in Illumos NFSv3. Fortunately ESXi connections has not been one of them. Might be the end of my luck on that. -Chip On Fri, Apr 10, 2015 at 8:55 AM, Hafiz Rafiyev wrote: > Chip thank you for quick answer,I think you mean these Oracle parameters: > > I changed them as yours and as oracle's but same result on r151014 system:( > > again datasources on r151014 connecting randomly,and some not connected > > TABLE 6. RECOMMENDED NFS AND TCP/IP ADVANCED SETTINGS FOR VMWARE VSPHERE > 5.1 DATASTORES ON ORACLE ZFS STORAGE APPLIANCE > OPTION > VALUE > NFS.HeartbeatTimeout > 5 > Nfs.Sendbuffersize > 264 > Nfs.Receivebuffersize > 256 > Nfs.MaxVolumes > 256 > Net.TcpipHeapMax > 128 > Net.TcpipHeapsize > 32 > Nfs.heartbeatfrequency > 20 > Nfs.heartbeatdelta > 12 > Nfs.heartbeatmaxfailures > 10 > > ----- Original Message ----- > From: "Schweiss, Chip" > To: "Hafiz Rafibeyli" > Cc: "omnios-discuss" , "G?nther Alka" < > alka at hfg-gmuend.de> > Sent: Friday, 10 April, 2015 16:11:49 > Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue > > On Fri, Apr 10, 2015 at 7:51 AM, Hafiz Rafiyev < rafibeyli at gmail.com > > wrote: > > > I tested all suggested solutions(reset filesystems everyone@=modify,edited > hosts files on esxi and omnios) but nothing changed , > > > I have same random not connected NFS share problem(also pached esxi 5.5 to > last release 2638301), > > I think something changed in r151014 nfs stack,because when I restored to > r151012 everythink running smooth > > Now I'm back to r151012, > > Hafiz > > > > > Have you adjusted the NFS heartbeats on ESXi? I can't seem to located the > best practices paper I found a few years ago. I think it was on Oracle or > Nexenta, but you need to adjust your heart beats from ESXi or it will think > your storage is offline. Here's my settings: > > > > My data stores are still on r151012, so I can't say for sure this has > anything to do with the problem you are seeing. But I have definitely seen > your problems before. I figured out the heart beat problem by analyzing > tcpdumps while the datastores went off and online. > > -Chip > > BQ_BEGIN > > > > ----- Original Message ----- > From: omnios-discuss-request at lists.omniti.com > To: "omnios-discuss" < omnios-discuss at lists.omniti.com > > Sent: Monday, 6 April, 2015 16:41:22 > Subject: OmniOS-discuss Digest, Vol 37, Issue 16 > > Send OmniOS-discuss mailing list submissions to > omnios-discuss at 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-request at lists.omniti.com > > You can reach the person managing the list at > omnios-discuss-owner at 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. r151014 KVM crash (Johan Kragsterman) > 2. Re: OmniOS r151014 is now out! (Natxo Asenjo) > 3. pkgrecv r151014 (Al Slater) > 4. esxi 5.5 to omnios r151014 nfs server issue (Hafiz Rafiyev) > 5. Re: pkgrecv r151014 (Al Slater) > 6. Re: esxi 5.5 to omnios r151014 nfs server issue (G?nther Alka) > 7. Re: All SSD pool advice (Chris Nagele) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Apr 2015 10:20:56 +0200 > From: Johan Kragsterman < johan.kragsterman at capvert.se > > To: " omnios-discuss at lists.omniti.com " > < omnios-discuss at lists.omniti.com > > Subject: [OmniOS-discuss] r151014 KVM crash > Message-ID: > < OF8C4EC57F.10747AAD-ONC1257E1F.0027F11B-C1257E1F.002DDCA2 at inse.com > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi! > > I switched one of my development ?machines over to r151014. On that > machine I got a few KVM VM's. > > One of them is a Linux terminal server, and when I wanted to > update/upgrade it, both the general OS and the chroot environments I got in > it, it crashed. I tried several times, and every time I did it, it crashed. > It seems to run without problems when I don't do any heavy work on it, but > with this update/upgrade, it runs for about ~5 min, then it crashes. It > can't get started again, until I reboot the server. > > The following msg is from /var/adm/messages: > > > 40b0000, id=1, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f > Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: > vcpu=ffffff06140a8000 > , id=2, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f > Apr ?4 20:45:45 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: > vcpu=ffffff0614236000 > , id=3, base_msr= fee00000 PRIx64 base_address=fee00000 > Apr ?4 20:45:45 omni2 kvm: [ID 710719 kern.info ] vmcs revision_id = f > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x1010101 data fffffd > 7fffdfe8e0 > Apr ?4 20:45:52 omni2 last message repeated 3 times > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0xff3d0f9c data fffff > d7fffdfe8b0 > Apr ?4 20:45:52 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: 0x0 > data 0 > Apr ?4 20:45:52 omni2 last message repeated 6 times > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 1 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 2 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 291337 kern.info ] vcpu 3 received sipi > with vector # 10 > Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: > vcpu=ffffff06140b0000 > , id=1, base_msr= fee00800 PRIx64 base_address=fee00000 > Apr ?4 20:45:52 omni2 kvm: [ID 420667 kern.info ] kvm_lapic_reset: > vcpu=ffffff06140a8000 > , id=2, base_msr= fee00800 PRIx64 base_address=fee00000 > > > Then it goes on like this: > > > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:25 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:25 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 8000000 > 01 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > 001 > Apr ?4 20:46:34 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:46:34 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x525f2f data 2000000 > > > > And like this: > > > > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 8 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr ?4 20:50:45 omni2 kvm: [ID 713435 kern.info ] unhandled rdmsr: > 0xff311c4c > Apr ?4 20:50:45 omni2 kvm: [ID 391722 kern.info ] unhandled wrmsr: > 0x526835 data 10 > Apr > > > I switched back to r151012, and there everything is working fine... > > I do a rollback of the volumes I used for the chroots in the VM, because > they've been messed up of the repetedly interupted upgrade attemts, so I > run new updates/upgrades on the chroots, and even build new ones, and no > problems here in r151012. > > So the problem seem to be exclusively in r151014. > > I got some messages on the omnios console after the VM crashes that I > didn't record, unfortunatly. What I remember was that it was complaining > about a bus, and it was also complains about either ps or pthread as well. > > I will go back to r151014 again, and run more tests like this, to get this > clarified, and record the exact msg on the consol. > > Any suggestion? > > > > Best regards from/Med v?nliga h?lsningar fr?n > > Johan Kragsterman > > Capvert > > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Apr 2015 11:32:16 +0200 > From: Natxo Asenjo < natxo.asenjo at gmail.com > > To: omnios-discuss < omnios-discuss at lists.omniti.com > > Subject: Re: [OmniOS-discuss] OmniOS r151014 is now out! > Message-ID: > < CAHBEJzUN7-4L0AyYxBLTxUXQbUsjmb0N7oOtWpx0uGPL0i7S5Q at mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > On Fri, Apr 3, 2015 at 3:58 AM, Dan McDonald < danmcd at omniti.com > wrote: > > > Say hello to OmniOS r151014: > > > > http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014 > > > upgrade succesful on my home microserver :-) > > Congrats on the good work! > > -- > regards, > natxo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://omniosce.org/ml-archive/attachments/20150406/ef8ee9b8/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 06 Apr 2015 11:03:47 +0100 > From: Al Slater < al.slater at scluk.com > > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] pkgrecv r151014 > Message-ID: < 55225A03.7020102 at scluk.com > > Content-Type: text/plain; charset=utf-8 > > Hi, > > I am trying to pkgrecv r151014 into my own repository and keep bumping > into this: > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > Is there a problem with this package in the repository? > > -- > Al Slater > > > > > ------------------------------ > > Message: 4 > Date: Mon, 6 Apr 2015 12:50:00 +0300 (EEST) > From: Hafiz Rafiyev < rafibeyli at gmail.com > > To: omnios-discuss < omnios-discuss at lists.omniti.com > > Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue > Message-ID: > < 1070639246.2109450.1428313800852.JavaMail.zimbra at cantekstil.com.tr > > Content-Type: text/plain; charset=windows-1254 > > > After upgrade from r151012 to r151014 i have issue with nfs server, > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > and it's being randomly,after omnios restart again some datastores > connected and some not > > when looking omnios side,nfs server up and running, > > note:before upgrade all esxi datastores were connected and running,omnios > running as VM,disks connected with HBA passthruogh mode > > only log I see from omnios side is: > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local > hostname binding for transport tcp6 - delegations will not be available on > this transport > > > regards > > Hafiz. > > > ------------------------------ > > Message: 5 > Date: Mon, 06 Apr 2015 11:24:30 +0100 > From: Al Slater < al.slater at scluk.com > > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] pkgrecv r151014 > Message-ID: < 55225EDE.2010902 at scluk.com > > Content-Type: text/plain; charset=windows-1252 > > On 06/04/15 11:03, Al Slater wrote: > > Hi, > > > > I am trying to pkgrecv r151014 into my own repository and keep bumping > > into this: > > > > pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: > > chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 > > computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > > > Is there a problem with this package in the repository? > > Same happens with pkg install... > > # pkg install pkg:/developer/sunstudio12.1 at 12.1-0.151014 > Packages to install: 1 > Create boot environment: No > Create backup boot environment: No > > DOWNLOAD PKGS FILES XFER (MB) > SPEED > developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 > 3.0M/s > > > > Errors were encountered while attempting to retrieve package or file > data for > the requested operation. > Details follow: > > Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash > failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: > 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) > > > regards > > -- > Al Slater > > Technical Director > SCL > > Phone : +44 (0)1273 666607 > Fax : +44 (0)1273 666601 > email : al.slater at scluk.com > > Stanton Consultancy Ltd > > Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU > > Registered in England Company number: 1957652 VAT number: GB 760 2433 55 > > > > ------------------------------ > > Message: 6 > Date: Mon, 6 Apr 2015 12:34:30 +0200 > From: G?nther Alka < alka at hfg-gmuend.de > > To: omnios-discuss < omnios-discuss at lists.omniti.com > > Subject: Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server > issue > Message-ID: < 4700B3B3-2CED-407D-A131-62FE1E392B53 at hfg-gmuend.de > > Content-Type: text/plain; charset=us-ascii > > just to rule out a permission problem > > can you recursively reset permissions of that filesystem to a > everyone@=modify setting. > > > > > Am 06.04.2015 um 11:50 schrieb Hafiz Rafiyev < rafibeyli at gmail.com >: > > > > > > After upgrade from r151012 to r151014 i have issue with nfs server, > > after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, > > > > and it's being randomly,after omnios restart again some datastores > connected and some not > > > > when looking omnios side,nfs server up and running, > > > > note:before upgrade all esxi datastores were connected and > running,omnios running as VM,disks connected with HBA passthruogh mode > > > > only log I see from omnios side is: > > > > nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local > hostname binding for transport tcp6 - delegations will not be available on > this transport > > > > > > regards > > > > Hafiz. > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > ------------------------------ > > Message: 7 > Date: Mon, 6 Apr 2015 09:41:19 -0400 > From: Chris Nagele < nagele at wildbit.com > > To: " omnios-discuss at lists.omniti.com " > < omnios-discuss at lists.omniti.com > > Subject: Re: [OmniOS-discuss] All SSD pool advice > Message-ID: > < CAHfYOdUN_CWsmPVDCZGRh3pCUoSkRkWThwBj7khkj+ztiwC5Zg at mail.gmail.com > > Content-Type: text/plain; charset=UTF-8 > > Thanks everyone. Regarding the expanders, our 4U servers are on the > following chassis: > > http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm > > We are using all SAS disks, except for the SSDs. How big is the risk > here when it comes to SAS -> SATA conversion? Our newer servers have > direct connections on each lane to the disk. > > Chris > > Chris Nagele > Co-founder, Wildbit > Beanstalk, Postmark, dploy.io > > > On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes < doug at will.to > wrote: > > > > We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is > the > > current favorite). They work great for IOPS. Here's my take. > > 1) you don't need a dedicated zil. Just let the zpool intersperse it > amongst > > the existing zpool devices. They are plenty fast enough. > > 2) you don't need an L2arc for the same reason. a smaller number of > > dedicated devices would likely cause more of a bottleneck than serving > off > > the existing pool devices (unless you were to put it on one of those > giant > > RDRAM things or similar, but that adds a lot of expense) > > > > > > > > > > > > On 4/4/2015 3:07 PM, Chris Nagele wrote: > > > > We've been running a few 4U Supermicro servers using ZeusRAM for zil and > > SSDs for L2. The main disks are regular 1TB SAS. > > > > I'm considering moving to all SSD since the pricing has dropped so much. > > What things should I know or do when moving to all SSD pools? I'm > assuming I > > don't need L2 and that I should keep the ZeusRAM. Should I only use > certain > > types of SSDs? > > > > Thanks, > > Chris > > > > > > -- > > > > Chris Nagele > > Co-founder, Wildbit > > Beanstalk, Postmark, dploy.io > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > ------------------------------ > > End of OmniOS-discuss Digest, Vol 37, Issue 16 > ********************************************** > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > BQ_END > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Apr 10 14:17:31 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 10 Apr 2015 10:17:31 -0400 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <8AD9538F-5F92-4355-B702-D88BB405F17E@omniti.com> > On Apr 10, 2015, at 10:10 AM, Schweiss, Chip wrote: > > This information certainly puts the pause on me moving to r151014 for my systems serving ESXi. > > My next suspicion would be that this would be an NFS locking issue. There were updates to the lock manager in r151014. Tcpdumps will reveal if that is the problem. > The lock manager updates in '014 were to prevent the choking-at-boot-time seen in '010 and 012. The illumos community is aware there are further problems. (The bug report or code review for illumos 4518 talks about this.) I hope to have the next OmniOS bloody spun out soon, and then people can start keeping up with upstream again. Dan From richard.elling at richardelling.com Fri Apr 10 15:19:20 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 10 Apr 2015 08:19:20 -0700 Subject: [OmniOS-discuss] Building a new storage In-Reply-To: <5527A337.5060405@zunaj.si> References: <5527A337.5060405@zunaj.si> Message-ID: > On Apr 10, 2015, at 3:17 AM, Matej Zerovnik wrote: > > We are currently thinking of rebuilding our SAN, since we did some mistakes on the first build. But before we begin, we would like to plan accordingly, so I'm wondering how to measure some data(l2arc and zil usage, current iops,...) the right way. > > We currently have a single raidz2 pool build out of 50 SATA drives(Seagate Constellation, 2x Intel S3700 100GB as ZIL and 2x Intel S3700 100GB as L2ARC. > > For the new system, we plan to use a IBM 3550 M4 server with 256GB of memory and LSI SAS 9207-8e HBA. We will have around 70-80 SAS 4TB drives in JBOD cases and, if we need, some SSD's for ZIL and L2ARC. [sidebar conversation: I've experienced bad results with WD Black 4TB SAS drives] > > Questions: > > 1.) > How to measure average IOPS of the current system? 'zpool iostat poolname 1' gives me weird numbers saying current drives perform around 300 read ops and 100 write ops per second. Drives are 7200 SATA drives, so I know they can't perform that much IOPS. Sure they can. The measurable peak will be closer to 20,000 IOPS for a 7,200 rpm drive at 512 bytes. For HDDs, the biggest impact to response time is long seeks and the placement algorithms for ZFS bias towards the outer cylinders. From outer to inner, bandwidth usually drops by 30% and random IOPS becomes impacted by longer seeks. Also writes are cached in the drive, so you rarely see seek penalties for writes. This leads to a false sense of performance. This is why we often use the rule of thumb that a HDD can deliver 100 IOPS @ 4KB and 100 MB/sec -- good enough for back-of-the-envelope capacity planning, but not as good as real, long-term measurement. But the more interesting question is: where do you plan to measure the IOPS? The backend stats as seen by iostat and zpool iostat are difficult to use because they do not account for caching and the writes are coalesced. Write coalescing is particularly important for people who insist on counting IOPS because, by default, 32 4KB random write IOPS will be coalesced into one 128KB write. Let's take a closer look at your data... > Output from iostat -vx (only some drives are pasted): > Code: > device r/s w/s kr/s kw/s wait actv svc_t %w %b > data 36621,9 25740,2 19288,6 66191,0 197,6 25,9 3,6 40 77 > sd18 276,3 104,8 145,2 83,3 0,0 0,6 1,5 0 36 This version of iostat doesn't show average sizes :-( but you can calculate them from the data :-) For pool data (data written from the pool to disks, not data written into the pool): average write size = 66191,0 / 25740,2 = 2.5 KB average read size = 19288,6 / 36621,9 = 526 bytes For sd18: average write size = 83,3 / 104,8 = 794 bytes average read size = 145,2 / 276,3 = 525 bytes From this we can suggest: 1. avoid 4KB sector sized disks for this configuration and workload 2. look further up the stack to determine why such small physical I/Os are being used > sd19 283,3 106,7 152,1 83,3 0,0 0,6 1,5 0 24 > sd20 281,3 101,8 146,7 79,8 0,0 0,5 1,4 0 35 > sd21 286,3 117,7 146,7 84,3 0,0 0,3 0,7 0 21 > sd22 283,3 85,8 144,2 81,3 0,0 0,5 1,3 0 32 > sd23 275,3 116,7 139,7 82,8 0,0 0,3 0,8 0 21 > sd24 280,3 106,7 155,6 84,3 0,0 0,6 1,6 0 25 > sd25 288,3 106,7 148,6 86,3 0,0 0,4 1,0 0 24 > sd26 269,4 110,7 137,2 91,8 0,0 0,5 1,3 0 24 > sd27 272,4 87,8 141,7 78,3 0,0 0,7 1,8 0 34 > sd28 236,4 115,7 219,0 84,8 0,0 0,9 2,5 0 26 > sd29 235,4 108,7 228,5 83,8 0,0 0,9 2,7 0 33 > Output of 'zpool iostat -v data 1 | grep drive_id' > Code: > capacity operations bandwidth > pool alloc free read write read write > c8t5000C5004FD18DE9d0 - - 573 220 663K 607K > c8t5000C5004FD18DE9d0 - - 563 0 318K 0 > c8t5000C5004FD18DE9d0 - - 586 314 361K 806K > c8t5000C5004FD18DE9d0 - - 567 445 373K 1,02M > c8t5000C5004FD18DE9d0 - - 464 25 299K 17,9K > c8t5000C5004FD18DE9d0 - - 552 2 326K 3,68K > c8t5000C5004FD18DE9d0 - - 421 41 249K 31,3K > c8t5000C5004FD18DE9d0 - - 492 400 391K 944K > c8t5000C5004FD18DE9d0 - - 313 148 242K 337K > c8t5000C5004FD18DE9d0 - - 330 163 360K 390K > c8t5000C5004FD18DE9d0 - - 655 23 577K 21,5K > Is it just me, or are there too much IOPS for those drive to handle even in theory, let alone in practice? How to get the right measurement? To measure IOPS written into the pool, look at fsstat for file systems. For iSCSI, this isn't quite so easy to gather, so we use dtrace, see iscsisvrtop as an example. > > 2.) > Current ARC utilization on our system: > Code: > ARC Efficency: > Cache Access Total: 2134027465 > Cache Hit Ratio: 64% 1381755042 [Defined State for buffer] > Cache Miss Ratio: 35% 752272423 [Undefined State for Buffer] > REAL Hit Ratio: 56% 1199175179 [MRU/MFU Hits Only] > Code: > ./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 1 2>/dev/null > read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size > 1 1 0 100 0 0 0 0 213G 235G > 4.8K 3.0K 1.9K 61 1.9K 40 1.8K 2 213G 235G > 4.3K 2.7K 1.6K 62 1.6K 35 1.5K 2 213G 235G > 2.5K 853 1.6K 34 1.6K 45 1.6K 2 213G 235G > 5.1K 3.0K 2.2K 57 2.2K 49 2.1K 2 213G 235G > 6.5K 4.4K 2.1K 68 2.1K 30 2.0K 1 213G 235G > 5.0K 2.5K 2.5K 49 2.5K 44 2.5K 1 213G 235G > 11K 8.5K 2.8K 75 2.8K 13 2.8K 0 213G 235G > 6.4K 4.8K 1.6K 74 1.6K 57 1.6K 3 213G 235G > 2.3K 1.1K 1.2K 46 1.2K 88 1.1K 7 213G 235G > 1.9K 532 1.3K 28 1.3K 83 1.2K 6 213G 235G > As we can see, there are almost no L2ARC cache hits. What can be the reason for that? Is our L2ARC cache too small or are the data on our storage just too much random to be cached? I don't know what is on our iscsi shares, since they are for outside customers, but as far as I know, it's mostly backups and some live data. Unfortunately, most versions of arcstat do not measure what you want to know. The measurement you're looking for is the reason for eviction. These are measured as kstats: # kstat -p ::arcstats:evict_l2\* zfs:0:arcstats:evict_l2_cached 0 zfs:0:arcstats:evict_l2_eligible 2224128 zfs:0:arcstats:evict_l2_ineligible 4096 For this example system, you can see: + nothing is in the L2 cache (mostly, because there is no L2 :-) + 2224128 ARC evictions were eligible to be satisfied from an L2 cache + 4096 ARC evictions were not eligible This example system can benefit from an L2 cache. > > 3.) > As far as ZIL goes, do we need it? From the data below, yes, it will help > I think I read somewhere, that ZIL can only store 8k blocks and that you have to 'format' iscsi drives accordingly. Is that still the case? This was never the case, where did you read it? > Output from 'zilstat': > Code: > N-Bytes N-Bytes/s N-Max-Rate B-Bytes B-Bytes/s B-Max-Rate ops <=4kB 4-32kB >=32kB > 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 > 178352 178352 178352 262144 262144 262144 2 0 0 2 > 134823992 134823992 134823992 221380608 221380608 221380608 1689 0 0 1689 > 102893848 102893848 102893848 168427520 168427520 168427520 1285 0 0 1285 > 0 0 0 0 0 0 0 0 0 0 > 4472 4472 4472 131072 131072 131072 1 0 0 1 > 0 0 0 0 0 0 0 0 0 0 > 41904 41904 41904 262144 262144 262144 2 0 0 2 > 134963824 134963824 134963824 221511680 221511680 221511680 1690 0 0 1690 > 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 > 32789896 32789896 32789896 53346304 53346304 53346304 407 0 0 407 > 25467912 25467912 25467912 41811968 41811968 41811968 319 0 0 319 > Given the stats, is ZIL even necessary? When I'm running zilstat, I see big ops every 5s. Why is that? I know system is suppose to flush data from memory to spindles every 5s, but that shouldn't be seen as ZIL flush, is that correct? > > 4.) > How to put drives together, to get the best IOPS/capacity ratio out of them? We were thinking of 7 RAIDZ2 vdev's with 10 drives each. That way we would get around 224TB pool. This depends on the workload. For more IOPS, use more vdevs. > > 5.) > In case we decide to go with 4 JBOD cases, would it be better to build 2 pools, just so that in case 1 pool has a hickup, we won't loose all data? This is a common configuration: two SAS pools + two servers configured such that either server can serve the pool. -- richard > > What else am I not considering? > > Thanks, Matej > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Fri Apr 10 15:23:15 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 10 Apr 2015 08:23:15 -0700 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <8AD9538F-5F92-4355-B702-D88BB405F17E@omniti.com> References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> <8AD9538F-5F92-4355-B702-D88BB405F17E@omniti.com> Message-ID: <5603E5F8-F9A5-49BF-A3E7-5AA75C5A537A@richardelling.com> > On Apr 10, 2015, at 7:17 AM, Dan McDonald wrote: > > >> On Apr 10, 2015, at 10:10 AM, Schweiss, Chip wrote: >> >> This information certainly puts the pause on me moving to r151014 for my systems serving ESXi. >> >> My next suspicion would be that this would be an NFS locking issue. There were updates to the lock manager in r151014. Tcpdumps will reveal if that is the problem. >> > > The lock manager updates in '014 were to prevent the choking-at-boot-time seen in '010 and 012. The illumos community is aware there are further problems. (The bug report or code review for illumos 4518 talks about this.) I hope to have the next OmniOS bloody spun out soon, and then people can start keeping up with upstream again. It is my understanding that ESX doesn't use NFS locking, they implement their own. This makes sense, because NFSv2/3 locking has been problematic since the beginning, from all vendors. Again, this is easy to measure. -- richard From chip at innovates.com Fri Apr 10 15:59:30 2015 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 10 Apr 2015 10:59:30 -0500 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: <5603E5F8-F9A5-49BF-A3E7-5AA75C5A537A@richardelling.com> References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> <8AD9538F-5F92-4355-B702-D88BB405F17E@omniti.com> <5603E5F8-F9A5-49BF-A3E7-5AA75C5A537A@richardelling.com> Message-ID: On Fri, Apr 10, 2015 at 10:23 AM, Richard Elling < richard.elling at richardelling.com> wrote: > > It is my understanding that ESX doesn't use NFS locking, they implement > their own. > This makes sense, because NFSv2/3 locking has been problematic since the > beginning, > from all vendors. Again, this is easy to measure. > I thought that too, but looking in the advanced config, there are a couple tunables for nfs locks. NFS.LockRenewMaxFailureNumber, range 1-100, def 3 and NFS.LockUpdateTimeout, range 1-8 default 5. This is on ESXi 5.5. I don't have an non-production datastores connected to ESXi, or else I would test this right away. -Chip > -- richard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Fri Apr 10 17:39:19 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 10 Apr 2015 19:39:19 +0200 Subject: [OmniOS-discuss] [developer] Re: Strange bge0 messages in syslog. interrupt, flags - not updated? In-Reply-To: References: <433A63C1-4A65-4948-AFA2-F4C626B3E288@pipar-tbwa.is> <5A0ECE59-010C-47C3-8F92-54B13D5CE9E8@omniti.com> <1E032AB6-8E23-4466-B5BB-3DD80849C0AD@pipar-tbwa.is> Message-ID: <21800.2759.766419.87784@glaurung.bb-c.de> Davide Poletto writes: > Just for reference/comparison I'm too have a (spare machine with > only its 2GB ECC HP factory RAM module and 20131001 ROM BIOS) HP > MicroServer G7 - N40L - with the same onboard Broadcom Ethernet chip > and I too upgraded flawlessly from OmniOS 151012 to 151014 the day > before yesterday but, AFAIK, I can't see those bge0 notice logs. Same here. Exact same PCIe device, no "notice" messages. > Here latest (bge0 related) logs after a cold start: > > Apr 8 17:20:40 nas01 genunix: [ID 469746 kern.info] NOTICE: bge0 registered > Apr 8 17:20:40 nas01 genunix: [ID 586369 kern.info] PCIE-device: pci103c,705d at 0, bge0 > Apr 8 17:20:40 nas01 genunix: [ID 236367 kern.info] PCI Express-device: pci103c,705d at 0, bge0 > Apr 8 17:20:40 nas01 genunix: [ID 936769 kern.info] bge0 is /pci at 0,0/pci1022,9606 at 6/pci103c,705d at 0 > Apr 8 17:20:41 nas01 genunix: [ID 801725 kern.info] NOTICE: bge0: bge_mii_access: cmd 0x28390000 -- MI_COMMS_START set for 580 us; 0x24208000->0x4208000 [...] I see those same messages during reboot. The interface works fine. No more messages after that. If it helps, I also have a spare N40L that I can run tests on, including installing a new OS. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From richard.elling at richardelling.com Fri Apr 10 18:12:58 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 10 Apr 2015 11:12:58 -0700 Subject: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue In-Reply-To: References: <835418605.2262677.1428670278892.JavaMail.zimbra@cantekstil.com.tr> <865678079.2266136.1428674124197.JavaMail.zimbra@cantekstil.com.tr> <8AD9538F-5F92-4355-B702-D88BB405F17E@omniti.com> <5603E5F8-F9A5-49BF-A3E7-5AA75C5A537A@richardelling.com> Message-ID: > On Apr 10, 2015, at 8:59 AM, Schweiss, Chip wrote: > > On Fri, Apr 10, 2015 at 10:23 AM, Richard Elling > wrote: > > It is my understanding that ESX doesn't use NFS locking, they implement their own. > This makes sense, because NFSv2/3 locking has been problematic since the beginning, > from all vendors. Again, this is easy to measure. > > I thought that too, but looking in the advanced config, there are a couple tunables for nfs locks. NFS.LockRenewMaxFailureNumber, range 1-100, def 3 and NFS.LockUpdateTimeout, range 1-8 default 5. This is on ESXi 5.5. > > I don't have an non-production datastores connected to ESXi, or else I would test this right away. There are several ways to see lock activity on the server side: tcpdump, snoop, dtrace, etc. There is also kstats for lockd activity on some distros... but offhand I'm not sure exactly what is in which distro... if we're missing interesting stats we can add them to the open source lock manager :-) Meanwhile, the other tools can work. -- richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Sat Apr 11 05:24:15 2015 From: tobi at oetiker.ch (Tobias Oetiker) Date: Sat, 11 Apr 2015 07:24:15 +0200 (CEST) Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: References: Message-ID: Hi Nigel, Yesterday Nigel W wrote: > On Fri, Apr 10, 2015 at 7:52 AM, Tobias Oetiker wrote: > > > Hi, > > > > For the past few months I have been struggling with bad KVM nework > > performance on omnios R12 and R14. Especially under > > bidirectional load things are looking terrible (factor 1000). > > > > Every now and then there is a report on the mailinglist about such > > problems, but we have not yet seen anything really helpful. > > > > In my tests I have been using iperf to collect streaming tcp > > network performance on verious configurations. > > > > I realy want to see this solved. As an initial effort, I have setup > > a google spreadsheet to collect performance data. The sheet > > includes instructions on how to test and lets you record your test > > results: > > > > http://goo.gl/Vr1tC6 > > > > Please add your test results, or even better, figure out what is going > > wrong! > > > > cheers > > tobi > > > Is this measurement between the kvm guest and the host or the kvm guest > and another (presumably native) host on the network? the measurement is between the kvm guest and the host where kvm is running on. cheers tobi > > Thanks, > > > > ------------------------------------------- > smartos-discuss > Archives: https://www.listbox.com/member/archive/184463/=now > RSS Feed: https://www.listbox.com/member/archive/rss/184463/25228365-edc0b66b > Modify Your Subscription: https://www.listbox.com/member/?member_id=25228365&id_secret=25228365-9b5303ef > Powered by Listbox: http://www.listbox.com > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From danmcd at omniti.com Sat Apr 11 15:56:21 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 11 Apr 2015 11:56:21 -0400 Subject: [OmniOS-discuss] Bloody is now at r151015 Message-ID: <3BF56ACB-9DD0-4202-B84B-4E6CDD6DEE67@omniti.com> I've reinstalled the bloody repo with new r151015 bits: http://pkg.omniti.com/omnios/bloody/ NOTE: Bloody packages are still delivered unsigned, so if you update r151014 to bloody, YOU MUST RESET THE "omnios" PUBLISHER'S SIGNATURE POLICY! I've created a new wiki page about it: https://src.omniti.com/omnios-private/wiki.php/Bloody The starting date for this is 20150411, so look for that in your ISOs, USB, or Kayak images. Visit the "Installation" wiki page to get easy download links. The only changes from r151014 thus far are a few more merges with illumos-gate. Happy bleeding! Dan From contact at jacobvosmaer.nl Sat Apr 11 18:50:34 2015 From: contact at jacobvosmaer.nl (Jacob Vosmaer) Date: Sat, 11 Apr 2015 20:50:34 +0200 Subject: [OmniOS-discuss] Who here had lockd/nlockmgr problems? In-Reply-To: <305CC122-4584-4791-9D63-18C210FA3DC2@omniti.com> References: <968CF721-8839-49E2-8F04-9FD912E78E68@omniti.com> <9A9651B5-B71B-44D3-90C1-BCF96B4ECCE8@omniti.com> <54BE3F70.8080303@alcatel-lucent.com> <305CC122-4584-4791-9D63-18C210FA3DC2@omniti.com> Message-ID: Hi Dan, omnios-discuss As one of the people complaining about nfs/statmon issues in 151012 I would like to share my impression that this problem somehow went away in 151014. I have not done rigorous testing but prior to upgrading my OmniOS NFS server from 151012 to 151014 the statmon issue seemed to happen almost every time I booted the server, and since upgrading to 151014 I have not yet seen it happen once. A cautious hurray seems in order. 2015-01-20 16:40 GMT+01:00 Dan McDonald : > > > On Jan 20, 2015, at 6:43 AM, Paul Jochum > wrote: > > > > Hi Dan: > > > > Resurrecting an older thread here. > > > > Do you know if a fix was submitted for this problem, and if > submitted, if/when will it be picked up in OmniOS? > > > > We have had this problem when trying to upgrade multiple machines to > R151012 in our environment, and decided to stay at r151010 hoping it will > get fixed soon. > > There have been some changes in nlockmgr, but not *specifically* for that > problem. Given there's now a known workaround (deleting the files in > statmon), I think the community hasn't been as gung-ho to fix it. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sun Apr 12 00:54:58 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 11 Apr 2015 20:54:58 -0400 Subject: [OmniOS-discuss] Who here had lockd/nlockmgr problems? In-Reply-To: References: <968CF721-8839-49E2-8F04-9FD912E78E68@omniti.com> <9A9651B5-B71B-44D3-90C1-BCF96B4ECCE8@omniti.com> <54BE3F70.8080303@alcatel-lucent.com> <305CC122-4584-4791-9D63-18C210FA3DC2@omniti.com> Message-ID: <8BC7054C-BD70-45C9-AD81-47F67159DA21@omniti.com> > On Apr 11, 2015, at 2:50 PM, Jacob Vosmaer wrote: > > Hi Dan, omnios-discuss > > As one of the people complaining about nfs/statmon issues in 151012 I would like to share my impression that this problem somehow went away in 151014. I have not done rigorous testing but prior to upgrading my OmniOS NFS server from 151012 to 151014 the statmon issue seemed to happen almost every time I booted the server, and since upgrading to 151014 I have not yet seen it happen once. Illumos 4518 addressed the immediate problem of NLM & statd sabotaging each other. This solves the boot-time problem you were seeing a lot. There are subsequent fixes that the community will be addressing, but this one was finished in time for '014. Dan From richard at netbsd.org Sun Apr 12 06:12:03 2015 From: richard at netbsd.org (Richard PALO) Date: Sun, 12 Apr 2015 08:12:03 +0200 Subject: [OmniOS-discuss] updating to 151015 with local gate Message-ID: How to accomplish easily an update if [only] the illumos gate is locally built (i.e. not userland). > richard at omnis:/home/richard/src/illumos-gate$ LANG=C pkg publisher > PUBLISHER TYPE STATUS P LOCATION > on-nightly origin online F file:///home/richard/src/illumos-gate/packages/i386/nightly//repo.redist/ > omnios (non-sticky) origin online F http://pkg.omniti.com/omnios/bloody/ > richard at omnis:/home/richard/src/illumos-gate$ LANG=C pfexec pkg update -vn --be-name b151015 > Startup: Refreshing catalog 'on-nightly' ... Done > Startup: Refreshing catalog 'omnios' ... Done > Startup: Checking that pkg(5) is up to date ... Done > Planning: Solver setup ... Done (0.468s) > > 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/incorporation/jeos/omnios-userland at 11,5.11-0.151015:20150410T200015Z > pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151015:20150410T195834Z > > The following indicates why the system cannot update to the latest version: > > No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151015:20150410T195834Z found: > Reject: pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151015:20150410T195834Z > Reason: A version for 'incorporate' dependency on pkg:/SUNWcs at 0.5.11,5.11-0.151015 cannot be found > No suitable version of required package pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151015:20150410T200015Z found: > Reject: pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151015:20150410T200015Z > Reason: A version for 'incorporate' dependency on pkg:/compress/bzip2 at 1.0.6,5.11-0.151015 cannot be found > Seems omnios bloody is being insidiously 'racist' :) about incorporations... Is there a workaround? Setting omnios sticky and on-nightly non-sticky doesn't seem to solve anything. -- Richard PALO From jdg117 at elvis.arl.psu.edu Sun Apr 12 13:16:09 2015 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Sun, 12 Apr 2015 09:16:09 -0400 Subject: [OmniOS-discuss] Node.js Message-ID: <201504121316.t3CDG9ud008648@elvis.arl.psu.edu> Building Node.js has a couple quirks: Fetch libproc.h from Joyent's source tree. The binaries in pkg:/developer/gnu-binutils aren't in /usr/gnu/bin. Otherwise, its a straight-forward. John groenveld at acm.org $ cd node-v0.12.2 $ env PATH=/opt/nodejs/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/gcc-4.8.1/bin:/usr/sfw/bin:/usr/gnu/bin:/usr/gnu/i386-pc-solaris2.11/bin \ CC=gcc CXX=g++ ./configure \ --dest-os=solaris \ --dest-cpu=x64 \ --shared-openssl --shared-zlib \ --prefix=/opt/nodejs $ env PATH=/opt/nodejs/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/gcc-4.8.1/bin:/usr/sfw/bin:/usr/gnu/bin:/usr/gnu/i386-pc-solaris2.11/bin \ gmake *** common.gypi Sun Apr 12 09:07:56 2015 --- common.gypi.FCS Sun Apr 12 09:07:52 2015 *************** *** 75,81 **** }], ['OS=="solaris"', { # pull in V8's postmortem metadata ! 'ldflags': [ '-Wl,-z,allextract -L/usr/lib/64 -R/usr/lib/64 -L/usr/lib/mdb/proc/amd64 -R/usr/lib/mdb/proc/amd64' ] }], ['clang == 0 and gcc_version >= 40', { 'cflags': [ '-fno-tree-vrp' ], # Work around compiler bug. --- 75,81 ---- }], ['OS=="solaris"', { # pull in V8's postmortem metadata ! 'ldflags': [ '-Wl,-z,allextract' ] }], ['clang == 0 and gcc_version >= 40', { 'cflags': [ '-fno-tree-vrp' ], # Work around compiler bug. From danmcd at omniti.com Sun Apr 12 21:19:34 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 12 Apr 2015 17:19:34 -0400 Subject: [OmniOS-discuss] updating to 151015 with local gate In-Reply-To: References: Message-ID: > On Apr 12, 2015, at 2:12 AM, Richard PALO wrote: > > Seems omnios bloody is being insidiously 'racist' :) about incorporations... > > Is there a workaround? > Setting omnios sticky and on-nightly non-sticky doesn't seem to solve anything. You need to match ONNV_BUILDNUM in illumos-omnios's .env file with whatever you wish to ONU: # SET ONNV_BUILDNUM to override the current "151015" of OmniOS. ONNV_BUILDNUM=151015 Make sure those are in your env file if you wish to ONU r151015. Dan From danmcd at omniti.com Sun Apr 12 21:23:07 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 12 Apr 2015 17:23:07 -0400 Subject: [OmniOS-discuss] Node.js In-Reply-To: <201504121316.t3CDG9ud008648@elvis.arl.psu.edu> References: <201504121316.t3CDG9ud008648@elvis.arl.psu.edu> Message-ID: <9FF6F369-AF38-42A8-8CB5-35BF7E038BFA@omniti.com> Thanks for sharing. The omniti-ms branch of omnios-build still builds 0.10.21. If they wish to jump, they should probably take your patch as an entry for patches/ inside the nodejs build directory. Thanks! Dan From matej at zunaj.si Mon Apr 13 10:16:24 2015 From: matej at zunaj.si (Matej Zerovnik) Date: Mon, 13 Apr 2015 12:16:24 +0200 Subject: [OmniOS-discuss] Building a new storage In-Reply-To: References: <5527A337.5060405@zunaj.si> Message-ID: <552B9778.7010306@zunaj.si> Hello Richard. Thank you very much for your answer. On 10. 04. 2015 17:19, Richard Elling wrote: > [sidebar conversation: I've experienced bad results with WD Black 4TB > SAS drives] What kind of bad results? What drives do you use now or what do you recommend? I was thinking of going with HGST anyway, since they got a good reputation on Backblaze reports. > But the more interesting question is: where do you plan to measure the > IOPS? The backend stats > as seen by iostat and zpool iostat are difficult to use because they > do not account for caching and > the writes are coalesced. Write coalescing is particularly important > for people who insist on counting > IOPS because, by default, 32 4KB random write IOPS will be coalesced > into one 128KB write. Let's > take a closer look at your data... Thank you for explaining this. A lot clearer now. Where are write ops coalesced? In memory/ZIL? In drive cache? >> Output from iostat -vx (only some drives are pasted): >> Code: >> device r/s w/s kr/s kw/s wait actv svc_t %w %b >> data 36621,9 25740,2 19288,6 66191,0 197,6 25,9 3,6 40 77 >> sd18 276,3 104,8 145,2 83,3 0,0 0,6 1,5 0 36 > > This version of iostat doesn't show average sizes :-( but you can > calculate them from the data :-) Is there a version that does that? I see they can be calculated, but it might be nice to see results right there:) Is it in official repo or do I have to get it somewhere else? > From this we can suggest: > 1. avoid 4KB sector sized disks for this configuration and workload > 2. look further up the stack to determine why such small physical I/Os > are being used I will take a look at the enterprise drives, but I think most of them are still 512b. I will be on alert when ordering the new drives. As far as looking up the stack, where can I look for that? Is there something that can be done on the server itself or do I have to check that on iscsi clients? > >> Is it just me, or are there too much IOPS for those drive to handle >> even in theory, let alone in practice? How to get the right measurement? > > To measure IOPS written into the pool, look at fsstat for file > systems. For iSCSI, this isn't > quite so easy to gather, so we use dtrace, see iscsisvrtop as an example. Looking at iscsivrtop, I see around 260 r ops(10MB/s) and 140 w ops(14MB/s) total: client ops reads writes nops rd_bw wr_bw ard_sz awr_sz rd_t wr_t nop_t align% xxx.xxx.140.38 70 49 21 0 498 2201 1 10 6 6154 0 100 xxx.xxx.57.158 114 38 67 0 1210 7699 3 11 58 697704 0 100 xxx.xxx.7.3 233 188 46 0 9240 1241 4 2 5235 11183 0 100 all 446 284 148 0 11204 12641 3 8 3453 326634 0 0 Why are numbers here smaller then the one reported by 'iostat' and 'zpool iostat'? > Unfortunately, most versions of arcstat do not measure what you want > to know. The measurement > you're looking for is the reason for eviction. These are measured as > kstats: > # kstat -p ::arcstats:evict_l2\* > zfs:0:arcstats:evict_l2_cached 0 > zfs:0:arcstats:evict_l2_eligible 2224128 > zfs:0:arcstats:evict_l2_ineligible 4096 > > For this example system, you can see: > + nothing is in the L2 cache (mostly, because there is no L2 :-) > + 2224128 ARC evictions were eligible to be satisfied from an L2 cache > + 4096 ARC evictions were not eligible > > This example system can benefit from an L2 cache. I'm not sure if I understand this. What does evict_l2_eligible and evict_l2_ineligible mean? 'ARC evictions were eligible to be satisfied from an L2 cache' <-- 2224128 arc evictions would be moved to l2 and serviced from l2 arc, so l2 arc would help in 2224128 cases? If that is the case, eligible value needs to be high for l2 to make sense? This are the stats from our server: kstat -p ::arcstats:evict_l2\* zfs:0:arcstats:evict_l2_cached 10717615626752 zfs:0:arcstats:evict_l2_eligible 13868417704448 zfs:0:arcstats:evict_l2_ineligible 8230791512064 zfs:0:arcstats:evict_l2_skip 174367 What do those stats tell me? Eligible counter is high, is it safe to assume, bigger l2 cache would help us? Would it be better to add more vdev's instead of bigger l2 cache? >> *3.)* >> As far as ZIL goes, do we need it? > > From the data below, yes, it will help > >> Output from 'zilstat': >> Code: >> N-Bytes N-Bytes/s N-Max-Rate B-Bytes B-Bytes/s B-Max-Rate ops <=4kB 4-32kB >=32kB >> 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 >> 178352 178352 178352 262144 262144 262144 2 0 0 2 >> 134823992 134823992 134823992 221380608 221380608 221380608 1689 0 0 1689 >> 102893848 102893848 102893848 168427520 168427520 168427520 1285 0 0 1285 >> 0 0 0 0 0 0 0 0 0 0 >> 4472 4472 4472 131072 131072 131072 1 0 0 1 >> 0 0 0 0 0 0 0 0 0 0 >> 41904 41904 41904 262144 262144 262144 2 0 0 2 >> 134963824 134963824 134963824 221511680 221511680 221511680 1690 0 0 1690 >> 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 >> 32789896 32789896 32789896 53346304 53346304 53346304 407 0 0 407 >> 25467912 25467912 25467912 41811968 41811968 41811968 319 0 0 319 >> Given the stats, is ZIL even necessary? When I'm running zilstat, I >> see big ops every 5s. Why is that? I know system is suppose to flush >> data from memory to spindles every 5s, but that shouldn't be seen as >> ZIL flush, is that correct? Would you be so kind and interpret the data a bit. What can I see and what can I gather from this data? What are N-bytes and B-bytes? What I see here are writes directly to ZIL and data are only written to ZIL, if I set sync option to always or if iscsi client mounts it's device with sync options, right? Would you consider this zil as a big performance benefit for our system or would it be better to spent money on more vdev's? > >> >> *5.)* >> In case we decide to go with 4 JBOD cases, would it be better to >> build 2 pools, just so that in case 1 pool has a hickup, we won't >> loose all data? > > This is a common configuration: two SAS pools + two servers configured > such that either server can > serve the pool. How do you usually achieve that? Do you also use RSF-1 software or do you use other solutions? Matej -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.barfield at bissinc.com Mon Apr 13 16:25:42 2015 From: john.barfield at bissinc.com (John Barfield) Date: Mon, 13 Apr 2015 16:25:42 +0000 Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: References: Message-ID: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> I can confirm that I?ve seen the same behaviors. I?ll try to pull some numbers but the truth is that debian based guest versions perform WAY better than CentOS guests. From all of my testing IMHO it is the host (illumos) virtio implementation. I only say this because I see such drastic performance results between different guest virtio driver version on illumos hosts that I do not see on Linux hosts. I can also confirm that I did not see this issue on SmartOS and I did test, Widows, Centos, And Ubuntu and was able to achieve near wire speed guest-2-guest on different SmartOS hosts. Here is my original thread posted about this in march: http://lists.omniti.com/pipermail/omnios-discuss/2015-March/004539.html John Barfield / Sr Principal Engineer +1 (214) 425-0783/ john.barfield at bissinc.com BISS, Inc. Office: +1 (214) 506-8354 4925 Greenville Ave Suite 900 Dallas, TX 75206 support.bissinc.com This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. On 4/11/15, 12:24 AM, "Tobias Oetiker" wrote: >Hi Nigel, > >Yesterday Nigel W wrote: > >> On Fri, Apr 10, 2015 at 7:52 AM, Tobias Oetiker wrote: >> >> > Hi, >> > >> > For the past few months I have been struggling with bad KVM nework >> > performance on omnios R12 and R14. Especially under >> > bidirectional load things are looking terrible (factor 1000). >> > >> > Every now and then there is a report on the mailinglist about such >> > problems, but we have not yet seen anything really helpful. >> > >> > In my tests I have been using iperf to collect streaming tcp >> > network performance on verious configurations. >> > >> > I realy want to see this solved. As an initial effort, I have setup >> > a google spreadsheet to collect performance data. The sheet >> > includes instructions on how to test and lets you record your test >> > results: >> > >> > http://goo.gl/Vr1tC6 >> > >> > Please add your test results, or even better, figure out what is going >> > wrong! >> > >> > cheers >> > tobi >> > >> Is this measurement between the kvm guest and the host or the kvm guest >> and another (presumably native) host on the network? > > >the measurement is between the kvm guest and the host where kvm is >running on. > >cheers >tobi > >> >> Thanks, >> >> >> >> ------------------------------------------- >> smartos-discuss >> Archives: https://www.listbox.com/member/archive/184463/=now >> RSS Feed: >>https://www.listbox.com/member/archive/rss/184463/25228365-edc0b66b >> Modify Your Subscription: >>https://www.listbox.com/member/?member_id=25228365&id_secret=25228365-9b5 >>303ef >> Powered by Listbox: http://www.listbox.com >> > >-- >Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland >www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss From tobi at oetiker.ch Mon Apr 13 16:40:19 2015 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 13 Apr 2015 18:40:19 +0200 (CEST) Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> Message-ID: Hi John Today John Barfield wrote: > I can confirm that I?ve seen the same behaviors. > > I?ll try to pull some numbers but the truth is that debian based > guest versions perform WAY better than CentOS guests. > > From all of my testing IMHO it is the host (illumos) virtio > implementation. > > I only say this because I see such drastic performance results > between different guest virtio driver version on illumos hosts > that I do not see on Linux hosts. > > I can also confirm that I did not see this issue on SmartOS and I > did test, Widows, Centos, And Ubuntu and was able to achieve near > wire speed guest-2-guest on different SmartOS hosts. > > Here is my original thread posted about this in march: > http://lists.omniti.com/pipermail/omnios-discuss/2015-March/004539.html if you look at the spreadsheet you can see that the problem also affects the e1000 driver ... and since nothing has changed in kvm between r10 and r12 (as dan pointed out in a earlier thread) my guess is that the problem is due to some unfortunate interaction between kvm and some other changes. the spreadsheet now contains results from quite a number of different configurations ... http://goo.gl/Vr1tC6 fact is, that we are in a pretty bad place with OmniOS now for our production systems, as support for r10 is over and we can not upgrade without totally killing performance ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From mir at miras.org Mon Apr 13 16:41:35 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 13 Apr 2015 18:41:35 +0200 Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> Message-ID: <20150413184135.70fb9410@sleipner.datanom.net> On Mon, 13 Apr 2015 16:25:42 +0000 John Barfield 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? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: You are here: *** *** ********* ******* ***** *** * But you're not all there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From john.barfield at bissinc.com Mon Apr 13 16:46:55 2015 From: john.barfield at bissinc.com (John Barfield) Date: Mon, 13 Apr 2015 16:46:55 +0000 Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: <20150413184135.70fb9410@sleipner.datanom.net> References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> <20150413184135.70fb9410@sleipner.datanom.net> Message-ID: <01F9F0FB-30EC-4AFE-ABD2-E765D0222807@bissinc.com> CentOS still uses the traditional 2.6 numbering convention and back ports modules and features that they feel should be back ported while Ubuntu/Debian is following the kernel.org release cycle. (For the most part). In other words?its hard to tell the differences. I spent the better part of a couple of days trying to determine the built in virtio driver version and was not successful. So Centos is something like 2.6.32 (I?ll have to verify the actual 3rd octet) and Ubuntu is 3.8.X?again I?m just talking now but I?ll get the versions and verify. I?ve been redirected to several other projects so just had to deal with running Ubuntu as a solution to the performance problem at the time because I had already spent 2 weeks debugging CentOS. John Barfield / Sr Principal Engineer +1 (214) 425-0783/ john.barfield at bissinc.com BISS, Inc. Office: +1 (214) 506-8354 4925 Greenville Ave Suite 900 Dallas, TX 75206 support.bissinc.com This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. On 4/13/15, 11:41 AM, "Michael Rasmussen" wrote: >On Mon, 13 Apr 2015 16:25:42 +0000 >John Barfield 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? > >-- >Hilsen/Regards >Michael Rasmussen > >Get my public GnuPG keys: >michael rasmussen cc >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >mir datanom net >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >mir miras org >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >-------------------------------------------------------------- >/usr/games/fortune -es says: >You are here: > *** > *** > ********* > ******* > ***** > *** > * > > But you're not all there. From tobi at oetiker.ch Mon Apr 13 16:48:44 2015 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 13 Apr 2015 18:48:44 +0200 (CEST) Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: <20150413184135.70fb9410@sleipner.datanom.net> References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> <20150413184135.70fb9410@sleipner.datanom.net> Message-ID: Michael, Today Michael Rasmussen wrote: > On Mon, 13 Apr 2015 16:25:42 +0000 > John Barfield 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 tobi at oetiker.ch +41 62 775 9902 From mir at miras.org Mon Apr 13 17:28:44 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 13 Apr 2015 19:28:44 +0200 Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> <20150413184135.70fb9410@sleipner.datanom.net> Message-ID: <20150413192844.0cb5073b@sleipner.datanom.net> On Mon, 13 Apr 2015 18:48:44 +0200 (CEST) Tobias Oetiker wrote: > > BUT what worries me, is that between omnios r10 and r14 (r12 > actually) there is a factor of 1000 or more !!! > Just a long shot. Has the compiler and linker used to build kernel and modules changed between r10 - r14? Newer compiler versions sometimes introduces new compiler flags and abandon older flags. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It is not good for a man to be without knowledge, and he who makes haste with his feet misses his way. -- Proverbs 19:2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mir at miras.org Mon Apr 13 17:30:16 2015 From: mir at miras.org (Michael Rasmussen) Date: Mon, 13 Apr 2015 19:30:16 +0200 Subject: [OmniOS-discuss] Fw: [smartos-discuss] kvm network performance survey Message-ID: <20150413193016.299bb5ed@sleipner.datanom.net> Sorry missed list address in reply. Begin forwarded message: Date: Mon, 13 Apr 2015 19:26:39 +0200 From: Michael Rasmussen To: John Barfield Subject: Re: [OmniOS-discuss] [smartos-discuss] kvm network performance survey On Mon, 13 Apr 2015 16:46:55 +0000 John Barfield wrote: > > So Centos is something like 2.6.32 (I?ll have to verify the actual 3rd > octet) and Ubuntu is 3.8.X?again I?m just talking now but I?ll get the > versions and verify. > This means CentOS 6.x. Have you tried CentOS 7.x since this comes with kernel 3.10? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It is not good for a man to be without knowledge, and he who makes haste with his feet misses his way. -- Proverbs 19:2 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It is not good for a man to be without knowledge, and he who makes haste with his feet misses his way. -- Proverbs 19:2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 13 17:35:11 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 13 Apr 2015 13:35:11 -0400 Subject: [OmniOS-discuss] [smartos-discuss] kvm network performance survey In-Reply-To: <20150413192844.0cb5073b@sleipner.datanom.net> References: <78CDE39A-278A-4605-AAC2-3A1600566A2B@bissinc.com> <20150413184135.70fb9410@sleipner.datanom.net> <20150413192844.0cb5073b@sleipner.datanom.net> Message-ID: <43B66AE4-0F34-4247-8E2C-01A8E504A231@omniti.com> > On Apr 13, 2015, at 1:28 PM, Michael Rasmussen wrote: > > On Mon, 13 Apr 2015 18:48:44 +0200 (CEST) > Tobias Oetiker wrote: > >> >> BUT what worries me, is that between omnios r10 and r14 (r12 >> actually) there is a factor of 1000 or more !!! >> > Just a long shot. Has the compiler and linker used to build kernel and > modules changed between r10 - r14? > > Newer compiler versions sometimes introduces new compiler flags and > abandon older flags. No. No changes there. Dan From lists at marzocchi.net Tue Apr 14 07:27:52 2015 From: lists at marzocchi.net (Olaf Marzocchi) Date: Tue, 14 Apr 2015 09:27:52 +0200 Subject: [OmniOS-discuss] Issues with smb and Android Message-ID: <206825BC-2547-4DFB-BA6B-EF97C1795BE7@marzocchi.net> Hello, the question is a bit vague but I cannot find any solution, so I ask here. I?m using OmniOS r151012 right now, but the issue has always been there since r151006. I shared some datasets using the kernel smb: > $ sharemgr show -vp > default nfs=() > smb smb=() > * /var/smb/cvol smb=() "" > c$=/var/smb/cvol smb=(abe="false" guestok="false") "Default Share" > zfs smb=() nfs=() > zfs/tank/Temporary smb=() > Temporary=/tank/Temporary > zfs/tank/home/olaf smb=() > olaf=/tank/home/olaf > zfs/tank/home/olaf/Photos smb=() > olaf_photos=/tank/home/olaf/Photos When I log in from Win 8.1 or OS X using DOMAIN\user, no problems. When I login from Android (app tested: several, among them "File Manager HD" and "ES File Explorer?) I get a authentication error. Most of the apps repeat it indefinitely even if I try again, however with "File Manager HD? I can try a second time (no changes in the settings) and I get authenticated. Every single time, on the second attempt, it works! I get this on the /var/adm/messages: > smbd[636]: [ID 812811 daemon.notice] logon[OMNIOS-XEON\olaf]: WRONG_PASSWORD > last message repeated 1 time I don?t know why it is repeated a second time, maybe the app File Manager HD tries twice without notifying me. I cannot understand the source of the problem: pass correct, sharing standard using zfs. The permissions of the folders: > drwxrws---+ 27 root temps 156 Apr 13 20:08 Temporary > owner@:rwxpdDaARWcCos:fd-----:allow > group@:rwxpdDaARWcCos:fd-----:allow > everyone@:rwxpdDaARWcCos:fd-----:deny > drwxrwx---+ 16 olaf olaf 16 Apr 13 23:32 olaf > owner@:rwxpdDaARWcCos:fd-----:allow > group@:rwxpdDaARWcCos:fd-----:allow > everyone@:rwxpdDaARWcCos:fd-----:deny I didn?t post the whole "zfs get? details of the dataset, but I will if you let me know which ones may affect the issue. My datasets were set using these instruction: http://www.marzocchi.net/Olafsen/Software/InstallationOfOmniOSAndBasicSetup (second half of the article). Any help would be greatly appreciated. Thank you! Olaf From sequoiamobil at gmx.net Tue Apr 14 10:25:05 2015 From: sequoiamobil at gmx.net (Sebastian Gabler) Date: Tue, 14 Apr 2015 12:25:05 +0200 Subject: [OmniOS-discuss] ZFS data set corruption In-Reply-To: References: Message-ID: <552CEB01.70703@gmx.net> Hi, I recently migrated from OI 151a7 to Omnios April 2015 LTS with my backup ZFS file server. Probably because of vibration-related issues a pool was corrupted during the first nightly backup. Several attempts to resilver the pool ended with checksum errors in one of the raidz vdevs, so I decided to try a recovery. The affetced files were the file that was being written when the first error occurred, and two blocks in pool/datasets/corrupted_dataset itself. A further salience was that copying some files under corrupted_dataset could not be read (bad exchange descriptor error). From other reports on that error message, I concluded that deleting the files would not work either, so I skipped that. Exporting pool did not work anymore (pool busy error, even with -f) Now, when trying to destroy 'pool/datasets/corrupted_dataset', I got a kernel panic. The same happened when trying to import -nfF the pool, after forcing an export with the pool not mounted on reboot. So, I decided to cut my losses and re-create all datasets from scratch, without further analyzing the reasons. Any ideas how I could have done better with an additional work of 2-3 h (5.7 TB dataset)? BR Sebastian From danmcd at omniti.com Tue Apr 14 13:56:02 2015 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 14 Apr 2015 09:56:02 -0400 Subject: [OmniOS-discuss] ZFS data set corruption In-Reply-To: <552CEB01.70703@gmx.net> References: <552CEB01.70703@gmx.net> Message-ID: > On Apr 14, 2015, at 6:25 AM, Sebastian Gabler wrote: > > Now, when trying to destroy 'pool/datasets/corrupted_dataset', I got a kernel panic. The same happened when trying to import -nfF the pool, after forcing an export with the pool not mounted on reboot. Do you still have those kernel coredumps? Those help in debugging. The OmniOS ZFS code is up to date with the upstream illumos-gate code, so this panic exists in the upstream ZFS code as well. I know some sorts of data corruption will cause ZFS to panic, but they have to be specific types. If you've the kernel corefiles, please share them. Thanks, Dan From omnios at citrus-it.net Wed Apr 15 18:22:04 2015 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 15 Apr 2015 18:22:04 +0000 (UTC) Subject: [OmniOS-discuss] package/pkg/depot dependencies Message-ID: Just moving our IPS repo over to a new r151014 server and mistakenly tried to install package/pkg/depot along the way. I don't need this package but I did notice that it has a couple of dependencies on non-existent apache-22 packages; at least non-existent in the main omnios repo. vault# (22) pkg install depot Creating Plan (Solver setup): - pkg install: No matching version of package/pkg/depot can be installed: Reject: pkg://omnios/package/pkg/depot at 0.5.11,5.11-0.151014:20150402T184310Z Reason: A version for 'require' dependency on pkg:/web/server/apache-22 cannot be found zsh: exit 1 pkg install depot vault# (23) pkg contents -rm depot | grep '^depend' | grep -v pkg: depend fmri=web/server/apache-22 type=require depend fmri=web/server/apache-22/module/apache-wsgi-26 type=require Should this package be in the main repo? Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From eric.sproul at circonus.com Wed Apr 15 18:32:26 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Wed, 15 Apr 2015 14:32:26 -0400 Subject: [OmniOS-discuss] package/pkg/depot dependencies In-Reply-To: References: Message-ID: On Wed, Apr 15, 2015 at 2:22 PM, Andy Fiddaman wrote: > > Just moving our IPS repo over to a new r151014 server and mistakenly tried > to install package/pkg/depot along the way. I don't need this package but I > did notice that it has a couple of dependencies on non-existent apache-22 > packages; at least non-existent in the main omnios repo. > > vault# (22) pkg install depot > Creating Plan (Solver setup): - > pkg install: No matching version of package/pkg/depot can be installed: > Reject: > pkg://omnios/package/pkg/depot at 0.5.11,5.11-0.151014:20150402T184310Z > Reason: A version for 'require' dependency on pkg:/web/server/apache-22 > cannot be found That looks like a new package that comes from the OI pkg(5) that we are now downstream of. We may just want to elide that package from OmniOS, as it looks to be just config for an Apache httpd proxy in front of pkg.depotd, and OmniOS does not ship Apache httpd. Eric From davide.poletto at gmail.com Thu Apr 16 09:51:58 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 11:51:58 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. Message-ID: Hello list, I did a fresh OmniOS 151014 install, during setup I set Timezone to my time zone (which is "Europe/Rome" because the server is going to be used in Italy) and physical Keyboard layout to Italian (I selected Keyboard Layout as 21 "Italian" when the default one is 47 "US-English") as per installer's requests. Now I've a question which is mostly related to the vi usage and was valid with every OmniOS versions I tested so far: I never been able to use vi editor in OmniOS as I do (entering editing mode, writing characters, deleting ones, etc.) in Linux because it seems it doesn't recognize any expected key combinations. Is it possible that I have a general issue with my locale settings and so the vi editor doesn't recognize properly any command I execute (and sequence of those commands like ESC+a to insert or ESC+Shift+: to go to vi's prompt for saving, quitting, etc.)? I noticed that not all my Italian keyboard's keys are printed out (or recognized at all) on the OmniOS's shell. As example, all the accent characters like "?", "?", "?", "?", "?" or "?" are not recognized and the Numerical Keypad available on the right, when disabled via the Bloc Num key, provide this strange keys mapping: 1 goes to a string's end 2 shows next commands, if any in Shell history 3 prints "z" 4 moves the cursor left along a string if this one was written on the prompt 5 prints "z" 6 moves the cursor right along a string if this one was written on the prompt 7 goes to a string's start 8 shows previous commands, if any in Shell history 9 prints "z" / prints "z" * prints "z" - prints "4z" + prints "3z" Enter prints "0z" . prints "9z" 0 prints "7z" which is somewhat curious. Just for reference (as OmniOS's root) below what my OmniOS reports: *kbd -l* type=6 layout=14 (0x0e) delay(ms)=500 rate(ms)=40 *cat /etc/default/init* TZ="Europe/Rome" CMASK=022 *locale* LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= *locale -a|grep "it_IT"* it_IT.ISO8859-15 it_IT.UTF-8 Could anybody provide me some help with that? Simple tasks like editing the /etcvssh/sshd_config to enable SSH Root access or editing the "omnios_zpool_install.pl" script (during the OmniOS install phase) is and was always an hard task with vi on OmniOS! Thanks, Davide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Thu Apr 16 10:03:33 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 16 Apr 2015 12:03:33 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: Message-ID: <21807.35061.144097.898163@glaurung.bb-c.de> Hi Davide! > Now I've a question which is mostly related to the vi usage and was > valid with every OmniOS versions I tested so far: I never been able > to use vi editor in OmniOS as I do (entering editing mode, writing > characters, deleting ones, etc.) in Linux because it seems it > doesn't recognize any expected key combinations. >From the output in your message, I assume that you use an USB keyboard connected directly to your OmniOS server console. What shell are you using? What does your $TERM variable contain? Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From davide.poletto at gmail.com Thu Apr 16 10:13:14 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 12:13:14 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.35061.144097.898163@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: Hi Volker, Yes, physical USB Italian keyboard directly connected to my little HP MicroServer G7 (or G8, no matter). I'm using the default OmniOS Shell...after login: echo $SHELL /usr/bin/bash echo $TERM sun-color They're default, never touched (as the /root/.profile file too). I'm starting to have few suspects there is something wrong with these "default" settings...Isn't it Volker? Davide. On Thu, Apr 16, 2015 at 12:03 PM, Volker A. Brandt wrote: > Hi Davide! > > > > Now I've a question which is mostly related to the vi usage and was > > valid with every OmniOS versions I tested so far: I never been able > > to use vi editor in OmniOS as I do (entering editing mode, writing > > characters, deleting ones, etc.) in Linux because it seems it > > doesn't recognize any expected key combinations. > > From the output in your message, I assume that you use an USB keyboard > connected directly to your OmniOS server console. > > What shell are you using? What does your $TERM variable contain? > > > Regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Thu Apr 16 10:21:37 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 12:21:37 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.35061.144097.898163@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: Hi Volker, forgot to add that also echo $BASH reports /usr/bin/bash Davide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at netbsd.org Thu Apr 16 10:53:21 2015 From: richard at netbsd.org (Richard PALO) Date: Thu, 16 Apr 2015 12:53:21 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: Le 16/04/15 12:13, Davide Poletto a ?crit : > Hi Volker, > > Yes, physical USB Italian keyboard directly connected to my little HP > MicroServer G7 (or G8, no matter). > > I'm using the default OmniOS Shell...after login: > > echo $SHELL > /usr/bin/bash > > echo $TERM > sun-color > > They're default, never touched (as the /root/.profile file too). > > I'm starting to have few suspects there is something wrong with these > "default" settings...Isn't it Volker? > > Davide. > What is TERMINFO? I haven't had much time to really dig into the matter, but I seem to remember although /usr/gnu/lib/terminfo was fine on OI, it's not really on omnios. Most of the strangeness I've experienced (french keyboard) seemed to go away when using either /usr/share/lib/terminfo or in my case pkgsrc terminfo database... From vab at bb-c.de Thu Apr 16 10:57:32 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 16 Apr 2015 12:57:32 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: <21807.38300.73907.267470@glaurung.bb-c.de> > Yes, physical USB Italian keyboard directly connected to my little > HP MicroServer G7 (or G8, no matter). I am using exactly the same, original Chicony/HP USB keyboard directly connected to an HP N54L (G7). It is a German keyboard of course. :-) > I'm using the default OmniOS Shell...after login: > > echo $SHELL /usr/bin/bash > > echo $TERM sun-color > > They're default, never touched (as the /root/.profile file too). > > I'm starting to have few suspects there is something wrong with > these "default" settings...Isn't it Volker? No, the default works just fine for me and always has: root at nfs:/root# pkg list -H entire entire 11-0.151014 i-- root at nfs:/root# echo $SHELL /usr/bin/bash root at nfs:/root# echo $TERM sun-color root at nfs:/root# kbd -l type=6 layout=9 (0x09) delay(ms)=500 rate(ms)=40 All keys work fine in vi, including the arrow keys, also those in the numerical keypad. I can enter all special characters (like German umlauts, ????). I do not have LANG and any LC_* variable set in my root environment. So, in the shell I need to press the bash escape character (^V): root at nfs:/root# echo ^V? ? Try unsetting LANG and LC_* and see if the arrow keys work. Hope this helps -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From davide.poletto at gmail.com Thu Apr 16 11:07:46 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 13:07:46 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: Hi Richard, echo $TERMINFO reports only a blank line on my system. Davide. On Thu, Apr 16, 2015 at 12:53 PM, Richard PALO wrote: What is TERMINFO? > > I haven't had much time to really dig into the matter, but I seem to > remember although /usr/gnu/lib/terminfo was fine on OI, it's not really on > omnios. Most of the strangeness I've experienced (french keyboard) seemed > to go away when using either /usr/share/lib/terminfo or in my case pkgsrc > terminfo database... > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Thu Apr 16 11:11:18 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 13:11:18 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.38300.73907.267470@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> Message-ID: I will try to set locale so it will report: LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_ALL= even if it will be difficult with my crazy vi editor...and tell you back. Thanks, Davide. On Thu, Apr 16, 2015 at 12:57 PM, Volker A. Brandt wrote: > > Yes, physical USB Italian keyboard directly connected to my little > > HP MicroServer G7 (or G8, no matter). > > I am using exactly the same, original Chicony/HP USB keyboard directly > connected to an HP N54L (G7). It is a German keyboard of course. :-) > > > I'm using the default OmniOS Shell...after login: > > > > echo $SHELL /usr/bin/bash > > > > echo $TERM sun-color > > > > They're default, never touched (as the /root/.profile file too). > > > > I'm starting to have few suspects there is something wrong with > > these "default" settings...Isn't it Volker? > > No, the default works just fine for me and always has: > > root at nfs:/root# pkg list -H entire > entire 11-0.151014 i-- > > root at nfs:/root# echo $SHELL > /usr/bin/bash > > root at nfs:/root# echo $TERM > sun-color > > root at nfs:/root# kbd -l > type=6 > layout=9 (0x09) > delay(ms)=500 > rate(ms)=40 > > All keys work fine in vi, including the arrow keys, also those in > the numerical keypad. I can enter all special characters (like > German umlauts, ????). > > I do not have LANG and any LC_* variable set in my root environment. > So, in the shell I need to press the bash escape character (^V): > > root at nfs:/root# echo ^V? > ? > > Try unsetting LANG and LC_* and see if the arrow keys work. > > > Hope this helps -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Thu Apr 16 11:18:40 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 16 Apr 2015 13:18:40 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> Message-ID: <21807.39568.46208.745940@glaurung.bb-c.de> > I will try to set locale so it will report: > > LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= > LC_MESSAGES= LC_ALL= Forget locale. Just set the variables in your bash session. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From davide.poletto at gmail.com Thu Apr 16 11:30:51 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 13:30:51 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.39568.46208.745940@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: You mean into /etc/default/init ? OK...I did that by echoing those lines (not the LANG parameter which I left blank as is) and settings it_IT.UTF-8 Now special characters are printed correctly (e.g. "?" or "?") but vi editor way of input commands is still a true mess: I'm still unable to enter the INSERT mode (via ESC + a) to type what I want, ESC + Shift + : works and I'm able to place commands like q! or wq and so on. Really don't know why vi behaves in such way. On Thu, Apr 16, 2015 at 1:18 PM, Volker A. Brandt wrote: > > I will try to set locale so it will report: > > > > LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= > > LC_MESSAGES= LC_ALL= > > Forget locale. Just set the variables in your bash session. > > > Regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Thu Apr 16 11:35:33 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 13:35:33 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.39568.46208.745940@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Now locale shows these settings: LANG= LC_CTYPE=it_IT.UTF-8 LC_NUMERIC=it_IT.UTF-8 LC_TIME=it_IT.UTF-8 LC_COLLATE=it_IT.UTF-8 LC_MONETARY=it_IT.UTF-8 LC_MESSAGES="C" LC_ALL= On Thu, Apr 16, 2015 at 1:18 PM, Volker A. Brandt wrote: > > I will try to set locale so it will report: > > > > LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= > > LC_MESSAGES= LC_ALL= > > Forget locale. Just set the variables in your bash session. > > > Regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Thu Apr 16 12:35:33 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 14:35:33 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <21807.39568.46208.745940@glaurung.bb-c.de> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Hi Volker, I reset the locale via /etc/default/init so the situation is now the initial one with locale that shows: LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= With these parameters (I suspect with the LC_CTYPE not set to it_IT.UTF-8 as I tested before) the Keyboard layout is the initial one and I've lost the characters like "?" or "?" that worked with it_IT.UTF-8. I can live with that...the point is still the vi editor. It's nearly impossible to use it to edit any configuration file. Once vi is launched I'm used to enable the INSERT mode with ESC + a and then start editing (this happens in Linux), in this case if I press ESC + a vi doesn't enter into INSERT mode at all and consequent keys that are pressed are wihtout any sense for me...as example if I press the Up Key to move up vi prints the letter "B", what is interesting is that if I press ESC once again it switches into another mode...and pressing the "dd" will delete the line on which the cursor is (dd delete) so there something weird about vi and my configuration (which is the default as per OmniOS fresh install) <- This behaviour was the same with every single OmniOS install I did in the past (same Timezone, same Keyboard layout). Davide. On Thu, Apr 16, 2015 at 1:18 PM, Volker A. Brandt wrote: > > I will try to set locale so it will report: > > > > LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= > > LC_MESSAGES= LC_ALL= > > Forget locale. Just set the variables in your bash session. > > > Regards -- Volker > -- > ------------------------------------------------------------------------ > Volker A. Brandt Consulting and Support for Oracle Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ > Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 > Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > > "When logic and proportion have fallen sloppy dead" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at multitalents.net Thu Apr 16 17:45:26 2015 From: tim at multitalents.net (Tim Rice) Date: Thu, 16 Apr 2015 10:45:26 -0700 (PDT) Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Davide, On Thu, 16 Apr 2015, Davide Poletto wrote: > Once vi is launched I'm used to enable the INSERT mode with ESC + a and > then start editing (this happens in Linux), in this case if I press ESC + a The way this is written leads me to think you are pressing ESC and a at the same time. Keep in mind ESC is not a modifier key like Shift, Ctrl, or Alt. In vi, ESC exits edit mode and gets back to command mode. > vi doesn't enter into INSERT mode at all and consequent keys that are > pressed are wihtout any sense for me...as example if I press the Up Key to > move up vi prints the letter "B", what is interesting is that if I press > ESC once again it switches into another mode...and pressing the "dd" will > delete the line on which the cursor is (dd delete) so there something weird > about vi and my configuration (which is the default as per OmniOS fresh > install) <- This behaviour was the same with every single OmniOS install I > did in the past (same Timezone, same Keyboard layout). Yes, in command mode, dd should delete the line at the cursor. Pressing the arrow keys will only do what you expect in command mode. If you've pressed an a, (append after cursor) you are now in edit mode where you can start typing your text. Press ESC to get back to command mode. Now on a OmniOS (and every other *NIX I know) console the arrow keys send an ESC as the first character of their sequence so you end up in command mode. > > Davide. -- Tim Rice Multitalents tim at multitalents.net From richard at netbsd.org Thu Apr 16 19:52:55 2015 From: richard at netbsd.org (Richard PALO) Date: Thu, 16 Apr 2015 21:52:55 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> Message-ID: <55301317.6090208@netbsd.org> Le 16/04/15 12:13, Davide Poletto a ?crit : > Hi Volker, > > Yes, physical USB Italian keyboard directly connected to my little HP > MicroServer G7 (or G8, no matter). > > I'm using the default OmniOS Shell...after login: > > echo $SHELL > /usr/bin/bash > > echo $TERM > sun-color > > They're default, never touched (as the /root/.profile file too). > > I'm starting to have few suspects there is something wrong with these > "default" settings...Isn't it Volker? > > Davide. > Also, out of curiosity, what does the following show for you? > richard at omnis:/home/richard$ svcprop -p keymap/layout keymap:default > French -- Richard PALO From davide.poletto at gmail.com Thu Apr 16 20:07:07 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 22:07:07 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Hi Tim, On Apr 16, 2015 7:45 PM, "Tim Rice" wrote: > > > Davide, > > The way this is written leads me to think you are pressing ESC and a at the same time. Yes, exactly as I do once in vi to enter into its INSERT mode on every Linux I've put my hands on. > Yes, in command mode, dd should delete the line at the cursor. Yeah, I know that dd when vi editor is into its COMMAND mode deletes the line at which the cursor is...no news here. Are you meaning that I should use use keys combinations in a different ways (e.g. the "ESC" with "a" combination in the way you explained above) I'm used in Linux for years to let vi editor in OmniOS behaving the same way it behaves in Linux? Thanks, Davide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at multitalents.net Thu Apr 16 20:40:04 2015 From: tim at multitalents.net (Tim Rice) Date: Thu, 16 Apr 2015 13:40:04 -0700 (PDT) Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Hi Davide, On Thu, 16 Apr 2015, Davide Poletto wrote: | Hi Tim, | | On Apr 16, 2015 7:45 PM, "Tim Rice" wrote: | > | > | > Davide, | > | > The way this is written leads me to think you are pressing ESC and a at | the same time. | | Yes, exactly as I do once in vi to enter into its INSERT mode on every | Linux I've put my hands on. | | > Yes, in command mode, dd should delete the line at the cursor. | | Yeah, I know that dd when vi editor is into its COMMAND mode deletes the | line at which the cursor is...no news here. | | Are you meaning that I should use use keys combinations in a different ways | (e.g. the "ESC" with "a" combination in the way you explained above) I'm | used in Linux for years to let vi editor in OmniOS behaving the same way it | behaves in Linux? Remember ESC is not a modifer. So if you attempt to press ESC and a at the same time, you don't know which one the system will get first. The only reason the press the ESC key is to get back to command mode. Once in command mode an a will enter input mode appending after the cursor. There are other ways to begin input mode. A to append to end of line. i to insert before cursor. I to insert before 1st non whitespace on line. o to open a new line below cursor. O to open a new line above cursor. And others. | Thanks, Davide. | -- Tim Rice Multitalents (707) 456-1146 tim at multitalents.net From davide.poletto at gmail.com Thu Apr 16 20:52:52 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 22:52:52 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <552FF9B2.8090409@netbsd.org> References: <21807.35061.144097.898163@glaurung.bb-c.de> <552FF9B2.8090409@netbsd.org> Message-ID: Hi Richard, Here are my settings: OmniOS 5.11 omnios-a708424 April 2015 root at intra:/root# pkg list -a |grep locale|grep it locale/it 0.5.11-0.151014 i-- locale/it-extra 0.5.11-0.151014 i-- root at intra:/root# stty -a speed 38400 baud; rows 54; columns 190; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = ; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; status = ^T; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke root at intra:/root# kbd -lt USB keyboard type=6 layout=14 (0x0e) delay(ms)=500 rate(ms)=40 root at intra:/root# locale LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= root at intra:/root# cat /etc/default/init TZ="Europe/Rome" CMASK=022 The fact is that the abnormal behaviour I see (and I always seen) with vi editor happens both with the local USB Italian Keyboard (It's a Fujitsu Siemens Keyboard of 2006 that works perfectly with any Linux I used and I use) AND when I log in through SSH...so It appears not related to the physical keyboard but to a system setting. Thanks for you help! really much appreciated. Davide. On Thu, Apr 16, 2015 at 8:04 PM, Richard PALO wrote: > Le 16/04/15 13:07, Davide Poletto a ?crit : >> Hi Richard, >> >> echo $TERMINFO reports only a blank line on my system. >> >> Davide. >> > > Then you're probably on default. > I must admit I'm still on 151013... > > A few things to probably indicate... what is your actual keyboard? > > I will dig out my logitech usb keyboard to try, it does seem usb has issues. > using ps/2 right now and it's fine. > > Do you have all the locale files installed? (pkg list -a |grep locale|grep it) > for me I have: >> richard at omnis:/home/richard$ pkg list -a |grep locale|grep fr >> locale/fr 0.5.11-0.151013 i-- >> locale/fr-extra 0.5.11-0.151013 i-- > my locale is: >> LANG=fr_FR.UTF-8 >> LC_CTYPE="fr_FR.UTF-8" >> LC_NUMERIC="fr_FR.UTF-8" >> LC_TIME="fr_FR.UTF-8" >> LC_COLLATE="fr_FR.UTF-8" >> LC_MONETARY="fr_FR.UTF-8" >> LC_MESSAGES="fr_FR.UTF-8" >> LC_ALL= > > you may also wish to post your 'stty -a' output. > I have: >> speed 9600 baud; >> rows = 25; columns = 80; ypixels = 0; xpixels = 0; >> csdata ? >> eucw 1:0:0:0, scrw 1:0:0:0 >> intr = ^c; quit = ^\; erase = ^?; kill = ^u; >> eof = ^d; eol = ; eol2 = ; swtch = ; >> start = ^q; stop = ^s; susp = ^z; dsusp = ^y; >> rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v; >> status = ^t; >> -parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff -parext >> -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc >> ixon -ixany -ixoff imaxbel >> isig icanon -xcase echo echoe echok -echonl -noflsh >> -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten >> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3 > > I find deceiving to see that even though I use a ps/2 kbd, the following is my 'kbd -lt' >> USB keyboard >> type=6 >> layout=8 (0x08) >> delay(ms)=500 >> rate(ms)=40 > > there's certainly a reason though with the keyboard itself. I'll let you know when I get > my usb kbd located... > -- > Richard PALO > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Apr 16 21:02:25 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 16 Apr 2015 14:02:25 -0700 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: Message-ID: <1d7f01d07888$a5e4b920$f1ae2b60$@acm.org> > From: Davide Poletto > Sent: Thursday, April 16, 2015 2:52 AM > > every OmniOS versions I tested so far: I never been able to use vi editor in > OmniOS as I do (entering editing mode, writing characters, deleting ones, etc.) in > Linux because it seems it doesn't recognize any expected key combinations. One thing to note is that under OmniOS, vim defaults to compatible mode, as opposed to linux, where it generally does not. When running in compatible mode, a lot of the nifty vim features and abilities you are used to don't work 8-/. To disable compatible mode, all you need to do is create a ~/.vimrc (even if empty) or turn it off explicitly in the global configuration file (see ":help compatible" for details). > those commands like ESC+a to insert or ESC+Shift+: to go to vi's prompt for > saving, quitting, etc.)? I don't believe I've ever seen "ESC+a" listed as a specific vi command. ESC, if you are in edit mode, returns you to command mode. If you are in command mode, it is a noop AFAIK. 'a' is actually "append", not "insert", which is 'i'. ':' if you are in command mode pops up the prompt, you only need to hit ESC first if you are in edit mode and need to switch to command mode, although if you are already in command mode it doesn't hurt to hit again. From davide.poletto at gmail.com Thu Apr 16 21:03:13 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 23:03:13 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: Hi Tim, There isn't any difference when I press "Esc" then "a" (so no "Esc" and "a" at the same time...that's not possible to grant that happens): vi behaviour is abnormal because It doesn't show you that it entered into INSERT mode even if it looks like it has (both directly via locally connected USB Keyboard with Italian layout and also via SSH from a Linux machine that has another USB Keyboard with Italian layout). I can't make a video...but if you would see it you would understand it's like to guess what key to press to obtain a particular action you yet know (because you did that hundreds times with vi in Linux). As example: If I press "Esc" then "a" it seem into the INSERT mode but vi doesn't show that...then with "Canc" (and not "Esc" only to go back as you wrote) it goes out from this mode and enters into what looks like the COMMAND mode because if then I press "dd" vi deletes the line which the cursor is). At this point I don't know if I have a problem (never seen when I edit files with vi in Linux) or if there is really something strange happening with my settings. Davide. On Thu, Apr 16, 2015 at 10:40 PM, Tim Rice wrote: > > Hi Davide, > > On Thu, 16 Apr 2015, Davide Poletto wrote: > > | Hi Tim, > | > | On Apr 16, 2015 7:45 PM, "Tim Rice" wrote: > | > > | > > | > Davide, > | > > | > The way this is written leads me to think you are pressing ESC and a at > | the same time. > | > | Yes, exactly as I do once in vi to enter into its INSERT mode on every > | Linux I've put my hands on. > | > | > Yes, in command mode, dd should delete the line at the cursor. > | > | Yeah, I know that dd when vi editor is into its COMMAND mode deletes the > | line at which the cursor is...no news here. > | > | Are you meaning that I should use use keys combinations in a different > ways > | (e.g. the "ESC" with "a" combination in the way you explained above) I'm > | used in Linux for years to let vi editor in OmniOS behaving the same way > it > | behaves in Linux? > > Remember ESC is not a modifer. So if you attempt to press ESC and a at > the same time, you don't know which one the system will get first. > > The only reason the press the ESC key is to get back to command mode. > Once in command mode an a will enter input mode appending after the cursor. > There are other ways to begin input mode. > A to append to end of line. > i to insert before cursor. > I to insert before 1st non whitespace on line. > o to open a new line below cursor. > O to open a new line above cursor. > And others. > > | Thanks, Davide. > | > > -- > Tim Rice Multitalents (707) 456-1146 > tim at multitalents.net > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Apr 16 21:04:55 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 16 Apr 2015 14:04:55 -0700 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: <1d8f01d07888$ff0b4b40$fd21e1c0$@acm.org> > From: Tim Rice > Sent: Thursday, April 16, 2015 10:45 AM > > Pressing the arrow keys will only do what you expect in command mode. Unless you disable compatibility mode, in which case you can happily navigate with the arrow keys while in edit mode, presumably just as you are used to doing under linux. > Now on a OmniOS (and every other *NIX I know) console the arrow keys send > an ESC as the first character of their sequence so you end up in command mode. I don't know the internal details, but I assume vim interprets "ESC+arrow key stuff" as a movement command even in edit mode rather than reverting to command mode and doing random stuff based on the keys following the ESC... From davide.poletto at gmail.com Thu Apr 16 21:08:04 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 16 Apr 2015 23:08:04 +0200 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <1d7f01d07888$a5e4b920$f1ae2b60$@acm.org> References: <1d7f01d07888$a5e4b920$f1ae2b60$@acm.org> Message-ID: Hi Paul ~/.vimrc does the trick! Now It behaves like in Linux and "Esc" then "a" starts the INSERT mode (at vi's bottom appears the "-- INSERT --") and I can move with arrows keys and use Del/Canc as I'm used to. Thanks! On Thu, Apr 16, 2015 at 11:02 PM, Paul B. Henson wrote: > > From: Davide Poletto > > Sent: Thursday, April 16, 2015 2:52 AM > > > > every OmniOS versions I tested so far: I never been able to use vi > editor in > > OmniOS as I do (entering editing mode, writing characters, deleting > ones, etc.) in > > Linux because it seems it doesn't recognize any expected key > combinations. > > One thing to note is that under OmniOS, vim defaults to compatible mode, > as opposed to linux, where it generally does not. When running in > compatible mode, a lot of the nifty vim features and abilities you are used > to don't work 8-/. To disable compatible mode, all you need to do is create > a ~/.vimrc (even if empty) or turn it off explicitly in the global > configuration file (see ":help compatible" for details). > > > those commands like ESC+a to insert or ESC+Shift+: to go to vi's prompt > for > > saving, quitting, etc.)? > > I don't believe I've ever seen "ESC+a" listed as a specific vi command. > ESC, if you are in edit mode, returns you to command mode. If you are in > command mode, it is a noop AFAIK. 'a' is actually "append", not "insert", > which is 'i'. ':' if you are in command mode pops up the prompt, you only > need to hit ESC first if you are in edit mode and need to switch to command > mode, although if you are already in command mode it doesn't hurt to hit > again. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Apr 16 21:08:23 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 16 Apr 2015 14:08:23 -0700 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> Message-ID: <1d9201d07889$7b6650e0$7232f2a0$@acm.org> > From: Davide Poletto > Sent: Thursday, April 16, 2015 1:07 PM > > > The way this is written leads me to think you are pressing ESC and a at the > > same time. > > Yes, exactly as I do once in vi to enter into its INSERT mode on every Linux I've > put my hands on. As has been mentioned, ESC is a separate character, not a modifier key, and as such for the purposes of providing input to vim it is not possible to press them "simultaneously". vim gets either an ESC than an a, or an a then an ESC. You only need the ESC if you are in edit mode. But if you're already in edit mode, what's the point of ESC'ing to command mode then immediately we enter in edit mode :)? > Are you meaning that I should use use keys combinations in a different ways > (e.g. the "ESC" with "a" combination in the way you explained above) I'm used in > Linux for years to let vi editor in OmniOS behaving the same way it behaves in > Linux? If you disable compatibility mode so vim acts like vim rather than vi you should have pretty much the identical experience as under linux. Dan, any thoughts on disabling compatibility mode by default :)? Or would that be to un-Solaris like ;)? Thanks? From henson at acm.org Thu Apr 16 21:15:38 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 16 Apr 2015 14:15:38 -0700 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: References: <1d7f01d07888$a5e4b920$f1ae2b60$@acm.org> Message-ID: <1db201d0788a$7e81cc40$7b8564c0$@acm.org> > From: Davide Poletto > Sent: Thursday, April 16, 2015 2:08 PM > > Now It behaves like in Linux and "Esc" then "a" starts the INSERT mode Yeah, once you get used to vim trying to use plain jane vi can be excruciatingly painful :). If you want it to behave exactly like your favorite linux distribution, you can copy over the linux vim global configuration file (typically /etc/vimrc or something like that) to your omnios box (where it looks like it wants it to be in /usr/share/vim/vimrc). From danmcd at omniti.com Thu Apr 16 22:17:34 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 16 Apr 2015 18:17:34 -0400 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <1d9201d07889$7b6650e0$7232f2a0$@acm.org> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> <1d9201d07889$7b6650e0$7232f2a0$@acm.org> Message-ID: <24ECD67B-6A9E-466C-8F52-A75642D1F81B@omniti.com> Some have suggested that we include old UCB vi by default. ;) We'll likely keep compatibility mode by default for the foreseeable future. Dan Sent from my iPhone (typos, autocorrect, and all) On Apr 16, 2015, at 5:08 PM, Paul B. Henson wrote: >> From: Davide Poletto >> Sent: Thursday, April 16, 2015 1:07 PM >> >>> The way this is written leads me to think you are pressing ESC and a at the >>> same time. >> >> Yes, exactly as I do once in vi to enter into its INSERT mode on every Linux I've >> put my hands on. > > As has been mentioned, ESC is a separate character, not a modifier key, and as such for the purposes of providing input to vim it is not possible to press them "simultaneously". vim gets either an ESC than an a, or an a then an ESC. You only need the ESC if you are in edit mode. But if you're already in edit mode, what's the point of ESC'ing to command mode then immediately we enter in edit mode :)? > >> Are you meaning that I should use use keys combinations in a different ways >> (e.g. the "ESC" with "a" combination in the way you explained above) I'm used in >> Linux for years to let vi editor in OmniOS behaving the same way it behaves in >> Linux? > > If you disable compatibility mode so vim acts like vim rather than vi you should have pretty much the identical experience as under linux. > > Dan, any thoughts on disabling compatibility mode by default :)? Or would that be to un-Solaris like ;)? > > Thanks? > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From jesus at omniti.com Thu Apr 16 22:28:08 2015 From: jesus at omniti.com (Theo Schlossnagle) Date: Thu, 16 Apr 2015 18:28:08 -0400 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <24ECD67B-6A9E-466C-8F52-A75642D1F81B@omniti.com> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> <1d9201d07889$7b6650e0$7232f2a0$@acm.org> <24ECD67B-6A9E-466C-8F52-A75642D1F81B@omniti.com> Message-ID: And... we always have ed for when terminals go bad. Then you get used to it and to most surgical editing via ed. On Thu, Apr 16, 2015 at 6:17 PM, Dan McDonald wrote: > Some have suggested that we include old UCB vi by default. ;) > > We'll likely keep compatibility mode by default for the foreseeable future. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Apr 16, 2015, at 5:08 PM, Paul B. Henson wrote: > > >> From: Davide Poletto > >> Sent: Thursday, April 16, 2015 1:07 PM > >> > >>> The way this is written leads me to think you are pressing ESC and a > at the > >>> same time. > >> > >> Yes, exactly as I do once in vi to enter into its INSERT mode on every > Linux I've > >> put my hands on. > > > > As has been mentioned, ESC is a separate character, not a modifier key, > and as such for the purposes of providing input to vim it is not possible > to press them "simultaneously". vim gets either an ESC than an a, or an a > then an ESC. You only need the ESC if you are in edit mode. But if you're > already in edit mode, what's the point of ESC'ing to command mode then > immediately we enter in edit mode :)? > > > >> Are you meaning that I should use use keys combinations in a different > ways > >> (e.g. the "ESC" with "a" combination in the way you explained above) > I'm used in > >> Linux for years to let vi editor in OmniOS behaving the same way it > behaves in > >> Linux? > > > > If you disable compatibility mode so vim acts like vim rather than vi > you should have pretty much the identical experience as under linux. > > > > Dan, any thoughts on disabling compatibility mode by default :)? Or > would that be to un-Solaris like ;)? > > > > Thanks? > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at 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: From henson at acm.org Thu Apr 16 22:42:00 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 16 Apr 2015 15:42:00 -0700 Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <24ECD67B-6A9E-466C-8F52-A75642D1F81B@omniti.com> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> <1d9201d07889$7b6650e0$7232f2a0$@acm.org> <24ECD67B-6A9E-466C-8F52-A75642D1F81B@omniti.com> Message-ID: <1dc901d07896$8f7150a0$ae53f1e0$@acm.org> > From: Dan McDonald > Sent: Thursday, April 16, 2015 3:18 PM > > Some have suggested that we include old UCB vi by default. ;) I see Theo already beat me to the punch of pointing out ed ;), hard-core old-school users can use that if vim is too darn newfangled modern for them :). > We'll likely keep compatibility mode by default for the foreseeable future. Might be worth a page on the wiki? Tentatively titled "Why does vi suck?" :)... From tim at multitalents.net Thu Apr 16 23:25:58 2015 From: tim at multitalents.net (Tim Rice) Date: Thu, 16 Apr 2015 16:25:58 -0700 (PDT) Subject: [OmniOS-discuss] OmniOS 151014: questions about locale settings and vi editing command's issues. In-Reply-To: <1d8f01d07888$ff0b4b40$fd21e1c0$@acm.org> References: <21807.35061.144097.898163@glaurung.bb-c.de> <21807.38300.73907.267470@glaurung.bb-c.de> <21807.39568.46208.745940@glaurung.bb-c.de> <1d8f01d07888$ff0b4b40$fd21e1c0$@acm.org> Message-ID: On Thu, 16 Apr 2015, Paul B. Henson wrote: | > From: Tim Rice | > Sent: Thursday, April 16, 2015 10:45 AM | > | > Pressing the arrow keys will only do what you expect in command mode. | | Unless you disable compatibility mode, in which case you can happily | navigate with the arrow keys while in edit mode, presumably just as you are | used to doing under linux. Well then that would not be vi, would it? ;-) I solved my vim on Limux anoyances years ago wit a few lins in my .vimrc ...... set undolevels=0 set whichwrap="" set fileformats=unix set noautoindent set noruler set noshowcmd ...... Works much better. :-) -- Tim Rice Multitalents tim at multitalents.net From rt at steait.net Sat Apr 18 09:23:29 2015 From: rt at steait.net (Rune Tipsmark) Date: Sat, 18 Apr 2015 09:23:29 +0000 Subject: [OmniOS-discuss] crash dump analysis help Message-ID: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net> hi guys, my omnios zfs server crashed today and I got a complete core dump and I was wondering if I am on the right track... here is what I did so far... root at zfs10:/root# fmdump -Vp -u 775e0fc1-dcd2-4cb2-b800-88a1b9910f94 TIME UUID SUNW-MSG-ID Apr 17 2015 22:48:13.667749000 775e0fc1-dcd2-4cb2-b800-88a1b9910f94 SUNOS-8000-KL TIME CLASS ENA Apr 17 22:48:13.6544 ireport.os.sunos.panic.dump_available 0x0000000000000000 Apr 17 22:45:46.3335 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000 nvlist version: 0 version = 0x0 class = list.suspect uuid = 775e0fc1-dcd2-4cb2-b800-88a1b9910f94 code = SUNOS-8000-KL diag-time = 1429303693 655062 de = fmd:///module/software-diagnosis fault-list-sz = 0x1 fault-list = (array of embedded nvlists) (start fault-list[0]) nvlist version: 0 version = 0x0 class = defect.sunos.kernel.panic certainty = 0x64 asru = sw:///:path=/var/crash/unknown/.775e0fc1-dcd2-4cb2-b800-88a1b9910f94 resource = sw:///:path=/var/crash/unknown/.775e0fc1-dcd2-4cb2-b800-88a1b9910f94 savecore-succcess = 1 dump-dir = /var/crash/unknown dump-files = vmdump.1 os-instance-uuid = 775e0fc1-dcd2-4cb2-b800-88a1b9910f94 panicstr = BAD TRAP: type=e (#pf Page fault) rp=ffffff01701bb960 addr=ec6093a0 occurred in module "unix" due to an illegal access to a user address panicstack = unix:die+df () | unix:trap+db3 () | unix:cmntrap+e6 () | unix:bzero+184 () | zfs:l2arc_write_buffers+1f8 () | zfs:l2arc_feed_thread+240 () | unix:thread_start+8 () | crashtime = 1429299093 panic-time = Fri Apr 17 21:31:33 2015 CEST (end fault-list[0]) fault-status = 0x1 severity = Major __ttl = 0x1 __tod = 0x5531718d 0x27cd0a88 //then extract the dump file: savecore: not enough space in /var/crash/unknown (14937 MB avail, 27154 MB needed) root at zfs10:/var/crash/unknown# savecore -f /pool01/ISO/vmdump.1 /pool01/ISO/ savecore: System dump time: Fri Apr 17 21:31:33 2015 savecore: saving system crash dump in /pool01/ISO//{unix,vmcore}.1 Constructing namelist /pool01/ISO//unix.1 Constructing corefile /pool01/ISO//vmcore.1 3:33 100% done: 6897249 of 6897249 pages saved // then mdb and $c to see last process before the crash... root at zfs10:/pool01/ISO# mdb unix.1 vmcore.1 Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs sata sd ip hook neti sockfs arp usba stmf stmf_sbd fctl md lofs mpt_sas random ufs idm smbsrv nfs crypto ptm cpc kvm fcp fcip logindmux nsmb nsctl sdbc ii sv rdc ] > $c bzero+0x184() l2arc_write_buffers+0x1f8(ffffff328f860000, ffffff331782d8d8, 800000, ffffff01701bbbec) l2arc_feed_thread+0x240() thread_start+8() // based on this I believe my m2 sata L2 cache Samsung ssd drives used for L2arc in the zpool are ready to be thrown into the bin .... Is there some way I can gather more info and confirm I am on the right track? br, Rune -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at netbsd.org Sat Apr 18 10:37:36 2015 From: richard at netbsd.org (Richard PALO) Date: Sat, 18 Apr 2015 12:37:36 +0200 Subject: [OmniOS-discuss] updating to 151015 with local gate In-Reply-To: References: Message-ID: <553233F0.70400@netbsd.org> Le 12/04/15 23:19, Dan McDonald a ?crit : > >> On Apr 12, 2015, at 2:12 AM, Richard PALO wrote: >> >> Seems omnios bloody is being insidiously 'racist' :) about incorporations... >> >> Is there a workaround? >> Setting omnios sticky and on-nightly non-sticky doesn't seem to solve anything. > > You need to match ONNV_BUILDNUM in illumos-omnios's .env file with whatever you wish to ONU: > > # SET ONNV_BUILDNUM to override the current "151015" of OmniOS. > ONNV_BUILDNUM=151015 > > Make sure those are in your env file if you wish to ONU r151015. > > Dan > Yeah, this worked... if the on-nightly gate bits are already @151015 then upgrading is hunky dory, though without passing via generic bloody first.. (which in this case is okay). restoring entire is probably the only means to do that. thanks for the kick in the head;-) -- Richard PALO From richard at netbsd.org Sat Apr 18 10:56:02 2015 From: richard at netbsd.org (Richard PALO) Date: Sat, 18 Apr 2015 12:56:02 +0200 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found Message-ID: > richard at omnis:/home/richard$ pfexec pkg install -v system/dtrace/tests > Creating Plan (Solver setup): / > pkg install: No matching version of system/dtrace/tests can be installed: > Reject: pkg://on-nightly/system/dtrace/tests at 0.5.11,5.11-0.151015:20150418T072853Z > Reason: A version for 'require' dependency on pkg:/runtime/java/runtime64 cannot be found something missing in omnios? > richard at omnis:/home/richard/src/illumos-gate/usr/src/pkg$ grep runtime manifests/system-dtrace-tests.mf > depend fmri=runtime/java type=require > depend fmri=runtime/java/runtime64 type=require -- Richard PALO From richard at netbsd.org Sat Apr 18 12:02:05 2015 From: richard at netbsd.org (Richard PALO) Date: Sat, 18 Apr 2015 14:02:05 +0200 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: References: Message-ID: <553247BD.8080300@netbsd.org> Le 18/04/15 12:56, Richard PALO a ?crit : >> richard at omnis:/home/richard$ pfexec pkg install -v system/dtrace/tests >> Creating Plan (Solver setup): / >> pkg install: No matching version of system/dtrace/tests can be installed: >> Reject: pkg://on-nightly/system/dtrace/tests at 0.5.11,5.11-0.151015:20150418T072853Z >> Reason: A version for 'require' dependency on pkg:/runtime/java/runtime64 cannot be found > > something missing in omnios? >> richard at omnis:/home/richard/src/illumos-gate/usr/src/pkg$ grep runtime manifests/system-dtrace-tests.mf >> depend fmri=runtime/java type=require >> depend fmri=runtime/java/runtime64 type=require > Perhaps with jdk7 there is no additional runtime64. I simply deleted the line: > diff --git a/usr/src/pkg/manifests/system-dtrace-tests.mf b/usr/src/pkg/manifests/system-dtrace-tests.mf > index 0974627..5e744b5 100644 > --- a/usr/src/pkg/manifests/system-dtrace-tests.mf > +++ b/usr/src/pkg/manifests/system-dtrace-tests.mf > @@ -2116,4 +2116,3 @@ legacy pkg=SUNWdtrt category=internal \ > license cr_Sun license=cr_Sun > license lic_CDDL license=lic_CDDL > depend fmri=runtime/java type=require > -depend fmri=runtime/java/runtime64 type=require repackaged from pkg with dmake install whereupon I can now install just fine, and after adding /opt/gcc-4.8.1/bin to my path and am running the dtrace tests now. -- Richard PALO From jesus at omniti.com Sat Apr 18 12:14:27 2015 From: jesus at omniti.com (Theo Schlossnagle) Date: Sat, 18 Apr 2015 05:14:27 -0700 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: <553247BD.8080300@netbsd.org> References: <553247BD.8080300@netbsd.org> Message-ID: We should probably publish an empty runtime/java/runtime64 that requires runtime/java. On Apr 18, 2015 5:07 AM, "Richard PALO" wrote: > Le 18/04/15 12:56, Richard PALO a ?crit : > >> richard at omnis:/home/richard$ pfexec pkg install -v system/dtrace/tests > >> Creating Plan (Solver setup): / > >> pkg install: No matching version of system/dtrace/tests can be > installed: > >> Reject: pkg://on-nightly/system/dtrace/tests at 0.5.11 > ,5.11-0.151015:20150418T072853Z > >> Reason: A version for 'require' dependency on > pkg:/runtime/java/runtime64 cannot be found > > > > something missing in omnios? > >> richard at omnis:/home/richard/src/illumos-gate/usr/src/pkg$ grep runtime > manifests/system-dtrace-tests.mf > >> depend fmri=runtime/java type=require > >> depend fmri=runtime/java/runtime64 type=require > > > > Perhaps with jdk7 there is no additional runtime64. > > I simply deleted the line: > > diff --git a/usr/src/pkg/manifests/system-dtrace-tests.mf > b/usr/src/pkg/manifests/system-dtrace-tests.mf > > index 0974627..5e744b5 100644 > > --- a/usr/src/pkg/manifests/system-dtrace-tests.mf > > +++ b/usr/src/pkg/manifests/system-dtrace-tests.mf > > @@ -2116,4 +2116,3 @@ legacy pkg=SUNWdtrt category=internal \ > > license cr_Sun license=cr_Sun > > license lic_CDDL license=lic_CDDL > > depend fmri=runtime/java type=require > > -depend fmri=runtime/java/runtime64 type=require > > repackaged from pkg with dmake install > whereupon I can now install just fine, and after adding /opt/gcc-4.8.1/bin > to my path > and am running the dtrace tests now. > > > -- > Richard PALO > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at netbsd.org Sat Apr 18 15:17:15 2015 From: richard at netbsd.org (Richard PALO) Date: Sat, 18 Apr 2015 17:17:15 +0200 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: References: <553247BD.8080300@netbsd.org> Message-ID: <5532757B.4000107@netbsd.org> Le 18/04/15 14:14, Theo Schlossnagle a ?crit : > We should probably publish an empty runtime/java/runtime64 that requires > runtime/java. Alternately provide something like OI/Hipster does https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openjdk-7/openjdk7-runtime64.p5m -- Richard PALO From dwq at xmweixun.com Sun Apr 19 08:24:05 2015 From: dwq at xmweixun.com (=?gb2312?B?tcvOsMio?=) Date: Sun, 19 Apr 2015 16:24:05 +0800 Subject: [OmniOS-discuss] [Omnios-discuss] Zvol rewrite slow? Message-ID: <00c401d07a7a$33f35c10$9bda1430$@xmweixun.com> Hello all, I used OmniOS 151006 Or 151014 found Zvol rewrite from 212MB to 44.4MB.Details are as follows. zpool crerate WX raidz c8t5000C5003AEADC65d0 c8t5000C5003AE7BAD9d0 c8t5000C5003AC4E3CDd0 zfs create -V 20g WX/test01 stmfadm create-lu -p wcd=false /dev/zvol/rdsk/WX/test01 stmfadm add-view #add view to client host client:redhat 5.8 X86 pvcreate /dev/sdb vgcreate /dev/vgtest /dev/sdb lvcreate ?CL xxx ?Cn lvtest /dev/vgtest mkfs /dev/vgtest/lvtest mkdir /test mount /dev/vgtest/lvtest /test [root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 dd: writing `/test/1': No space left on device 5023+0 records in 5022+0 records out 21066981376 bytes (21 GB) copied, 99.443 seconds, 212 MB/s [root at localhost test]# ls [root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 dd: writing `/test/1': No space left on device 5023+0 records in 5022+0 records out 21066981376 bytes (21 GB) copied, 474.468 seconds, 44.4 MB/s Thanks. Best Regards, Deng Wei Quan Mob: +86 13906055059 Mail: dwq at xmweixun.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Sun Apr 19 09:27:15 2015 From: jimklimov at cos.ru (Jim Klimov) Date: Sun, 19 Apr 2015 11:27:15 +0200 Subject: [OmniOS-discuss] [Omnios-discuss] Zvol rewrite slow? In-Reply-To: <00c401d07a7a$33f35c10$9bda1430$@xmweixun.com> References: <00c401d07a7a$33f35c10$9bda1430$@xmweixun.com> Message-ID: <80E58D87-12D1-431D-B167-8CCAF1B0FB36@cos.ru> 19 ?????? 2015??. 10:24:05 CEST, "???" ?????: >Hello all, > > I used OmniOS 151006 Or 151014 found Zvol rewrite from 212MB to >44.4MB.Details are as follows. > > > >zpool crerate WX raidz c8t5000C5003AEADC65d0 c8t5000C5003AE7BAD9d0 >c8t5000C5003AC4E3CDd0 > >zfs create -V 20g WX/test01 > >stmfadm create-lu -p wcd=false /dev/zvol/rdsk/WX/test01 > >stmfadm add-view #add view to client host > > > >client:redhat 5.8 X86 > >pvcreate /dev/sdb > >vgcreate /dev/vgtest /dev/sdb > >lvcreate ?L xxx ?n lvtest /dev/vgtest > >mkfs /dev/vgtest/lvtest > >mkdir /test > >mount /dev/vgtest/lvtest /test > >[root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 > >dd: writing `/test/1': No space left on device > >5023+0 records in > >5022+0 records out > >21066981376 bytes (21 GB) copied, 99.443 seconds, 212 MB/s > >[root at localhost test]# ls > > > >[root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 > >dd: writing `/test/1': No space left on device > >5023+0 records in > >5022+0 records out > >21066981376 bytes (21 GB) copied, 474.468 seconds, 44.4 MB/s > > > >Thanks. > > > >Best Regards, >Deng Wei Quan > >Mob: +86 13906055059 > >Mail: dwq at xmweixun.com > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss OTOH, it may be because blocks to be freed are first put on a death list, and then released asynchronously as the zfs pool processes its structures. This was found to be a preferable and reliable way to do it, instead of a sync operation which may require more resources than a particular system has. So as you rewrite your data, writes may be waiting for some free space imminent to appear (in the sync approach, you might have a longer wait for all the space to become free at once), and maybe some space is served from the pool's internal reserves (1/64th of size). I think this is configurable as a per-zpool @feature. Also, searching for available 'holes' in the allocation, where zfs might put your new writes, this itself is slower on a full pool than on a new empty one. Search for 'zfs free space fragmentation' to get some history on this subject and solutions, and in particular be aware that there is (or at least was recently) a write-performance collapse when the pool got too full (numbers vary per installation and usage patterns, from 50% to 90+% full, for lags to become noticeable; rule of thumb is to use up to 80% of the pool and try not to exceed that - e.g. pre-reserve a 20% sparse volume or another dataset with a reservation). HTH, Jim -- Typos courtesy of K-9 Mail on my Samsung Android From dwq at xmweixun.com Sun Apr 19 11:27:43 2015 From: dwq at xmweixun.com (dwq at xmweixun.com) Date: Sun, 19 Apr 2015 19:27:43 +0800 Subject: [OmniOS-discuss] =?utf-8?b?562U5aSNOiAgW09tbmlvcy1kaXNjdXNzXSBa?= =?utf-8?q?vol_rewrite_slow=3F?= In-Reply-To: <80E58D87-12D1-431D-B167-8CCAF1B0FB36@cos.ru> References: <00c401d07a7a$33f35c10$9bda1430$@xmweixun.com> <80E58D87-12D1-431D-B167-8CCAF1B0FB36@cos.ru> Message-ID: <000401d07a93$eb4d0960$c1e71c20$@xmweixun.com> Hi Jim thanks for the advice. I may not clearly describ the issue. the issue is not relative to zpool directly rewrite and it is about the zvol raw block device map through fc target. when we rewrite on fc target client map with zvol raw block device,the write performance drop a lot of. Thanks. Deng -----????----- ???: dwq+auto_=dengweiquan=139.com at xmweixun.com [mailto:dwq+auto_=dengweiquan=139.com at xmweixun.com] ?? Jim Klimov ????: 2015?4?19? 17:27 ???: ???; omnios-discuss at lists.omniti.com ??: wetong at amoyun.com ??: Re: [OmniOS-discuss] [Omnios-discuss] Zvol rewrite slow? 19 ?????? 2015 ?. 10:24:05 CEST, "???" ?????: >Hello all, > > I used OmniOS 151006 Or 151014 found Zvol rewrite from 212MB to >44.4MB.Details are as follows. > > > >zpool crerate WX raidz c8t5000C5003AEADC65d0 c8t5000C5003AE7BAD9d0 >c8t5000C5003AC4E3CDd0 > >zfs create -V 20g WX/test01 > >stmfadm create-lu -p wcd=false /dev/zvol/rdsk/WX/test01 > >stmfadm add-view #add view to client host > > > >client:redhat 5.8 X86 > >pvcreate /dev/sdb > >vgcreate /dev/vgtest /dev/sdb > >lvcreate ?L xxx ?n lvtest /dev/vgtest > >mkfs /dev/vgtest/lvtest > >mkdir /test > >mount /dev/vgtest/lvtest /test > >[root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 > >dd: writing `/test/1': No space left on device > >5023+0 records in > >5022+0 records out > >21066981376 bytes (21 GB) copied, 99.443 seconds, 212 MB/s > >[root at localhost test]# ls > > > >[root at localhost test]# dd if=/dev/zero of=/test/1 bs=4096k count=100000 > >dd: writing `/test/1': No space left on device > >5023+0 records in > >5022+0 records out > >21066981376 bytes (21 GB) copied, 474.468 seconds, 44.4 MB/s > > > >Thanks. > > > >Best Regards, >Deng Wei Quan > >Mob: +86 13906055059 > >Mail: dwq at xmweixun.com > > > > > >----------------------------------------------------------------------- >- > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss OTOH, it may be because blocks to be freed are first put on a death list, and then released asynchronously as the zfs pool processes its structures. This was found to be a preferable and reliable way to do it, instead of a sync operation which may require more resources than a particular system has. So as you rewrite your data, writes may be waiting for some free space imminent to appear (in the sync approach, you might have a longer wait for all the space to become free at once), and maybe some space is served from the pool's internal reserves (1/64th of size). I think this is configurable as a per-zpool @feature. Also, searching for available 'holes' in the allocation, where zfs might put your new writes, this itself is slower on a full pool than on a new empty one. Search for 'zfs free space fragmentation' to get some history on this subject and solutions, and in particular be aware that there is (or at least was recently) a write-performance collapse when the pool got too full (numbers vary per installation and usage patterns, from 50% to 90+% full, for lags to become noticeable; rule of thumb is to use up to 80% of the pool and try not to exceed that - e.g. pre-reserve a 20% sparse volume or another dataset with a reservation). HTH, Jim -- Typos courtesy of K-9 Mail on my Samsung Android From danmcd at omniti.com Mon Apr 20 01:58:09 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 19 Apr 2015 21:58:09 -0400 Subject: [OmniOS-discuss] crash dump analysis help In-Reply-To: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net> References: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net> Message-ID: What version of OmniOS are you running (uname -a, or cat /etc/release)? Clearly a bad pointer was passed into bzero(). The pointer was 0xec6093a0, according to your panic screen. It COULD be bad HW, but it could also be something more sinister. Thanks, Dan From danmcd at omniti.com Mon Apr 20 01:58:55 2015 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 19 Apr 2015 21:58:55 -0400 Subject: [OmniOS-discuss] updating to 151015 with local gate In-Reply-To: <553233F0.70400@netbsd.org> References: <553233F0.70400@netbsd.org> Message-ID: <9DB45618-2F27-45FA-875D-0FE10F210B16@omniti.com> > On Apr 18, 2015, at 6:37 AM, Richard PALO wrote: > >> >> Make sure those are in your env file if you wish to ONU r151015. >> >> Dan >> > Yeah, this worked... if the on-nightly gate bits are already @151015 then upgrading is hunky dory, > though without passing via generic bloody first.. (which in this case is okay). > restoring entire is probably the only means to do that. > > thanks for the kick in the head;-) No problem. And if you want to ONU an 014 box, set things to 151014, etc. etc. Dan From rt at steait.net Mon Apr 20 11:02:44 2015 From: rt at steait.net (Rune Tipsmark) Date: Mon, 20 Apr 2015 11:02:44 +0000 Subject: [OmniOS-discuss] crash dump analysis help In-Reply-To: References: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net>, Message-ID: <1429527764554.96817@steait.net> root at zfs10:/root# uname -a SunOS zfs10 5.11 omnios-10b9c79 i86pc i386 i86pc Any idea how I can troubleshoot further? br, Rune ________________________________________ From: Dan McDonald Sent: Monday, April 20, 2015 3:58 AM To: Rune Tipsmark Cc: omnios-discuss; Dan McDonald Subject: Re: [OmniOS-discuss] crash dump analysis help What version of OmniOS are you running (uname -a, or cat /etc/release)? Clearly a bad pointer was passed into bzero(). The pointer was 0xec6093a0, according to your panic screen. It COULD be bad HW, but it could also be something more sinister. Thanks, Dan From danmcd at omniti.com Mon Apr 20 12:40:18 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Apr 2015 08:40:18 -0400 Subject: [OmniOS-discuss] crash dump analysis help In-Reply-To: <1429527764554.96817@steait.net> References: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net> <1429527764554.96817@steait.net> Message-ID: > On Apr 20, 2015, at 7:02 AM, Rune Tipsmark wrote: > > root at zfs10:/root# uname -a > SunOS zfs10 5.11 omnios-10b9c79 i86pc i386 i86pc That's r151012 (modulo today's update... read the list in a bit). > Any idea how I can troubleshoot further? Share the dump so people can see it. Dan From danmcd at omniti.com Mon Apr 20 12:43:50 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Apr 2015 08:43:50 -0400 Subject: [OmniOS-discuss] Please update - it's a reboot-your-box one Message-ID: If you have any of r151006, r151012, or r151014, please update your machines for a reboot-worthy update. A kernel bug was recently found and fixed that COULD cause privilege escalation. To be safe, I built the entirety of illumos-omnios and pushed those (after signing in 012 & 014) out to their respective repos. The 014 additional brought along a few extra ZFS fixes, and one more mr_sas fix, upstreamed not long after the 014 illumos merge window closed. I'm obtaining a CVE number, but don't have it yet. Dan From vab at bb-c.de Mon Apr 20 13:56:09 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 20 Apr 2015 15:56:09 +0200 Subject: [OmniOS-discuss] Please update - it's a reboot-your-box one In-Reply-To: References: Message-ID: <21813.1401.24333.794527@glaurung.bb-c.de> > If you have any of r151006, r151012, or r151014, please update your > machines for a reboot-worthy update. Done. Absolutely smooth, no problems whatsoever. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From pasztor at sagv5.gyakg.u-szeged.hu Sat Apr 18 19:09:32 2015 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Sat, 18 Apr 2015 21:09:32 +0200 Subject: [OmniOS-discuss] omnios zone experiences on openindiana Message-ID: <20150418190931.GA22924@linux.gyakg.u-szeged.hu> Hi, I do not remember, where I discussed about this topic earlier, but I just wanted to tell a success-story: I had a "playground" omnios-blody (151013) in a VirtualBox. I upgraded it to the current 151014 LTS. Then I created a zone into it to have a template. Then I migrated this zone to my home nas, which run OpenIndiana 151a9. Everything succeed, but I had some slap on my face to learn things:) So, I thought I share those experiences: At First time I forget to detach the zone. Docs says, you do not have to. But you suck much more if you don't so, detach the zone! ;-) Usual google findings about this topic is original sun/oracle docs, where zfs send has a -rc options. I used -R option. I did not have a sunsol11 playground in the near. And at the attach phase. You will suck! But, one thing which may help: http://everycity.co.uk/alasdair/2011/10/fixing-no-active-dataset-on-zone-attach/ That script helps you to setting zfs property after the migration. After running that script you can mount the ROOT/zbe by hand, as Alisdair writes, and the attach... almost work. I made a mistake, tried the attach with -u, which also exists on oracle/sun docs, but not on the illumos branch, so my openindiana added their own publishers to my zone. So, I attached again, but now with the -n option, which eliminates the checkings. Then I could boot the zone. I fixed the publishers. Then I could clone the zone, so now I can have omnios 151014 lts zones on my openindiana nas. (And I could eliminate also eliminate one virtualbox linux machine, since a native illumos based system is much-much efficient and using fstype=lofs instead of nfs, and an os-level virtualization instead of machine virtualization, etc.) Kind regards, Gy?rgy P?sztor From pasztor at sagv5.gyakg.u-szeged.hu Sun Apr 19 03:37:20 2015 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Sun, 19 Apr 2015 05:37:20 +0200 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? Message-ID: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> Hi, I faced with that, the login onto my new omnios zone is slow. I tried to debug. Many of the symptoms seemed pretty the same as this: http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ Also in my case it stopped at the same point: after the kexinit sent. However, on my omnios, the cryptadm list showed this: pasztor at omni:~$ cryptoadm list User-level providers: Provider: /usr/lib/security/$ISA/pkcs11_kernel.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so Kernel software providers: des aes arcfour blowfish ecc sha1 sha2 md4 md5 rsa swrand Kernel hardware providers: [---end of output----] So, in my case it did not contained the tpm module. I tried the opposite: enabling the tpm module, but nothing changed. (Maybe it become even slower. I did not count the seconds) So, I rewert it back, and run the same truss command, which revealed this: There are tons's of file openings in the /usr/lib/locale dir at that point: 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0 24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA", O_RDONLY) = 7 24560: 8.8236 fstat(7, 0x08047658) = 0 24560: 8.8237 mmap(0x00000000, 94904, PROT_READ, MAP_PRIVATE, 7, 0) = 0xFEDE7000 24560: 8.8238 close(7) = 0 ... 24560: 14.5883 open("/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA", O_RDONLY) = 7 24560: 14.5884 fstat(7, 0x08047678) = 0 24560: 14.6061 read(7, " ^ ( ( [EDCD ] ( [E1C1 ]".., 82) = 82 24560: 14.6063 close(7) = 0 24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0 24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE) Err#22 EINVAL 24560: 14.6069 fstat64(1, 0x08046E00) = 0 24560: 14.6070 brk(0x080689D0) = 0 24560: 14.6071 brk(0x0806A9D0) = 0 24560: 14.6072 fstat64(1, 0x08046D00) = 0 24560: 14.6074 close(5) = 0 24560: 14.6075 write(1, " C\n P O S I X\n a f _ Z".., 2891) = 2891 24556: 14.6076 read(3, " C\n P O S I X\n a f _ Z".., 5120) = 2891 24560: 14.6077 _exit(0) 24556: 14.6080 brk(0x080D0488) = 0 24556: 14.6082 brk(0x080D2488) = 0 24556: 14.6083 read(3, 0x080CD544, 5120) = 0 24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 ESPIPE 24556: 14.6085 close(3) = 0 24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0 So, does somebody knows what is happening at that point, why, and how can I "fine-tune" it? Kind regards, Gy?rgy P?sztor From chip at innovates.com Mon Apr 20 16:17:03 2015 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 20 Apr 2015 11:17:03 -0500 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> Message-ID: Slow ssh logon is almost always reverse DNS problems on the server side. Adding the client to the server's /etc/hosts will usually resolve the problem. -Chip On Sat, Apr 18, 2015 at 10:37 PM, P?SZTOR Gy?rgy < pasztor at sagv5.gyakg.u-szeged.hu> wrote: > Hi, > > I faced with that, the login onto my new omnios zone is slow. > I tried to debug. > Many of the symptoms seemed pretty the same as this: > > http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ > > Also in my case it stopped at the same point: after the kexinit sent. > > However, on my omnios, the cryptadm list showed this: > pasztor at omni:~$ cryptoadm list > > User-level providers: > Provider: /usr/lib/security/$ISA/pkcs11_kernel.so > Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so > > Kernel software providers: > des > aes > arcfour > blowfish > ecc > sha1 > sha2 > md4 > md5 > rsa > swrand > > Kernel hardware providers: > [---end of output----] > > So, in my case it did not contained the tpm module. > I tried the opposite: enabling the tpm module, but nothing changed. > (Maybe it become even slower. I did not count the seconds) > So, I rewert it back, and run the same truss command, which revealed this: > There are tons's of file openings in the /usr/lib/locale dir at that point: > > 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0 > 24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA", > O_RDONLY) = 7 > 24560: 8.8236 fstat(7, 0x08047658) = 0 > 24560: 8.8237 mmap(0x00000000, 94904, PROT_READ, MAP_PRIVATE, 7, 0) = > 0xFEDE7000 > 24560: 8.8238 close(7) = 0 > ... > 24560: 14.5883 > open("/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA", O_RDONLY) = 7 > 24560: 14.5884 fstat(7, 0x08047678) = 0 > 24560: 14.6061 read(7, " ^ ( ( [EDCD ] ( [E1C1 ]".., 82) = 82 > 24560: 14.6063 close(7) = 0 > 24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0 > 24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE) Err#22 > EINVAL > 24560: 14.6069 fstat64(1, 0x08046E00) = 0 > 24560: 14.6070 brk(0x080689D0) = 0 > 24560: 14.6071 brk(0x0806A9D0) = 0 > 24560: 14.6072 fstat64(1, 0x08046D00) = 0 > 24560: 14.6074 close(5) = 0 > 24560: 14.6075 write(1, " C\n P O S I X\n a f _ Z".., 2891) = 2891 > 24556: 14.6076 read(3, " C\n P O S I X\n a f _ Z".., 5120) = 2891 > 24560: 14.6077 _exit(0) > 24556: 14.6080 brk(0x080D0488) = 0 > 24556: 14.6082 brk(0x080D2488) = 0 > 24556: 14.6083 read(3, 0x080CD544, 5120) = 0 > 24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 > ESPIPE > 24556: 14.6085 close(3) = 0 > 24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0 > > So, does somebody knows what is happening at that point, > why, > and how can I "fine-tune" it? > > Kind regards, > Gy?rgy P?sztor > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wzmalone at gmail.com Mon Apr 20 16:29:12 2015 From: wzmalone at gmail.com (Zach Malone) Date: Mon, 20 Apr 2015 10:29:12 -0600 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> Message-ID: Alternatively, you can define reverse entries for your SSH clients (if you control the DNS server), or just disable reverse DNS lookup in your sshd config altogether. Are SSH logins to localhost slow? 127.0.0.1 should be defined, so if ssh-ing from your host to itself is quick, that would indicate a DNS issue. On Mon, Apr 20, 2015 at 10:17 AM, Schweiss, Chip wrote: > Slow ssh logon is almost always reverse DNS problems on the server side. > Adding the client to the server's /etc/hosts will usually resolve the > problem. > > -Chip > > On Sat, Apr 18, 2015 at 10:37 PM, P?SZTOR Gy?rgy > wrote: >> >> Hi, >> >> I faced with that, the login onto my new omnios zone is slow. >> I tried to debug. >> Many of the symptoms seemed pretty the same as this: >> >> http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ >> >> Also in my case it stopped at the same point: after the kexinit sent. >> >> However, on my omnios, the cryptadm list showed this: >> pasztor at omni:~$ cryptoadm list >> >> User-level providers: >> Provider: /usr/lib/security/$ISA/pkcs11_kernel.so >> Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so >> >> Kernel software providers: >> des >> aes >> arcfour >> blowfish >> ecc >> sha1 >> sha2 >> md4 >> md5 >> rsa >> swrand >> >> Kernel hardware providers: >> [---end of output----] >> >> So, in my case it did not contained the tpm module. >> I tried the opposite: enabling the tpm module, but nothing changed. >> (Maybe it become even slower. I did not count the seconds) >> So, I rewert it back, and run the same truss command, which revealed this: >> There are tons's of file openings in the /usr/lib/locale dir at that >> point: >> >> 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0 >> 24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA", >> O_RDONLY) = 7 >> 24560: 8.8236 fstat(7, 0x08047658) = 0 >> 24560: 8.8237 mmap(0x00000000, 94904, PROT_READ, MAP_PRIVATE, 7, 0) = >> 0xFEDE7000 >> 24560: 8.8238 close(7) = 0 >> ... >> 24560: 14.5883 >> open("/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA", O_RDONLY) = >> 7 >> 24560: 14.5884 fstat(7, 0x08047678) = 0 >> 24560: 14.6061 read(7, " ^ ( ( [EDCD ] ( [E1C1 ]".., 82) = 82 >> 24560: 14.6063 close(7) = 0 >> 24560: 14.6065 getdents64(5, 0xFEE04000, 8192) = 0 >> 24560: 14.6069 ioctl(1, TCGETA, 0x08046DBE) Err#22 >> EINVAL >> 24560: 14.6069 fstat64(1, 0x08046E00) = 0 >> 24560: 14.6070 brk(0x080689D0) = 0 >> 24560: 14.6071 brk(0x0806A9D0) = 0 >> 24560: 14.6072 fstat64(1, 0x08046D00) = 0 >> 24560: 14.6074 close(5) = 0 >> 24560: 14.6075 write(1, " C\n P O S I X\n a f _ Z".., 2891) = 2891 >> 24556: 14.6076 read(3, " C\n P O S I X\n a f _ Z".., 5120) = 2891 >> 24560: 14.6077 _exit(0) >> 24556: 14.6080 brk(0x080D0488) = 0 >> 24556: 14.6082 brk(0x080D2488) = 0 >> 24556: 14.6083 read(3, 0x080CD544, 5120) = 0 >> 24556: 14.6084 llseek(3, 0, SEEK_CUR) Err#29 >> ESPIPE >> 24556: 14.6085 close(3) = 0 >> 24556: 14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0 >> >> So, does somebody knows what is happening at that point, >> why, >> and how can I "fine-tune" it? >> >> Kind regards, >> Gy?rgy P?sztor >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From rt at steait.net Mon Apr 20 16:41:12 2015 From: rt at steait.net (Rune Tipsmark) Date: Mon, 20 Apr 2015 16:41:12 +0000 Subject: [OmniOS-discuss] crash dump analysis help In-Reply-To: References: <8c2da48b329444469abfef68339e7a76@EX1301.steait.net> <1429527764554.96817@steait.net>, Message-ID: <1429548072149.28960@steait.net> it's nearly 30 gigs... not sure anyone would download it :) maybe I can compress it or something. br, Rune ________________________________________ From: Dan McDonald Sent: Monday, April 20, 2015 2:40 PM To: Rune Tipsmark Cc: omnios-discuss Subject: Re: [OmniOS-discuss] crash dump analysis help > On Apr 20, 2015, at 7:02 AM, Rune Tipsmark wrote: > > root at zfs10:/root# uname -a > SunOS zfs10 5.11 omnios-10b9c79 i86pc i386 i86pc That's r151012 (modulo today's update... read the list in a bit). > Any idea how I can troubleshoot further? Share the dump so people can see it. Dan From vab at bb-c.de Mon Apr 20 17:11:34 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 20 Apr 2015 19:11:34 +0200 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash Message-ID: <21813.13126.379443.853370@glaurung.bb-c.de> Hello all! This is paraphrased from a mail that I had sent to Dan privately on March 31st. Unfortunately, the problem still persists in 151014. There seems to be a bug in the IPS version that comes with OmniOS. If there is a dash in the publisher name and the repo is accessed via http, it breaks: omnitest# pkg set-publisher -g http://omnios-server:12345/ my-pub pkg set-publisher: Could not refresh the catalog for my-pub http protocol error: code: 400 reason: Bad Request URL: 'http://omnios-server:12345/my-pub/catalog/1/catalog.attrs' It does not matter if the client is OmniOS or Solaris 11.2, it always breaks. If I run that same command against a Solaris 11.2 server with an identical repository, it works. If I use the identical repo locally, it works. If I mount the repository via NFS from an OmniOS server, it works. All combinations work, except the one I want: The repo served from an OmniOS box via http. :-( The SMF service itself runs fine, no maintenance mode, no error messages, nothing. It is only when I try to set the publisher on the client, and the client wants to retrieve the catalog, I get the above error. When I researched this bug before I found a reference to it somewhere, saying that it is a bug in cherrypy, but I can't find that reference again, now that I look for it. The Solaris 11.2 SRU8 /usr/bin/pkg has CLIENT_API_VERSION = 79, whereas the OmniOS /usr/bin/pkg is at CLIENT_API_VERSION = 75. So my guess is that the bug was fixed upstream somewhere between the pkg version shipped with OmniOS 151014 and the one shipped S11.2 SRU 8. Has anyone seen this problem before? Or does anyone have an OmniOS system successfully serving IPS packages with a dash in the publisher name? Any and all info gratefully accepted! It is entirely possible that I am doing something wrong, but I don't really know where to look. Thanks -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Mon Apr 20 17:48:17 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Apr 2015 13:48:17 -0400 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: <21813.13126.379443.853370@glaurung.bb-c.de> References: <21813.13126.379443.853370@glaurung.bb-c.de> Message-ID: <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> > On Apr 20, 2015, at 1:11 PM, Volker A. Brandt wrote: > > Hello all! > > > This is paraphrased from a mail that I had sent to Dan privately on > March 31st. Unfortunately, the problem still persists in 151014. Dug through my mail, and I didn't see this note. I may have lost it, but gmail is usually good about not letting you get rid of mails. :( > There seems to be a bug in the IPS version that comes with OmniOS. If > there is a dash in the publisher name and the repo is accessed via http, > it breaks: > > omnitest# pkg set-publisher -g http://omnios-server:12345/ my-pub > pkg set-publisher: Could not refresh the catalog for my-pub > > http protocol error: code: 400 reason: Bad Request > URL: 'http://omnios-server:12345/my-pub/catalog/1/catalog.attrs' > > It does not matter if the client is OmniOS or Solaris 11.2, it always > breaks. I'm seeing a different variant of this error using a toy repo I set up. It has to be an http repo using pkg.depotd. If I use a file:/// URL, it appears to work. > The Solaris 11.2 SRU8 /usr/bin/pkg has CLIENT_API_VERSION = 79, whereas > the OmniOS /usr/bin/pkg is at CLIENT_API_VERSION = 75. So my guess is > that the bug was fixed upstream somewhere between the pkg version > shipped with OmniOS 151014 and the one shipped S11.2 SRU 8. The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which is in turn a downstream of Oracle's, but last synched in 2013 (because Oracle uses hg, and git from hg is annoying). The github URL is https://github.com/omniti-labs/pkg5/ if you wanna poke around in the source we use. NOTE we have per-release branches starting with r151014, but the "default master" is called "omnios" because we're a downstream child of another downstream child. > Has anyone seen this problem before? Or does anyone have an OmniOS > system successfully serving IPS packages with a dash in the publisher > name? Any and all info gratefully accepted! It is entirely possible > that I am doing something wrong, but I don't really know where to look. I don't know of anyone who uses dashes in their publisher name. I wonder if this bug was around a while, and that's why it's "ms.omniti.com" instead of "omniti-ms", for example? ANYWAY, my toy server with an empty repo had this in its logs: 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 "" "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg)" 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /publisher/0/ HTTP/1.1" 200 57 "" "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; pkg)" Dan From vab at bb-c.de Mon Apr 20 20:38:19 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 20 Apr 2015 22:38:19 +0200 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> References: <21813.13126.379443.853370@glaurung.bb-c.de> <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> Message-ID: <21813.25531.190043.134121@glaurung.bb-c.de> Hi Dan! > > This is paraphrased from a mail that I had sent to Dan privately > > on March 31st. Unfortunately, the problem still persists in > > 151014. > > Dug through my mail, and I didn't see this note. I may have lost > it, but gmail is usually good about not letting you get rid of > mails. :( Well, I sent it to @omniti.com. My guess is you don't see any of my mails because they are filtered away. But no matter, as long as the discuss list works, that's fine. > I'm seeing a different variant of this error using a toy repo I set > up. It has to be an http repo using pkg.depotd. If I use a > file:/// URL, it appears to work. Exactly. Good to know that I am not imagining things. > The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which > is in turn a downstream of Oracle's, but last synched in 2013 > (because Oracle uses hg, and git from hg is annoying). Interesting, wasn't aware of that. So is it really just a matter of mercurial->git conversion, or has the OI/Omni version of pkg diverged too much? if the former, maybe one of the many tools could be leveraged that pull stuff out of hg repos and push it into git? > The github > URL is https://github.com/omniti-labs/pkg5/ if you wanna poke around > in the source we use. NOTE we have per-release branches starting > with r151014, but the "default master" is called "omnios" because > we're a downstream child of another downstream child. Thanks for the pointer, but I guess it would take me ages to spot, let alone fix the bug. > I don't know of anyone who uses dashes in their publisher name. Well, now you know. :-) BTW IHAC who uses lots of dashes in lots of publisher names under Solaris... just a matter of taste I guess. > wonder if this bug was around a while, and that's why it's > "ms.omniti.com" instead of "omniti-ms", for example? Sounds likely. I wouldn't know. :-) > ANYWAY, my toy server with an empty repo had this in its logs: > > 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 "" > "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; > pkg)" Interesting. Where does that log come from? Do you have an Apache with redirect rules sitting in front of your repo? I did play around with redirects and rewrite rules, but wasn't really happy, so I decided to concentrate on one problem at a time. My Apache logs show similar entries when I tell the IPS client to use port 80 (where an Apache is listening on the pkg server host): 192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] "GET /my-repo/versions/0/ HTTP/1.1" 404 220 "-" "pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full; pkg)" ...but the pkg/server:my-pub instance listens on another port, hence the 404 codes. Going forward, what is the likelihood of OmniOS adopting a more recent version of the Oracle IPS gate? I don't really think I can offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if it fixes that bug. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Mon Apr 20 20:58:02 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 20 Apr 2015 16:58:02 -0400 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: <21813.25531.190043.134121@glaurung.bb-c.de> References: <21813.13126.379443.853370@glaurung.bb-c.de> <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> <21813.25531.190043.134121@glaurung.bb-c.de> Message-ID: > On Apr 20, 2015, at 4:38 PM, Volker A. Brandt wrote: > > Hi Dan! >> >> Dug through my mail, and I didn't see this note. I may have lost >> it, but gmail is usually good about not letting you get rid of >> mails. :( > > Well, I sent it to @omniti.com. My guess is you don't see any of > my mails because they are filtered away. But no matter, as long as > the discuss list works, that's fine. I may have deleted it while reading on my phone (which can happen more than I'd like). >> The OmniOS version of pkg(5) is a downstream of OpenIndiana's, which >> is in turn a downstream of Oracle's, but last synched in 2013 >> (because Oracle uses hg, and git from hg is annoying). > > Interesting, wasn't aware of that. So is it really just a matter > of mercurial->git conversion, or has the OI/Omni version of pkg > diverged too much? > > if the former, maybe one of the many tools could be leveraged that > pull stuff out of hg repos and push it into git? I don't know. I don't do the downstreaming from Oracle... OI does. > >> wonder if this bug was around a while, and that's why it's >> "ms.omniti.com" instead of "omniti-ms", for example? > > Sounds likely. I wouldn't know. :-) I mention that for the list's benefit, because that decision was made before I arrived at OmniTI. >> ANYWAY, my toy server with an empty repo had this in its logs: >> >> 127.0.0.1 - - [20/Apr/2015:13:32:46] "GET /versions/0/ HTTP/1.1" 200 179 "" >> "pkg/1427212657 (sunos i86pc; 5.11 omnios-fbd6dc7; full; >> pkg)" > > Interesting. Where does that log come from? Do you have an Apache > with redirect rules sitting in front of your repo? Just running pkg.depotd in the foreground. /usr/lib/pkg.depotd -p 2112 -d blah Port 2112, with "blah" being a pkgrepo(1M) directory. > I did play around > with redirects and rewrite rules, but wasn't really happy, so I decided > to concentrate on one problem at a time. My Apache logs show similar > entries when I tell the IPS client to use port 80 (where an Apache is > listening on the pkg server host): > > 192.168.xxx.xxx - - [20/Apr/2015:17:58:10 +0200] "GET /my-repo/versions/0/ > HTTP/1.1" 404 220 "-" "pkg/1427212657 (sunos i86pc; 5.11 omnios-170cea2; full; > pkg)" > > ...but the pkg/server:my-pub instance listens on another port, hence > the 404 codes. I'd have to look deeper, and maybe enable more debugging output. > Going forward, what is the likelihood of OmniOS adopting a more recent > version of the Oracle IPS gate? I don't really think I can offer much > help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if > it fixes that bug. I have enough else pulling at me at the moment I can't look at this deeply right now. Sorry, Dan From eric.sproul at circonus.com Mon Apr 20 21:05:53 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Mon, 20 Apr 2015 17:05:53 -0400 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: <21813.25531.190043.134121@glaurung.bb-c.de> References: <21813.13126.379443.853370@glaurung.bb-c.de> <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> <21813.25531.190043.134121@glaurung.bb-c.de> Message-ID: On Mon, Apr 20, 2015 at 4:38 PM, Volker A. Brandt wrote: >> wonder if this bug was around a while, and that's why it's >> "ms.omniti.com" instead of "omniti-ms", for example? > > Sounds likely. I wouldn't know. :-) I would know, as I was the one that chose it when I was at OmniTI. :) The various OmniTI "extra" publishers (those other than omnios) use the pseudo-domain-name style, simply for the high degree of confidence that it is globally unique. I was unaware of the issue with dashes in publisher names, but IIRC way back at the beginning (circa 2011) when we started working on what would become OmniOS, I'm pretty sure there was an "omni-os" publisher configured. Perhaps the issue was introduced in a later revision (one that's in the OI fork) but only fixed after the last time OI synced their tree. > Going forward, what is the likelihood of OmniOS adopting a more recent > version of the Oracle IPS gate? I don't really think I can offer much > help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well worth while if > it fixes that bug. As I understand it (someone please correct me if I'm wrong), we cannot use Oracle's pkg-gate unmodified, as it has dependencies on closed bits in Solaris for certain features. Those need to be stripped/modified for non-Solaris use, which is what OI has been maintaining in their fork, thanks mostly to the hard work of Andrzej Szeszo. Anyone interested in helping refresh https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit both communities. Eric From vab at bb-c.de Mon Apr 20 21:32:22 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 20 Apr 2015 23:32:22 +0200 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: References: <21813.13126.379443.853370@glaurung.bb-c.de> <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> <21813.25531.190043.134121@glaurung.bb-c.de> Message-ID: <21813.28774.347280.762161@glaurung.bb-c.de> > >> The OmniOS version of pkg(5) is a downstream of OpenIndiana's, > >> which is in turn a downstream of Oracle's, but last synched in > >> 2013 (because Oracle uses hg, and git from hg is annoying). > > > > Interesting, wasn't aware of that. So is it really just a matter > > of mercurial->git conversion, or has the OI/Omni version of pkg > > diverged too much? > > > > if the former, maybe one of the many tools could be leveraged that > > pull stuff out of hg repos and push it into git? > > I don't know. I don't do the downstreaming from Oracle... OI does. OK, I will post a query to the OI dev list when I have time. > Just running pkg.depotd in the foreground. > > /usr/lib/pkg.depotd -p 2112 -d blah > > Port 2112, with "blah" being a pkgrepo(1M) directory. Neat trick for debugging, thanks. [...] > > ...but the pkg/server:my-pub instance listens on another port, > > hence the 404 codes. > > I'd have to look deeper, and maybe enable more debugging output. The 404 is expected. That was just to show the "pkg/1427212657". > > Going forward, what is the likelihood of OmniOS adopting a more > > recent version of the Oracle IPS gate? I don't really think I can > > offer much help (ENOTIME, ENOCLUE, etc.) but IMHO it would be well > > worth while if it fixes that bug. > > I have enough else pulling at me at the moment I can't look at this > deeply right now. Understood. Same here. Thanks for having a look! Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Mon Apr 20 21:37:47 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 20 Apr 2015 23:37:47 +0200 Subject: [OmniOS-discuss] Bug in pkg/server on OmniOS when the publisher name contains a dash In-Reply-To: References: <21813.13126.379443.853370@glaurung.bb-c.de> <5FE205EC-6959-4413-89AC-EEB5089B9263@omniti.com> <21813.25531.190043.134121@glaurung.bb-c.de> Message-ID: <21813.29099.50176.659966@glaurung.bb-c.de> > As I understand it (someone please correct me if I'm wrong), we > cannot use Oracle's pkg-gate unmodified, as it has dependencies on > closed bits in Solaris for certain features. Those need to be > stripped/modified for non-Solaris use, which is what OI has been > maintaining in their fork, thanks mostly to the hard work of Andrzej > Szeszo. Anyone interested in helping refresh > https://github.com/OpenIndiana/pkg5 from Oracle's gate would benefit > both communities. Thanks for the info Eric! A quick glance at that URL shows that people are working on it. Last commit was March 9th by Alexander Pyhalov. I'll ping the OI guys as to what kind of effort is needed. Don't hold your breath though. :-) Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Tue Apr 21 07:39:18 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Tue, 21 Apr 2015 09:39:18 +0200 Subject: [OmniOS-discuss] omnios zone experiences on openindiana In-Reply-To: <20150418190931.GA22924@linux.gyakg.u-szeged.hu> References: <20150418190931.GA22924@linux.gyakg.u-szeged.hu> Message-ID: <21813.65190.248585.289804@glaurung.bb-c.de> Hi Gy?rgy! > I do not remember, where I discussed about this topic earlier, but I > just wanted to tell a success-story: Thank you, interesting story. :-) > now I > can have omnios 151014 lts zones on my openindiana nas. I am surprised that it works. What "brand" setting do you use for the zone? My guess is "ipkg". Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From cks at cs.toronto.edu Tue Apr 21 20:51:27 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 21 Apr 2015 16:51:27 -0400 Subject: [OmniOS-discuss] What do people use for basic system monitoring? Message-ID: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Out of curiosity: I suspect that plenty of people are gathering basic system activity stats for their OmniOS systems and pushing them into modern metrics systems such as graphite (to pick perhaps the most well known package for this). For those that are doing this, what is your preferred collection agent? (My ideal collection agent would be able to gather stats for ZFS, network and disk IO, and general kernel stats analogous to vmstat and mpstat.) Thanks in advance. - cks From doug at will.to Tue Apr 21 21:38:45 2015 From: doug at will.to (Doug Hughes) Date: Tue, 21 Apr 2015 17:38:45 -0400 Subject: [OmniOS-discuss] What do people use for basic system monitoring? In-Reply-To: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> References: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Message-ID: I'm interested in this too! Once upon a time we used Orcallator for this on Sol10, which is quite a bit like Ganglia, but uses the venerable SEtoolkit to pull stats. I'd be curious what other people are doing here since all of that stuff is pretty much unmaintained for a decade, though it provided decent stats per server. On Tue, Apr 21, 2015 at 4:51 PM, Chris Siebenmann wrote: > Out of curiosity: I suspect that plenty of people are gathering basic > system activity stats for their OmniOS systems and pushing them into > modern metrics systems such as graphite (to pick perhaps the most well > known package for this). For those that are doing this, what is your > preferred collection agent? > > (My ideal collection agent would be able to gather stats for ZFS, > network and disk IO, and general kernel stats analogous to vmstat > and mpstat.) > > Thanks in advance. > > - cks > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus at omniti.com Tue Apr 21 21:41:21 2015 From: jesus at omniti.com (Theo Schlossnagle) Date: Tue, 21 Apr 2015 17:41:21 -0400 Subject: [OmniOS-discuss] What do people use for basic system monitoring? In-Reply-To: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> References: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Message-ID: Given that several of the original core OmniOS team work for Circonus, I'd say the answer from this side would be pretty biased. Collectd works okay, but certainly isn't my preference as the polling interval can't easily modified on-demand during troubleshooting. We use nad everywhere: https://github.com/circonus-labs/nad It exposes systems telemetry in JSON over HTTP and has some really nice features like exposing histograms of syscall latencies and/or disk I/O latencies allowing you to track the latency of every individual I/O against every spindle -- nice for understanding workload changes and disk behavior issues. As it is JSON data, it should trivial to pump it into just about any metrics systems... Circonus is free for up to 500 metrics: http://www.circonus.com/free-account/ On Tue, Apr 21, 2015 at 4:51 PM, Chris Siebenmann wrote: > Out of curiosity: I suspect that plenty of people are gathering basic > system activity stats for their OmniOS systems and pushing them into > modern metrics systems such as graphite (to pick perhaps the most well > known package for this). For those that are doing this, what is your > preferred collection agent? > > (My ideal collection agent would be able to gather stats for ZFS, > network and disk IO, and general kernel stats analogous to vmstat > and mpstat.) > > Thanks in advance. > > - cks > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at 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: From eric.sproul at circonus.com Tue Apr 21 21:47:26 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Tue, 21 Apr 2015 17:47:26 -0400 Subject: [OmniOS-discuss] What do people use for basic system monitoring? In-Reply-To: References: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Message-ID: On Tue, Apr 21, 2015 at 5:41 PM, Theo Schlossnagle wrote: > We use nad everywhere: https://github.com/circonus-labs/nad It exposes > systems telemetry in JSON over HTTP and has some really nice features like > exposing histograms of syscall latencies and/or disk I/O latencies allowing > you to track the latency of every individual I/O against every spindle -- > nice for understanding workload changes and disk behavior issues. I was writing something at the same time, so I'll just let Theo's word stand and add a couple of things: If you `make install-illumos` you'll get all the default illumos plugins activated and an SMF service installed as well. The "track every I/O" feature comes from a (non-default) plugin called "io.js" that uses node-libdtrace [1] and DTrace's io provider to report the latency of *every* I/O operation, allowing you to build a histogram like https://circonus-ops.circonus.com/trending/graphs/view/0b3b922e-f670-4efa-9cc8-84cb7489e3af to visualize disk latency distribution. Eric [1] https://github.com/bcantrill/node-libdtrace From eric.sproul at circonus.com Tue Apr 21 21:57:51 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Tue, 21 Apr 2015 17:57:51 -0400 Subject: [OmniOS-discuss] What do people use for basic system monitoring? In-Reply-To: References: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Message-ID: On Tue, Apr 21, 2015 at 5:47 PM, Eric Sproul wrote: > The "track every I/O" feature comes from a (non-default) plugin called > "io.js" that uses node-libdtrace [1] and DTrace's io provider to > report the latency of *every* I/O operation, allowing you to build a > histogram like ... like this, actually: https://share.circonus.com/shared/graphs/0b3b922e-f670-4efa-9cc8-84cb7489e3af/H64Fns Sorry, I pasted the wrong link. From pasztor at sagv5.gyakg.u-szeged.hu Tue Apr 21 23:05:35 2015 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Wed, 22 Apr 2015 01:05:35 +0200 Subject: [OmniOS-discuss] omnios zone experiences on openindiana In-Reply-To: <21813.65190.248585.289804@glaurung.bb-c.de> References: <20150418190931.GA22924@linux.gyakg.u-szeged.hu> <21813.65190.248585.289804@glaurung.bb-c.de> Message-ID: <20150421230534.GC22570@linux.gyakg.u-szeged.hu> Hi, "Volker A. Brandt" ?rta 2015-04-21 09:39-kor: > > I do not remember, where I discussed about this topic earlier, but I > > just wanted to tell a success-story: > > Thank you, interesting story. :-) > > > now I > > can have omnios 151014 lts zones on my openindiana nas. > > I am surprised that it works. What "brand" setting do you use for > the zone? My guess is "ipkg". Yes. It was ipkg on the source omnios too, so I just did not change that. I exported the config on omni, and imported here, and the zfs too. Maybe, if someone interested, I can try to reproduce the whole thing, and write a more "structured" howto / wikipage about it. Or try to write the whole into a shellscript and make the whole zone migration automated, and upload that to my github repo. (Not on this week! ;-) ) The only hard question for myself (poetic question) how to automate the root privilege gathering on the target side? (sudo, pfexec, su - ?) Kind regards, Gy?rgy P?sztor From pasztor at sagv5.gyakg.u-szeged.hu Tue Apr 21 23:33:19 2015 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Wed, 22 Apr 2015 01:33:19 +0200 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> Message-ID: <20150421233319.GD22570@linux.gyakg.u-szeged.hu> Hi, "Zach Malone" ?rta 2015-04-20 10:29-kor: > Alternatively, you can define reverse entries for your SSH clients (if > you control the DNS server), or just disable reverse DNS lookup in > your sshd config altogether. Are SSH logins to localhost slow? > 127.0.0.1 should be defined, so if ssh-ing from your host to itself is > quick, that would indicate a DNS issue. Maybe I did not wrote some detail, which I thought obvious for me. Yes, ssh to localhost is sloow too. It is my home network, and also I have proper dns records forward and in reverse direction. As I already said: when I log in from the same workstation to my openindiana box or into an openindiana zoen, the ssh is subsecond fast! The issue comes only, when I log in to my omnios zone. > On Mon, Apr 20, 2015 at 10:17 AM, Schweiss, Chip wrote: > >> I faced with that, the login onto my new omnios zone is slow. > >> I tried to debug. > >> Many of the symptoms seemed pretty the same as this: > >> > >> http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ Please read this link first! As I already wrote: I checked the "basic" things first. Also I ruled out that case, what Jason writes about: It is not the tpm module. However the simptoms are similar: My ssh client is also wait at the same phase: after the kexinit was sent. (However, it not minutes in my case, only ~10 secs) > >> There are tons's of file openings in the /usr/lib/locale dir at that > >> point: > >> > >> 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0 > >> 24560: 8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA", I don't know what happens at this point on server side, or what it tries to read / check in locale settings, or why... BUT On one of my openindiana box: pasztor at sb:~$ ls -l /usr/lib/locale/ total 14 drwxr-xr-x 8 root bin 8 Mar 5 2014 C lrwxrwxrwx 1 root root 3 Mar 5 2014 POSIX -> ./C And compare that to omnios: pasztor at omni:~$ ls -l /usr/lib/locale/ total 2984 drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 af_ZA.UTF-8 ... drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 zh_SG.UTF-8 drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 zh_TW.UTF-8 pasztor at omni:~$ ls -l /usr/lib/locale/ |wc -l 223 And another difference: pasztor at sb:~$ locale LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= vs. pasztor at omni:~$ locale LANG=hu_HU.UTF-8 LC_CTYPE="hu_HU.UTF-8" LC_NUMERIC="hu_HU.UTF-8" LC_TIME="hu_HU.UTF-8" LC_COLLATE="hu_HU.UTF-8" LC_MONETARY="hu_HU.UTF-8" LC_MESSAGES="hu_HU.UTF-8" LC_ALL= So, Now I tried this: root at omni:/usr/lib/locale# mkdir _ root at omni:/usr/lib/locale# mv * _ ; ln -s _/{C,POSIX} . mv: cannot move ?_? to a subdirectory of itself, ?_/_? root at omni:/usr/lib/locale# ls -l total 15 lrwxrwxrwx 1 root root 3 Apr 21 23:18 C -> _/C lrwxrwxrwx 1 root root 7 Apr 21 23:18 POSIX -> _/POSIX drwxr-xr-x 223 root root 224 Apr 21 23:18 _ pasztor at intrepid:/tmp$ time ssh omni date Tue Apr 21 23:19:02 UTC 2015 real 0m0.248s user 0m0.004s sys 0m0.008s So, the problem is definitely about the locales. Sshd check into every locale dir on the kexinit phase. I think it's a bug. Why on earth does this needed to an ssh login? Proof 2: Now I revert back locale dir into it's original state: root at omni:/usr/lib/locale# rm C POSIX ; mv _/* . root at omni:/usr/lib/locale# rmdir _ Aaaand: pasztor at intrepid:/tmp$ time ssh omni date 2015. ?prilis 21. 23:21:18 UTC real 0m9.575s user 0m0.028s sys 0m0.004s So, do you understand it now? It is definitely not dns. I quoted the output of truss on purpose, not just some L'art pour Lart thing. I also choose the subject carefully, not just because I was bored ;-) The situation changed now, it's not "maybe" now. We have definitely a proof about that. Kind regards, Gy?rgy P?sztor From richard.elling at richardelling.com Wed Apr 22 02:38:32 2015 From: richard.elling at richardelling.com (Richard Elling) Date: Tue, 21 Apr 2015 19:38:32 -0700 Subject: [OmniOS-discuss] What do people use for basic system monitoring? In-Reply-To: References: <20150421205127.420DA7A0933@apps0.cs.toronto.edu> Message-ID: <0E3B7CA8-C845-4D29-85CB-E43CD972522D@richardelling.com> > On Apr 21, 2015, at 2:41 PM, Theo Schlossnagle wrote: > > Given that several of the original core OmniOS team work for Circonus, I'd say the answer from this side would be pretty biased. > > Collectd works okay, but certainly isn't my preference as the polling interval can't easily modified on-demand during troubleshooting. We've done a bunch of work on collectd collectors. It has the benefit of being lightweight and low-impact, but isn't as inherently flexible as nad. https://github.com/Coraid/coraid-collectd > > We use nad everywhere: https://github.com/circonus-labs/nad It exposes systems telemetry in JSON over HTTP and has some really nice features like exposing histograms of syscall latencies and/or disk I/O latencies allowing you to track the latency of every individual I/O against every spindle -- nice for understanding workload changes and disk behavior issues. > > As it is JSON data, it should trivial to pump it into just about any metrics systems... Circonus is free for up to 500 metrics: > > http://www.circonus.com/free-account/ > > > On Tue, Apr 21, 2015 at 4:51 PM, Chris Siebenmann > wrote: > Out of curiosity: I suspect that plenty of people are gathering basic > system activity stats for their OmniOS systems and pushing them into > modern metrics systems such as graphite (to pick perhaps the most well > known package for this). For those that are doing this, what is your > preferred collection agent? graphite is at the end of its life, though we can still feed it from collectd. There are many things I like about Circonus, but for various reasons we've been going with influxdb as an interesting target. > > (My ideal collection agent would be able to gather stats for ZFS, > network and disk IO, and general kernel stats analogous to vmstat > and mpstat.) The upstream (collectd.org ) collectd collectors are pretty generic and lowest-common denominator. To get details like mpstat/vmstat we added new collectors, see above link. -- richard > > Thanks in advance. > > - cks > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > -- > Theo Schlossnagle > > http://omniti.com/is/theo-schlossnagle _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at netbsd.org Wed Apr 22 08:06:33 2015 From: richard at netbsd.org (Richard PALO) Date: Wed, 22 Apr 2015 10:06:33 +0200 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: <5532757B.4000107@netbsd.org> References: <553247BD.8080300@netbsd.org> <5532757B.4000107@netbsd.org> Message-ID: Le 18/04/15 17:17, Richard PALO a ?crit : > Le 18/04/15 14:14, Theo Schlossnagle a ?crit : >> We should probably publish an empty runtime/java/runtime64 that requires >> runtime/java. > > Alternately provide something like OI/Hipster does > https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openjdk-7/openjdk7-runtime64.p5m > > The more I think about this, the more I'm against keeping any vestiges of pkg:/runtime/java/runtime* in the gate. This *forces* distros to use pkg and in particular previously but not necessarily useful pkg names for the java distribution provided. Let's drop these two 'require' lines: > richard at omnis:/home/richard/src/illumos-gate/usr/src/pkg$ grep runtime manifests/system-dtrace-tests.mf > depend fmri=runtime/java type=require > depend fmri=runtime/java/runtime64 type=require Dan? From danmcd at omniti.com Wed Apr 22 12:48:16 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 08:48:16 -0400 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: References: <553247BD.8080300@netbsd.org> <5532757B.4000107@netbsd.org> Message-ID: > On Apr 22, 2015, at 4:06 AM, Richard PALO wrote: >> > The more I think about this, the more I'm against keeping any vestiges of pkg:/runtime/java/runtime* in the gate. > > This *forces* distros to use pkg and in particular previously but not necessarily useful pkg names for the java distribution provided. > > Let's drop these two 'require' lines: >> richard at omnis:/home/richard/src/illumos-gate/usr/src/pkg$ grep runtime manifests/system-dtrace-tests.mf >> depend fmri=runtime/java type=require >> depend fmri=runtime/java/runtime64 type=require > > Dan? I'm certainly fine with removal. You COULD also weaken these by setting type=optional as well. Dan From dain.bentley at gmail.com Wed Apr 22 13:19:53 2015 From: dain.bentley at gmail.com (Dain Bentley) Date: Wed, 22 Apr 2015 09:19:53 -0400 Subject: [OmniOS-discuss] Updates Message-ID: Hello, I was looking in the Wiki and couldn't find it, how do I go about applying security updates and things like that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Apr 22 13:29:38 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 09:29:38 -0400 Subject: [OmniOS-discuss] Update curl to 7.42 (SECURITY FIXES) Message-ID: <21E1514E-0635-4711-B736-F81DCE2EABA2@omniti.com> All supported versions (r151006, r151012, and r151014) have just had their "curl" updated to 7.42.0. This update contains FOUR security fixes, per the official curl website: http://curl.haxx.se/ This is a non-rebooting update, but you may need to restart libcurl-using services. Dan From richard at netbsd.org Wed Apr 22 13:31:29 2015 From: richard at netbsd.org (Richard PALO) Date: Wed, 22 Apr 2015 15:31:29 +0200 Subject: [OmniOS-discuss] pkg:/runtime/java/runtime64 cannot be found In-Reply-To: References: <553247BD.8080300@netbsd.org> <5532757B.4000107@netbsd.org> Message-ID: <5537A2B1.6090802@netbsd.org> Le 22/04/15 14:48, Dan McDonald a ?crit : > > I'm certainly fine with removal. You COULD also weaken these by setting type=optional as well. > > Dan > My personal feeling is that it is no longer appropriate for the gate to *presume* any particular 'packaging' coupling with the userland components provided by a distribution. This is just one pertinent example with OmniOS... perhaps SmartOS is another example... I'm sure there are more. From danmcd at omniti.com Wed Apr 22 13:38:56 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 09:38:56 -0400 Subject: [OmniOS-discuss] Updates In-Reply-To: References: Message-ID: <289E7B1C-1773-482C-9B4C-90D3BA3CEC96@omniti.com> > On Apr 22, 2015, at 9:19 AM, Dain Bentley wrote: > > Hello, I was looking in the Wiki and couldn't find it, how do I go about applying security updates and things like that? Just like any other software update, run the following with privilege: pkg update Also, you can run: pkg update -n to get a dry-run and set your expectations (e.g. if you haven't got the recent kernel fix, you'll find out with -n whether or not you need to reboot). And if you want BIG details (can be verbose with large numbers of packages); pkg update -nv Dan From doug at will.to Wed Apr 22 14:50:44 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 10:50:44 -0400 Subject: [OmniOS-discuss] r151014 missing /usr/share/man/man1/cpp Message-ID: it seems like an odd omission. But I can't find the man page for cpp anywhere. I tried find in /usr/share/man to see if it was anywhere else, but couldn't find it. It's not that I don't have man pages installed. There are lots, but cpp is notably missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.sproul at circonus.com Wed Apr 22 15:37:31 2015 From: eric.sproul at circonus.com (Eric Sproul) Date: Wed, 22 Apr 2015 11:37:31 -0400 Subject: [OmniOS-discuss] r151014 missing /usr/share/man/man1/cpp In-Reply-To: References: Message-ID: On Wed, Apr 22, 2015 at 10:50 AM, Doug Hughes wrote: > it seems like an odd omission. But I can't find the man page for cpp > anywhere. > > I tried find in /usr/share/man to see if it was anywhere else, but couldn't > find it. It's not that I don't have man pages installed. There are lots, but > cpp is notably missing. Simply put, there isn't one. https://github.com/omniti-labs/omnios-build/tree/master/build/cpp/files is the only source we have. This is not part of illumos, it's an open-source replacement for the previous, closed-source cpp we inherited from OpenSolaris. I believe it's a copy from https://github.com/joyent/illumos-extra/tree/master/cpp but I'm hazy on the history. Eric From andreas at luka-online.de Wed Apr 22 15:59:54 2015 From: andreas at luka-online.de (Andreas Luka) Date: Wed, 22 Apr 2015 23:59:54 +0800 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: <20150421233319.GD22570@linux.gyakg.u-szeged.hu> References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> <20150421233319.GD22570@linux.gyakg.u-szeged.hu> Message-ID: You maybe check your passing of the language environment from ssh-client and sshd-server. If you want to pass the language environment than make sure that /etc/ssh/ssh_config in the client includes the line SendEnv LANG LC_* and that /etc/ssh/sshd_config in the server includes the line AcceptEnv LANG LC_* and that you have the same hungarian language files present on server and client side.?DAndreas Szia! Andreas On Wed, 22 Apr 2015 07:33:19 +0800, P?SZTOR Gy?rgy wrote: > Hi, > > "Zach Malone" ?rta 2015-04-20 10:29-kor: >> Alternatively, you can define reverse entries for your SSH clients (if >> you control the DNS server), or just disable reverse DNS lookup in >> your sshd config altogether. Are SSH logins to localhost slow? >> 127.0.0.1 should be defined, so if ssh-ing from your host to itself is >> quick, that would indicate a DNS issue. > > Maybe I did not wrote some detail, which I thought obvious for me. > Yes, ssh to localhost is sloow too. > It is my home network, and also I have proper dns records forward and in > reverse direction. > As I already said: when I log in from the same workstation to my > openindiana box or into an openindiana zoen, the ssh is subsecond fast! > The issue comes only, when I log in to my omnios zone. > >> On Mon, Apr 20, 2015 at 10:17 AM, Schweiss, Chip >> wrote: >> >> I faced with that, the login onto my new omnios zone is slow. >> >> I tried to debug. >> >> Many of the symptoms seemed pretty the same as this: >> >> >> >> >> http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/ > > Please read this link first! > As I already wrote: I checked the "basic" things first. > Also I ruled out that case, what Jason writes about: > It is not the tpm module. > > However the simptoms are similar: My ssh client is also wait at the same > phase: after the kexinit was sent. > (However, it not minutes in my case, only ~10 secs) > >> >> There are tons's of file openings in the /usr/lib/locale dir at that >> >> point: >> >> >> >> 24560: 8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0 >> >> 24560: 8.8234 >> open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA", > > I don't know what happens at this point on server side, or what it tries > to > read / check in locale settings, or why... > BUT > On one of my openindiana box: > pasztor at sb:~$ ls -l /usr/lib/locale/ > total 14 > drwxr-xr-x 8 root bin 8 Mar 5 2014 C > lrwxrwxrwx 1 root root 3 Mar 5 2014 POSIX -> ./C > > And compare that to omnios: > pasztor at omni:~$ ls -l /usr/lib/locale/ > total 2984 > drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 af_ZA.UTF-8 > ... > drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 zh_SG.UTF-8 > drwxr-xr-x 8 root bin 8 ?pr. 18 14:00 zh_TW.UTF-8 > pasztor at omni:~$ ls -l /usr/lib/locale/ |wc -l > 223 > > And another difference: > pasztor at sb:~$ locale > LANG= > LC_CTYPE="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_ALL= > > vs. > pasztor at omni:~$ locale > LANG=hu_HU.UTF-8 > LC_CTYPE="hu_HU.UTF-8" > LC_NUMERIC="hu_HU.UTF-8" > LC_TIME="hu_HU.UTF-8" > LC_COLLATE="hu_HU.UTF-8" > LC_MONETARY="hu_HU.UTF-8" > LC_MESSAGES="hu_HU.UTF-8" > LC_ALL= > > > So, Now I tried this: > root at omni:/usr/lib/locale# mkdir _ > root at omni:/usr/lib/locale# mv * _ ; ln -s _/{C,POSIX} . > mv: cannot move ?_? to a subdirectory of itself, ?_/_? > root at omni:/usr/lib/locale# ls -l > total 15 > lrwxrwxrwx 1 root root 3 Apr 21 23:18 C -> _/C > lrwxrwxrwx 1 root root 7 Apr 21 23:18 POSIX -> _/POSIX > drwxr-xr-x 223 root root 224 Apr 21 23:18 _ > > pasztor at intrepid:/tmp$ time ssh omni date > Tue Apr 21 23:19:02 UTC 2015 > > real 0m0.248s > user 0m0.004s > sys 0m0.008s > > > So, the problem is definitely about the locales. > Sshd check into every locale dir on the kexinit phase. > I think it's a bug. Why on earth does this needed to an ssh login? > > Proof 2: > Now I revert back locale dir into it's original state: > root at omni:/usr/lib/locale# rm C POSIX ; mv _/* . > root at omni:/usr/lib/locale# rmdir _ > > Aaaand: > pasztor at intrepid:/tmp$ time ssh omni date > 2015. ?prilis 21. 23:21:18 UTC > > real 0m9.575s > user 0m0.028s > sys 0m0.004s > > So, do you understand it now? > It is definitely not dns. > I quoted the output of truss on purpose, not just some L'art pour Lart > thing. > I also choose the subject carefully, not just because I was bored ;-) > The situation changed now, it's not "maybe" now. We have definitely a > proof about that. > > Kind regards, > Gy?rgy P?sztor > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Using Opera's mail client: http://www.opera.com/mail/ From doug at will.to Wed Apr 22 21:07:15 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 17:07:15 -0400 Subject: [OmniOS-discuss] r151014 missing /usr/share/man/man1/cpp In-Reply-To: References: Message-ID: Any place to submit long term requests like this? It is fair to note that Linux and OpenIndiana are in the same boat, as one might expect. Solaris10 has a pretty good man page for cpp, but obviously that couldn't be used directly for copyright reasons at least, but perhaps some of the options are different. (For one, I know that the -B option for solaris10 isn't in the version in OmniOS dist) -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Wed Apr 22 21:22:17 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 17:22:17 -0400 Subject: [OmniOS-discuss] r151014 feedback Message-ID: The awesome: the nlockmgr bug appears to be fixed. We're not seeing that any more and nlockmgr is, so far, starting flawlessly. But, our brand new Intel 10G card is no longer recognized.. It started out ok, then a whole host of SFP+ not recognized over the course of about 1-2 minutes, and now the card will not attach the driver. We also had a whole lot of fmadm faulty at the same time. I acquitted them assuming they were spurious, but now dladm show-phys won't even see the ixgbe devices at all. The summary says " Fault class : fault.io.pciex.device-interr Affects : dev:////pci at 0,0/pci8086,340e at 7/pci111d,806e at 0/pci111d,806e at 4 /pci8086,7a11 at 0 out of service, but associated components no longer faulty FRU : "PCIe 1" (hc://:product-id=SUN-FIRE-X4275-SERVER:server-id=x4275-3-15-39:chassis-id=0931XFG005/motherboard=0/hostbridge=4/pciexrc=4/pciexbus=25/pciexdev=0/pciexfn=0/pciexbus=26/pciexdev=4/pciexfn=0/pciexbus=33/pciexdev=0) acquitted Is there a handy way to reset all of this and bring the device back into service and reset any notion of the faults? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Apr 22 21:36:19 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 17:36:19 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: Message-ID: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> > On Apr 22, 2015, at 5:22 PM, Doug Hughes wrote: > > The awesome: the nlockmgr bug appears to be fixed. We're not seeing that any more and nlockmgr is, so far, starting flawlessly. Good. > But, our brand new Intel 10G card is no longer recognized.. It started out ok, then a whole host of SFP+ not recognized over the course of about 1-2 minutes, and now the card will not attach the driver. We also had a whole lot of fmadm faulty at the same time. I acquitted them assuming they were spurious, but now dladm show-phys won't even see the ixgbe devices at all. > > The summary says " > > Fault class : fault.io.pciex.device-interr > Affects : dev:////pci at 0,0/pci8086,340e at 7/pci111d,806e at 0/pci111d,806e at 4/pci8086,7a11 at 0 > out of service, but associated components no longer faulty > FRU : "PCIe 1" (hc://:product-id=SUN-FIRE-X4275-SERVER:server-id=x4275-3-15-39:chassis-id=0931XFG005/motherboard=0/hostbridge=4/pciexrc=4/pciexbus=25/pciexdev=0/pciexfn=0/pciexbus=26/pciexdev=4/pciexfn=0/pciexbus=33/pciexdev=0) > acquitted > > > Is there a handy way to reset all of this and bring the device back into service and reset any notion of the faults? Please look at your /var/adm/messages* files for ixgbe complaints. There may be more useful data in there. ixgbe generally is VERY VERY picky about which SFP+ one uses. Dan From mir at miras.org Wed Apr 22 21:45:08 2015 From: mir at miras.org (Michael Rasmussen) Date: Wed, 22 Apr 2015 23:45:08 +0200 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: <20150422234508.23f8ae3e@sleipner.datanom.net> On Wed, 22 Apr 2015 17:36:19 -0400 Dan McDonald wrote: > > Please look at your /var/adm/messages* files for ixgbe complaints. There may be more useful data in there. ixgbe generally is VERY VERY picky about which SFP+ one uses. > Certified SFP+ from Intel with ixgbe should be taken as the complet list of working SFP+;-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: "Good health" is merely the slowest rate at which one can die. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From doug at will.to Wed Apr 22 21:55:39 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 17:55:39 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: Yes, we had it working with this SFP+ before the upgrade, and now it won't even see the NIC card at all. The last messages in messages are about the SFP+ module not supported and failed to initialize adapter. I tried rem_drv ixgbe; add_drv ixgbe; it loads but fails to attach. Even if it doesn't recognize the SFP+ any more (though it was running fine for weeks on r151012), I wouldn't expect it to not see the card at all. (It shows in lspci, but not in dladm) On Wed, Apr 22, 2015 at 5:36 PM, Dan McDonald wrote: > > > On Apr 22, 2015, at 5:22 PM, Doug Hughes wrote: > > > > The awesome: the nlockmgr bug appears to be fixed. We're not seeing that > any more and nlockmgr is, so far, starting flawlessly. > > Good. > > > But, our brand new Intel 10G card is no longer recognized.. It started > out ok, then a whole host of SFP+ not recognized over the course of about > 1-2 minutes, and now the card will not attach the driver. We also had a > whole lot of fmadm faulty at the same time. I acquitted them assuming they > were spurious, but now dladm show-phys won't even see the ixgbe devices at > all. > > > > The summary says " > > > > Fault class : fault.io.pciex.device-interr > > Affects : dev:////pci at 0,0/pci8086,340e at 7/pci111d,806e at 0 > /pci111d,806e at 4/pci8086,7a11 at 0 > > out of service, but associated components no longer > faulty > > FRU : "PCIe 1" > (hc://:product-id=SUN-FIRE-X4275-SERVER:server-id=x4275-3-15-39:chassis-id=0931XFG005/motherboard=0/hostbridge=4/pciexrc=4/pciexbus=25/pciexdev=0/pciexfn=0/pciexbus=26/pciexdev=4/pciexfn=0/pciexbus=33/pciexdev=0) > > acquitted > > > > > > Is there a handy way to reset all of this and bring the device back into > service and reset any notion of the faults? > > Please look at your /var/adm/messages* files for ixgbe complaints. There > may be more useful data in there. ixgbe generally is VERY VERY picky about > which SFP+ one uses. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Apr 22 23:25:38 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 19:25:38 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <20150422234508.23f8ae3e@sleipner.datanom.net> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <20150422234508.23f8ae3e@sleipner.datanom.net> Message-ID: <04FE39A5-5586-44F7-A5FF-C276C70A3659@omniti.com> How about the messages output? Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 22, 2015, at 5:45 PM, Michael Rasmussen wrote: > > On Wed, 22 Apr 2015 17:36:19 -0400 > Dan McDonald wrote: > >> >> Please look at your /var/adm/messages* files for ixgbe complaints. There may be more useful data in there. ixgbe generally is VERY VERY picky about which SFP+ one uses. > Certified SFP+ from Intel with ixgbe should be taken as the complet > list of working SFP+;-) > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > "Good health" is merely the slowest rate at which one can die. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Apr 22 23:52:59 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 22 Apr 2015 19:52:59 -0400 Subject: [OmniOS-discuss] New OmniOS bloody update Message-ID: <943AC0AE-1BD5-4485-8512-C30679B6F436@omniti.com> Based on omnios-build commit 6f28911 and illumos-omnios commit fb4b19c. I pushed the whole wad of packages out, but in actuality not much changed this time around. Highlights include: - Security fixes in CURL and illumos that are out in r151014. - A few ZFS fixes that were also backported into r151014 - Not visible to OmniOS users, but several upstream-from-OmniOS pushes that should, once ALL are in, allow OmniOS to build stock illumos-gate. - Addition of netperf (2.6.0) and iperf (3.0.11) as native OmniOS packages. They are both 64-bit binaries, but that shouldn't be a problem. They are also stock for now, but I reserve the right to add features (command-line IPsec comes to mind). A "pkg update" will take care of things properly. I've not updated install media for this bump. Dan From doug at will.to Thu Apr 23 01:11:06 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 21:11:06 -0400 Subject: [OmniOS-discuss] New OmniOS bloody update In-Reply-To: <943AC0AE-1BD5-4485-8512-C30679B6F436@omniti.com> References: <943AC0AE-1BD5-4485-8512-C30679B6F436@omniti.com> Message-ID: <553846AA.4010807@will.to> On 4/22/2015 7:52 PM, Dan McDonald wrote: > > - Addition of netperf (2.6.0) and iperf (3.0.11) as native OmniOS packages. They are both 64-bit binaries, but that shouldn't be a problem. They are also stock for now, but I reserve the right to add features (command-line IPsec comes to mind). woohoo! I can delete my own ips version of these. great! > A "pkg update" will take care of things properly. I've not updated install media for this bump. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From doug at will.to Thu Apr 23 01:43:25 2015 From: doug at will.to (Doug Hughes) Date: Wed, 22 Apr 2015 21:43:25 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <04FE39A5-5586-44F7-A5FF-C276C70A3659@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <20150422234508.23f8ae3e@sleipner.datanom.net> <04FE39A5-5586-44F7-A5FF-C276C70A3659@omniti.com> Message-ID: <55384E3D.5030505@will.to> I'm going to start with replacing the SFP+ modules as soon as they arrive and go from there. There's a fair chance that might just take care of it. The odd thing is, though, that the ones that are in there were accepted previously. Head scratcher, I know. On 4/22/2015 7:25 PM, Dan McDonald wrote: > How about the messages output? > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 22, 2015, at 5:45 PM, Michael Rasmussen wrote: >> >> On Wed, 22 Apr 2015 17:36:19 -0400 >> Dan McDonald wrote: >> >>> Please look at your /var/adm/messages* files for ixgbe complaints. There may be more useful data in there. ixgbe generally is VERY VERY picky about which SFP+ one uses. >> Certified SFP+ from Intel with ixgbe should be taken as the complet >> list of working SFP+;-) >> >> -- >> Hilsen/Regards >> Michael Rasmussen >> >> Get my public GnuPG keys: >> michael rasmussen cc >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> mir datanom net >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> mir miras org >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 >> -------------------------------------------------------------- >> /usr/games/fortune -es says: >> "Good health" is merely the slowest rate at which one can die. >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From tim at multitalents.net Thu Apr 23 14:36:09 2015 From: tim at multitalents.net (Tim Rice) Date: Thu, 23 Apr 2015 07:36:09 -0700 (PDT) Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: On Wed, 22 Apr 2015, Doug Hughes wrote: > Even if it doesn't recognize the SFP+ any more (though it was running fine > for weeks on r151012), I wouldn't expect it to not see the card at all. (It > shows in lspci, but not in dladm) Have you booted r151012 to see if the card still works? It would be good to rule out an actual hardware failure. -- Tim Rice Multitalents tim at multitalents.net From pasztor at sagv5.gyakg.u-szeged.hu Thu Apr 23 14:51:08 2015 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Thu, 23 Apr 2015 16:51:08 +0200 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> <20150421233319.GD22570@linux.gyakg.u-szeged.hu> Message-ID: <20150423145108.GE28294@linux.gyakg.u-szeged.hu> Hi, "Andreas Luka" ?rta 2015-04-22 23:59-kor: > You maybe check your passing of the language environment from ssh-client > and sshd-server. I checked. > If you want to pass the language environment than make sure that I don't want. But it does automatically, so I just don't mind it :) > /etc/ssh/ssh_config in the client includes the line > SendEnv LANG LC_* Yes. It's in there in my ubuntu client's default config. > and that /etc/ssh/sshd_config in the server includes the line > AcceptEnv LANG LC_* OmniOS doesn't use openssh, they use their modified Solaris-derived version. It doesn't contain the AcceptEnv option. However, the manual says some exceptions, what are the defaultly accepted environment variables, and the manuel explicitly mentions these variables. But the login is still slow, if I write the "PermitUserEnvironment yes" into my ssd_config on OmniOS. > and that you have the same hungarian language files present on server and > client side.?DAndreas And with/without it: as my example showed: If I did not move away the language dirs from /usr/lib/locale then it can transfer my localized settings, and display the date in hungarian. So it works fine. The problem is still that, it's slooooow, because look into all locale dir... Kind regards, Gy?rgy P?sztor From doug at will.to Thu Apr 23 15:03:32 2015 From: doug at will.to (Doug Hughes) Date: Thu, 23 Apr 2015 11:03:32 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: it shows in lspci and is brand new. I'm pretty sure it still works. Most likely it's the optics that is causing this. (it also shows in POST) On Thu, Apr 23, 2015 at 10:36 AM, Tim Rice wrote: > On Wed, 22 Apr 2015, Doug Hughes wrote: > > > Even if it doesn't recognize the SFP+ any more (though it was running > fine > > for weeks on r151012), I wouldn't expect it to not see the card at all. > (It > > shows in lspci, but not in dladm) > > Have you booted r151012 to see if the card still works? > It would be good to rule out an actual hardware failure. > > > -- > Tim Rice Multitalents > tim at multitalents.net > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Thu Apr 23 19:58:17 2015 From: doug at will.to (Doug Hughes) Date: Thu, 23 Apr 2015 15:58:17 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. On Thu, Apr 23, 2015 at 11:03 AM, Doug Hughes wrote: > it shows in lspci and is brand new. I'm pretty sure it still works. Most > likely it's the optics that is causing this. (it also shows in POST) > > On Thu, Apr 23, 2015 at 10:36 AM, Tim Rice wrote: > >> On Wed, 22 Apr 2015, Doug Hughes wrote: >> >> > Even if it doesn't recognize the SFP+ any more (though it was running >> fine >> > for weeks on r151012), I wouldn't expect it to not see the card at all. >> (It >> > shows in lspci, but not in dladm) >> >> Have you booted r151012 to see if the card still works? >> It would be good to rule out an actual hardware failure. >> >> >> -- >> Tim Rice Multitalents >> tim at multitalents.net >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cks at cs.toronto.edu Thu Apr 23 20:02:28 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Thu, 23 Apr 2015 16:02:28 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: Your message of Thu, 23 Apr 2015 15:58:17 -0400. Message-ID: <20150423200229.0D7A47A05B3@apps0.cs.toronto.edu> > Oddly, removing the SFP modules makes no difference. Replacing the > modules - still doesn't show up. I really do expect to see the > interfaces in dladm show-phys now.. also add_drv still fails to > attach, which is odd. I feel like this has something to do with fault > management not clearing state somewhere along the way. This card was > definitely working just fine and the only thing that changes was the > latest upgrade, followed by a lot of fmadm stuff, and now it seems > like the error state has not cleared entirely. We just inserted the > new intel optics and I tried add_drv ixgbe again, but it still fails > to attach even though lspci sees the card just fine and it shows up in > PROM. Although this is not necessarily a good long-term solution to the problem, it might be interesting to boot a Linux live CD on this hardware and see what happens and what it reports about the hardware. We have had that magically fix ixgbe copper 10G ports that previously would only come up at 1G under OmniOS. (And this magic fix persisted through both reboots and powerdowns.) - cks From danmcd at omniti.com Thu Apr 23 20:07:56 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 23 Apr 2015 16:07:56 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> Message-ID: <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> > On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: > > Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. Dammit. Chris Siebenmann mentions one dead chicken to try, but the catch is, I got the impression that in your old r151012 Boot Environment, everything is working just fine. Am I correct in understanding that your r151012 BE works fine with these, but the r151014 BE does not? Once you answer that question, I can make suggestions on how to proceed. Thanks, Dan From doug at will.to Thu Apr 23 22:22:20 2015 From: doug at will.to (Doug Hughes) Date: Thu, 23 Apr 2015 18:22:20 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> Message-ID: I'll try a reboot into r151012 tonight. On Thu, Apr 23, 2015 at 4:07 PM, Dan McDonald wrote: > > > On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: > > > > Oddly, removing the SFP modules makes no difference. Replacing the > modules - still doesn't show up. I really do expect to see the interfaces > in dladm show-phys now.. also add_drv still fails to attach, which is odd. > I feel like this has something to do with fault management not clearing > state somewhere along the way. This card was definitely working just fine > and the only thing that changes was the latest upgrade, followed by a lot > of fmadm stuff, and now it seems like the error state has not cleared > entirely. We just inserted the new intel optics and I tried add_drv ixgbe > again, but it still fails to attach even though lspci sees the card just > fine and it shows up in PROM. > > Dammit. > > Chris Siebenmann mentions one dead chicken to try, but the catch is, I got > the impression that in your old r151012 Boot Environment, everything is > working just fine. > > Am I correct in understanding that your r151012 BE works fine with these, > but the r151014 BE does not? > > Once you answer that question, I can make suggestions on how to proceed. > > Thanks, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at luka-online.de Fri Apr 24 01:48:18 2015 From: andreas at luka-online.de (Andreas Luka) Date: Fri, 24 Apr 2015 09:48:18 +0800 Subject: [OmniOS-discuss] slow ssh login, maybee to many locales? In-Reply-To: <20150423145108.GE28294@linux.gyakg.u-szeged.hu> References: <20150419033720.GA29218@linux.gyakg.u-szeged.hu> <20150421233319.GD22570@linux.gyakg.u-szeged.hu> <20150423145108.GE28294@linux.gyakg.u-szeged.hu> Message-ID: 1. Would it be help for time being to remove all language files, except the hungarian, english and POSIX 2. Could you give me a more specific informatio, version of your host environment, vrtual machine version, do you login from host or remote, what shell you are using and so on, so I will set up my spare machine and try to replicate your problem. I would like to follow up as we have to work for different clients with language setting as well as in hungarian as in chinese. ?dv?zl?m Andreas On Thu, 23 Apr 2015 22:51:08 +0800, P?SZTOR Gy?rgy wrote: > Hi, > > "Andreas Luka" ?rta 2015-04-22 23:59-kor: >> You maybe check your passing of the language environment from ssh-client >> and sshd-server. > > I checked. > >> If you want to pass the language environment than make sure that > > I don't want. But it does automatically, so I just don't mind it :) > >> /etc/ssh/ssh_config in the client includes the line >> SendEnv LANG LC_* > > Yes. It's in there in my ubuntu client's default config. > >> and that /etc/ssh/sshd_config in the server includes the line >> AcceptEnv LANG LC_* > > OmniOS doesn't use openssh, they use their modified Solaris-derived > version. It doesn't contain the AcceptEnv option. > However, the manual says some exceptions, what are the defaultly accepted > environment variables, and the manuel explicitly mentions these > variables. > But the login is still slow, if I write the "PermitUserEnvironment yes" > into my ssd_config on OmniOS. > >> and that you have the same hungarian language files present on server >> and >> client side.?DAndreas > > And with/without it: as my example showed: > If I did not move away the language dirs from /usr/lib/locale then it can > transfer my localized settings, and display the date in hungarian. So it > works fine. > > The problem is still that, it's slooooow, because look into all locale > dir... > > Kind regards, > Gy?rgy P?sztor > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Using Opera's mail client: http://www.opera.com/mail/ From doug at will.to Fri Apr 24 03:52:32 2015 From: doug at will.to (Doug Hughes) Date: Thu, 23 Apr 2015 23:52:32 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> Message-ID: <5539BE00.5050309@will.to> BINGO I noticed that ixgbe entries were completely missing from driver_aliases. a little bit of googling to remember the syntax to bind the right mapping, a little bit of scanpci (PS - we really should have this as part of OmniOS, I imported it from a Sol10 machine), and I found the mapping and then: root at x4275-3-15-39:/root# add_drv -i '"pciex8086,10fb"' ixgbe root at x4275-3-15-39:/root# dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE usbecm0 Ethernet down 10 full usbecm0 igb0 Ethernet up 1000 full igb0 igb1 Ethernet up 1000 full igb1 igb2 Ethernet down 0 half igb2 igb3 Ethernet up 1000 full igb3 ixgbe0 Ethernet up 10000 full ixgbe0 ixgbe1 Ethernet up 10000 full ixgbe1 root at x4275-3-15-39:/root# back in business. On 4/23/2015 4:07 PM, Dan McDonald wrote: >> On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: >> >> Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. > Dammit. > > Chris Siebenmann mentions one dead chicken to try, but the catch is, I got the impression that in your old r151012 Boot Environment, everything is working just fine. > > Am I correct in understanding that your r151012 BE works fine with these, but the r151014 BE does not? > > Once you answer that question, I can make suggestions on how to proceed. > > Thanks, > Dan > From danmcd at omniti.com Fri Apr 24 04:21:42 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 24 Apr 2015 00:21:42 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <5539BE00.5050309@will.to> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> <5539BE00.5050309@will.to> Message-ID: <55A494C2-FB81-4530-9F69-40027BFD70ED@omniti.com> So you fixed this on the 014 BE? Strange the entries went away... Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 23, 2015, at 11:52 PM, Doug Hughes wrote: > > BINGO > > I noticed that ixgbe entries were completely missing from driver_aliases. a little bit of googling to remember the syntax to bind the right mapping, a little bit of scanpci (PS - we really should have this as part of OmniOS, I imported it from a Sol10 machine), and I found the mapping and then: > > root at x4275-3-15-39:/root# add_drv -i '"pciex8086,10fb"' ixgbe > root at x4275-3-15-39:/root# dladm show-phys > LINK MEDIA STATE SPEED DUPLEX DEVICE > usbecm0 Ethernet down 10 full usbecm0 > igb0 Ethernet up 1000 full igb0 > igb1 Ethernet up 1000 full igb1 > igb2 Ethernet down 0 half igb2 > igb3 Ethernet up 1000 full igb3 > ixgbe0 Ethernet up 10000 full ixgbe0 > ixgbe1 Ethernet up 10000 full ixgbe1 > root at x4275-3-15-39:/root# > > back in business. > > > On 4/23/2015 4:07 PM, Dan McDonald wrote: >>> On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: >>> >>> Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. >> Dammit. >> >> Chris Siebenmann mentions one dead chicken to try, but the catch is, I got the impression that in your old r151012 Boot Environment, everything is working just fine. >> >> Am I correct in understanding that your r151012 BE works fine with these, but the r151014 BE does not? >> >> Once you answer that question, I can make suggestions on how to proceed. >> >> Thanks, >> Dan > From doug at will.to Fri Apr 24 04:24:02 2015 From: doug at will.to (Doug Hughes) Date: Fri, 24 Apr 2015 00:24:02 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <55A494C2-FB81-4530-9F69-40027BFD70ED@omniti.com> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> <5539BE00.5050309@will.to> <55A494C2-FB81-4530-9F69-40027BFD70ED@omniti.com> Message-ID: <5539C562.1070303@will.to> Aye, fixed in r151014. Somewhere during the fmd storm and reboots, I guess they all just disappeared. Don't suppose you have an upstream open source version of scanpci to include? (it's a pretty useful utility) On 4/24/2015 12:21 AM, Dan McDonald wrote: > So you fixed this on the 014 BE? Strange the entries went away... > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 23, 2015, at 11:52 PM, Doug Hughes wrote: >> >> BINGO >> >> I noticed that ixgbe entries were completely missing from driver_aliases. a little bit of googling to remember the syntax to bind the right mapping, a little bit of scanpci (PS - we really should have this as part of OmniOS, I imported it from a Sol10 machine), and I found the mapping and then: >> >> root at x4275-3-15-39:/root# add_drv -i '"pciex8086,10fb"' ixgbe >> root at x4275-3-15-39:/root# dladm show-phys >> LINK MEDIA STATE SPEED DUPLEX DEVICE >> usbecm0 Ethernet down 10 full usbecm0 >> igb0 Ethernet up 1000 full igb0 >> igb1 Ethernet up 1000 full igb1 >> igb2 Ethernet down 0 half igb2 >> igb3 Ethernet up 1000 full igb3 >> ixgbe0 Ethernet up 10000 full ixgbe0 >> ixgbe1 Ethernet up 10000 full ixgbe1 >> root at x4275-3-15-39:/root# >> >> back in business. >> >> >> On 4/23/2015 4:07 PM, Dan McDonald wrote: >>>> On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: >>>> >>>> Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. >>> Dammit. >>> >>> Chris Siebenmann mentions one dead chicken to try, but the catch is, I got the impression that in your old r151012 Boot Environment, everything is working just fine. >>> >>> Am I correct in understanding that your r151012 BE works fine with these, but the r151014 BE does not? >>> >>> Once you answer that question, I can make suggestions on how to proceed. >>> >>> Thanks, >>> Dan From danmcd at omniti.com Fri Apr 24 04:43:47 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 24 Apr 2015 00:43:47 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: <5539C562.1070303@will.to> References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> <5539BE00.5050309@will.to> <55A494C2-FB81-4530-9F69-40027BFD70ED@omniti.com> <5539C562.1070303@will.to> Message-ID: > On Apr 24, 2015, at 12:24 AM, Doug Hughes wrote: > > Aye, fixed in r151014. Somewhere during the fmd storm and reboots, I guess they all just disappeared. > > Don't suppose you have an upstream open source version of scanpci to include? (it's a pretty useful utility) We have "lspci" already in OmniOS: r151014(~)[0]% pkg list -v pciutils FMRI IFO pkg://omnios/system/pciutils at 3.2.1-0.151014:20150402T213657Z i-- r151014(~)[0]% pkg contents pciutils PATH usr/sbin usr/sbin/lspci usr/sbin/setpci usr/sbin/update-pciids usr/share/man/man7 usr/share/man/man7/pcilib.7 usr/share/man/man8 usr/share/man/man8/lspci.8 usr/share/man/man8/setpci.8 usr/share/man/man8/update-pciids.8 r151014(~)[0]% Dan From xiaonan830818 at gmail.com Fri Apr 24 09:34:57 2015 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Fri, 24 Apr 2015 17:34:57 +0800 Subject: [OmniOS-discuss] Issues about OmniOS software installation package Message-ID: Hi all, I am a newbie of OmniOS, and install OmniOS vagrant box today. I have the following issues about software installation package. (1) Is there any repository which provides *.pkg install package for OmniOS? I think it is very convenient to install software than source code. (2) Could the OmniOS vagrant box with gcc installed? Lacking of gcc is awful. Thanks in advance! -- Best Regards Nan Xiao From xiaonan830818 at gmail.com Fri Apr 24 09:43:36 2015 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Fri, 24 Apr 2015 17:43:36 +0800 Subject: [OmniOS-discuss] Issues about OmniOS software installation package Message-ID: Hi all, I am a newbie of OmniOS, and install OmniOS vagrant box today. I have the following issues about software installation package. (1) Is there any repository which provides *.pkg install package for OmniOS? I think it is very convenient to install software than source code. (2) Could the OmniOS vagrant box with gcc installed? Lacking of gcc is awful. Thanks in advance! -- Best Regards Nan Xiao From danmcd at omniti.com Fri Apr 24 14:39:27 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 24 Apr 2015 10:39:27 -0400 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: References: Message-ID: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> > On Apr 24, 2015, at 5:43 AM, Nan Xiao wrote: > > Hi all, > > I am a newbie of OmniOS, and install OmniOS vagrant box today. I have > the following issues about software installation package. > > (1) Is there any repository which provides *.pkg install package for > OmniOS? I think it is very convenient to install software than source > code. The "omnios" IPS publisher has some stuff in it. "pkg search " can help. There's another publisher: ms.omniti.com, which includes compiles packages for things OmniTI uses itself. It's not officially supported for external users, but we sure don't mind people using packages there: pkg set-publisher -g http://pkg.omniti.com/omniti-ms ms.omniti.com You should see a whole bunch of new packages there. Finally, "pkgsrc" is available. Its maintainer works at Joyent, so illumos support (which includes OmniOS) is quite good. > (2) Could the OmniOS vagrant box with gcc installed? Lacking of gcc is awful. Two versions of gcc are available from the main "omnios" publisher. Just utter: pkg install gcc48 pkg install gcc44 (So you can build illumos-omnios) and you're golden. Dan From danmcd at omniti.com Fri Apr 24 14:41:16 2015 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 24 Apr 2015 10:41:16 -0400 Subject: [OmniOS-discuss] Fwd: [discuss] pkgsrc-2015Q1 binary packages for illumos now available References: <20150424105321.GA77784@joyent.com> Message-ID: <9241B5A7-F00D-48B9-BC65-475BD54C0E56@omniti.com> Funny, I was just mentioning pkgsrc, and this shows up on the illumos discussion list. FYI, Dan > Begin forwarded message: > > From: "Jonathan Perkin" > Subject: [discuss] pkgsrc-2015Q1 binary packages for illumos now available > Date: April 24, 2015 at 6:53:21 AM EDT > To: discuss at lists.illumos.org > Reply-To: discuss at lists.illumos.org > > I'm pleased to announce the pkgsrc-2015Q1 binary package sets for > illumos are now available. As always you can install them using the > instructions here: > > http://pkgsrc.joyent.com/install-on-illumos/ > > SmartOS users can use the 15.1.0 image sets which will be available > over the next few days. > > Major changes in this quarterly release: > > * The epoll and inotify features provided for Linux compatibility in > newer SmartOS have been explicitly disabled, ensuring the packages > are more portable across distributions compared to 2014Q4. > > * OpenSSL is now on the 1.0.2 branch at version 1.0.2a. > > * PostgreSQL 9.4 has been added, PHP 5.3 has been removed. > > * 2,007 packages have been updated. > > Package counts are down compared to 2014Q4 due to PHP 5.3's removal, > but according to 'pkgin avail' are: > > 32-bit: 13,379 > 64-bit: 13,359 > Multiarch: 12,751 > > The general pkgsrc-2015Q1 announcement is here: > > http://mail-index.netbsd.org/pkgsrc-users/2015/04/14/msg021358.html > > Please report any bugs or feature requests specifically related to > this binary package set on our GitHub issues page: > > https://github.com/joyent/pkgsrc/issues > > Enjoy! > > -- > Jonathan Perkin - Joyent, Inc. - www.joyent.com > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175487-64bb3106 > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175487&id_secret=21175487-26add75e > Powered by Listbox: http://www.listbox.com From doug at will.to Fri Apr 24 15:32:58 2015 From: doug at will.to (Doug Hughes) Date: Fri, 24 Apr 2015 11:32:58 -0400 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: References: <162CA382-D7A4-4C4F-9BD9-FE0149D071FE@omniti.com> <04D52DED-F18A-4527-818C-903899DA2104@omniti.com> <5539BE00.5050309@will.to> <55A494C2-FB81-4530-9F69-40027BFD70ED@omniti.com> <5539C562.1070303@will.to> Message-ID: Yeah, I like lspci and am happy to see it! but it doesn't exactly provide the same information. Maybe there's a flag that I'm just not familiar with. e.g. from lspci -v: 21:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) Subsystem: Intel Corporation Ethernet Server Adapter X520-2 Flags: bus master, fast devsel, latency 0, IRQ 5 Memory at faf80000 (64-bit, non-prefetchable) I/O ports at dc00 Memory at faf7c000 (64-bit, non-prefetchable) Expansion ROM at fae80000 [disabled] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=64 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Here's scanpci: for same device: pci bus 0x0021 cardnum 0x00 function 0x00: vendor 0x8086 device *0x10fb* Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection Ok, I just answered my own question and learned something about lspci in the process. lspci -nn has the same information in a usable format. Good enough! On Fri, Apr 24, 2015 at 12:43 AM, Dan McDonald wrote: > > > On Apr 24, 2015, at 12:24 AM, Doug Hughes wrote: > > > > Aye, fixed in r151014. Somewhere during the fmd storm and reboots, I > guess they all just disappeared. > > > > Don't suppose you have an upstream open source version of scanpci to > include? (it's a pretty useful utility) > > We have "lspci" already in OmniOS: > > r151014(~)[0]% pkg list -v pciutils > FMRI > IFO > pkg://omnios/system/pciutils at 3.2.1-0.151014:20150402T213657Z > i-- > r151014(~)[0]% pkg contents pciutils > PATH > usr/sbin > usr/sbin/lspci > usr/sbin/setpci > usr/sbin/update-pciids > usr/share/man/man7 > usr/share/man/man7/pcilib.7 > usr/share/man/man8 > usr/share/man/man8/lspci.8 > usr/share/man/man8/setpci.8 > usr/share/man/man8/update-pciids.8 > r151014(~)[0]% > > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.poletto at gmail.com Fri Apr 24 17:37:46 2015 From: davide.poletto at gmail.com (Davide Poletto) Date: Fri, 24 Apr 2015 19:37:46 +0200 Subject: [OmniOS-discuss] Fwd: [discuss] pkgsrc-2015Q1 binary packages for illumos now available In-Reply-To: <9241B5A7-F00D-48B9-BC65-475BD54C0E56@omniti.com> References: <20150424105321.GA77784@joyent.com> <9241B5A7-F00D-48B9-BC65-475BD54C0E56@omniti.com> Message-ID: Hello all, A newbie consideration about verifying signature as an (optional) install step of pkgsrc on OmniOS: GnuPG is not available directly on a freshly installed OmniOS (I mean without adding a third party publisher for that specific purpose) so a question...why not including GnuPG in OmniOS? wouldn't it be useful? I know actually there is: http://pkg.niksula.hut.fi/info/0/security%2Fgnupg%401.4.19%2C5.11-0.151006%3A20150302T091253Z packaged one...but it refers to OmniOS 151006. Davide. On Fri, Apr 24, 2015 at 4:41 PM, Dan McDonald wrote: > Funny, I was just mentioning pkgsrc, and this shows up on the illumos > discussion list. > > FYI, > Dan > > > Begin forwarded message: > > > > From: "Jonathan Perkin" > > Subject: [discuss] pkgsrc-2015Q1 binary packages for illumos now > available > > Date: April 24, 2015 at 6:53:21 AM EDT > > To: discuss at lists.illumos.org > > Reply-To: discuss at lists.illumos.org > > > > I'm pleased to announce the pkgsrc-2015Q1 binary package sets for > > illumos are now available. As always you can install them using the > > instructions here: > > > > http://pkgsrc.joyent.com/install-on-illumos/ > > > > SmartOS users can use the 15.1.0 image sets which will be available > > over the next few days. > > > > Major changes in this quarterly release: > > > > * The epoll and inotify features provided for Linux compatibility in > > newer SmartOS have been explicitly disabled, ensuring the packages > > are more portable across distributions compared to 2014Q4. > > > > * OpenSSL is now on the 1.0.2 branch at version 1.0.2a. > > > > * PostgreSQL 9.4 has been added, PHP 5.3 has been removed. > > > > * 2,007 packages have been updated. > > > > Package counts are down compared to 2014Q4 due to PHP 5.3's removal, > > but according to 'pkgin avail' are: > > > > 32-bit: 13,379 > > 64-bit: 13,359 > > Multiarch: 12,751 > > > > The general pkgsrc-2015Q1 announcement is here: > > > > http://mail-index.netbsd.org/pkgsrc-users/2015/04/14/msg021358.html > > > > Please report any bugs or feature requests specifically related to > > this binary package set on our GitHub issues page: > > > > https://github.com/joyent/pkgsrc/issues > > > > Enjoy! > > > > -- > > Jonathan Perkin - Joyent, Inc. - www.joyent.com > > > > > > ------------------------------------------- > > illumos-discuss > > Archives: https://www.listbox.com/member/archive/182180/=now > > RSS Feed: > https://www.listbox.com/member/archive/rss/182180/21175487-64bb3106 > > Modify Your Subscription: > https://www.listbox.com/member/?member_id=21175487&id_secret=21175487-26add75e > > Powered by Listbox: http://www.listbox.com > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakansom at ohsu.edu Fri Apr 24 18:58:14 2015 From: hakansom at ohsu.edu (Marion Hakanson) Date: Fri, 24 Apr 2015 11:58:14 -0700 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: Message from Doug Hughes of "Fri, 24 Apr 2015 00:24:02 EDT." <5539C562.1070303@will.to> Message-ID: <201504241858.t3OIwEIN015685@kyklops.ohsu.edu> Doug, OmniOS pkg repo has lspci. It's in the "pciutils" package. Regards, Marion ================================================================= Subject: Re: [OmniOS-discuss] r151014 feedback From: Doug Hughes Date: Fri, 24 Apr 2015 00:24:02 -0400 (Thu 21:24 PDT) To: Dan McDonald Cc: "omnios-discuss at lists.omniti.com" Aye, fixed in r151014. Somewhere during the fmd storm and reboots, I guess they all just disappeared. Don't suppose you have an upstream open source version of scanpci to include? (it's a pretty useful utility) On 4/24/2015 12:21 AM, Dan McDonald wrote: > So you fixed this on the 014 BE? Strange the entries went away... > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 23, 2015, at 11:52 PM, Doug Hughes wrote: >> >> BINGO >> >> I noticed that ixgbe entries were completely missing from driver_aliases. a little bit of googling to remember the syntax to bind the right mapping, a little bit of scanpci (PS - we really should have this as part of OmniOS, I imported it from a Sol10 machine), and I found the mapping and then: >> >> root at x4275-3-15-39:/root# add_drv -i '"pciex8086,10fb"' ixgbe >> root at x4275-3-15-39:/root# dladm show-phys >> LINK MEDIA STATE SPEED DUPLEX DEVICE >> usbecm0 Ethernet down 10 full usbecm0 >> igb0 Ethernet up 1000 full igb0 >> igb1 Ethernet up 1000 full igb1 >> igb2 Ethernet down 0 half igb2 >> igb3 Ethernet up 1000 full igb3 >> ixgbe0 Ethernet up 10000 full ixgbe0 >> ixgbe1 Ethernet up 10000 full ixgbe1 >> root at x4275-3-15-39:/root# >> >> back in business. >> >> >> On 4/23/2015 4:07 PM, Dan McDonald wrote: >>>> On Apr 23, 2015, at 3:58 PM, Doug Hughes wrote: >>>> >>>> Oddly, removing the SFP modules makes no difference. Replacing the modules - still doesn't show up. I really do expect to see the interfaces in dladm show-phys now.. also add_drv still fails to attach, which is odd. I feel like this has something to do with fault management not clearing state somewhere along the way. This card was definitely working just fine and the only thing that changes was the latest upgrade, followed by a lot of fmadm stuff, and now it seems like the error state has not cleared entirely. We just inserted the new intel optics and I tried add_drv ixgbe again, but it still fails to attach even though lspci sees the card just fine and it shows up in PROM. >>> Dammit. >>> >>> Chris Siebenmann mentions one dead chicken to try, but the catch is, I got the impression that in your old r151012 Boot Environment, everything is working just fine. >>> >>> Am I correct in understanding that your r151012 BE works fine with these, but the r151014 BE does not? >>> >>> Once you answer that question, I can make suggestions on how to proceed. >>> >>> Thanks, >>> Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From hakansom at ohsu.edu Fri Apr 24 19:18:13 2015 From: hakansom at ohsu.edu (Marion Hakanson) Date: Fri, 24 Apr 2015 12:18:13 -0700 Subject: [OmniOS-discuss] r151014 feedback In-Reply-To: Message from Marion Hakanson of "Fri, 24 Apr 2015 11:58:14 PDT." <201504241858.t3OIwEIN015685@kyklops.ohsu.edu> Message-ID: <201504241918.t3OJIDk5015776@kyklops.ohsu.edu> Sigh, sorry for the redundant noise. Perhaps I should consider developing a caffeine habit.... Marion ================================================================== Subject: Re: [OmniOS-discuss] r151014 feedback From: Marion Hakanson Date: Fri, 24 Apr 2015 11:58:14 -0700 To: Doug Hughes Cc: "omnios-discuss at lists.omniti.com" Doug, OmniOS pkg repo has lspci. It's in the "pciutils" package. Regards, Marion ================================================================= Subject: Re: [OmniOS-discuss] r151014 feedback From: Doug Hughes Date: Fri, 24 Apr 2015 00:24:02 -0400 (Thu 21:24 PDT) To: Dan McDonald Cc: "omnios-discuss at lists.omniti.com" Aye, fixed in r151014. Somewhere during the fmd storm and reboots, I guess they all just disappeared. Don't suppose you have an upstream open source version of scanpci to include? (it's a pretty useful utility) From gate03 at landcroft.co.uk Sat Apr 25 08:03:11 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sat, 25 Apr 2015 18:03:11 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy Message-ID: <20150425180311.5119405f@emeritus> Hello, I've just bailed out of updating to LTS / r151014 because I was unable to copy the data across from the old system. My system has a single rpool mirrored three ways across c2t[023]d0s0 (all on-board SATA) so to upgrade, I: 1. download the update (USB version) and dd it to a stick. 2. # zfs snapshot -r rpool at Z 3. reboot from the stick and install the new OS to c2t0d0s0 4. # zpool import -o readonly=on -R /woz rpool woz That imports the 'old' system but degraded of course because c2t0d0s0 now holds the 'new' system so the mirror has only two of three copies. Now copy all my filesystems from old to new: 5. # for I in home mail-archive volumes etcetera ... do zfs send -R woz/$I at Z | zfs recv rpool/$I zfs destroy -r woz/$I at Z echo $I done The problem is that the process just dies. It copied about 200GiB but then just froze. No disk activity. ACPI was sort-of working because when I pressed the power button the console showed a message, but the machine didn't power down and I had to hold down the power button to obtain a hard power-off. I ran a zpool scrub the night before with no errors. If you're wondering how I have three disks in that tiny machine, I run two of them externally via eSATA connections that I installed myself. Any ideas ? Michael. From gate03 at landcroft.co.uk Sat Apr 25 08:17:59 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sat, 25 Apr 2015 18:17:59 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150425180311.5119405f@emeritus> References: <20150425180311.5119405f@emeritus> Message-ID: <20150425181759.6fca2714@emeritus> On Sat, 25 Apr 2015 18:03:11 +1000 Michael Mounteney wrote: > zfs destroy -r woz/$I at Z I meant zfs destroy -r rpool/$I at Z Michael. From gate03 at landcroft.co.uk Sun Apr 26 01:14:09 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sun, 26 Apr 2015 11:14:09 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150425180311.5119405f@emeritus> References: <20150425180311.5119405f@emeritus> Message-ID: <20150426111409.17962ceb@emeritus> Supplementary: 1. To revert, I booted from c2t2d0s0 then zpool replaced c2t0d0s0. That went OK. 2. The mass copying process (step 5 of TFA) died on one particular zfs filesystem, which had child systems, although it had already successfully copied another filesystem with child systems. I restarted the machine and resumed mass-copying and it again died on the same filesystem. Is it possible that the system contains features that LTS can't handle ? Surely LTS would say so ? 3. Having reverted and replaced, I then copied the offending filesystem within the same rpool, i.e.: root at world:/root# zfs snapshot -r rpool/gentoo at Z root at world:/root# nice zfs send -R rpool/gentoo at Z | nice zfs recv rpool/G2 which went alright, so the filesystem itself does not appear to be unreadable. Does the above provide any clues ? Michael. From xiaonan830818 at gmail.com Mon Apr 27 02:03:25 2015 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Mon, 27 Apr 2015 10:03:25 +0800 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> Message-ID: Hi Dan, Thanks very much for your answer! But I can't access both ms.omniti.com and http://pkg.omniti.com/omniti-ms ms.omniti.com, could you make sure they are available? Thanks very much! Best Regards Nan Xiao On Fri, Apr 24, 2015 at 10:39 PM, Dan McDonald wrote: > > > On Apr 24, 2015, at 5:43 AM, Nan Xiao wrote: > > > > Hi all, > > > > I am a newbie of OmniOS, and install OmniOS vagrant box today. I have > > the following issues about software installation package. > > > > (1) Is there any repository which provides *.pkg install package for > > OmniOS? I think it is very convenient to install software than source > > code. > > The "omnios" IPS publisher has some stuff in it. "pkg search " > can help. > > There's another publisher: ms.omniti.com, which includes compiles > packages for things OmniTI uses itself. It's not officially supported for > external users, but we sure don't mind people using packages there: > > pkg set-publisher -g http://pkg.omniti.com/omniti-ms ms.omniti.com > > You should see a whole bunch of new packages there. > > Finally, "pkgsrc" is available. Its maintainer works at Joyent, so > illumos support (which includes OmniOS) is quite good. > > > (2) Could the OmniOS vagrant box with gcc installed? Lacking of gcc is > awful. > > Two versions of gcc are available from the main "omnios" publisher. Just > utter: > > pkg install gcc48 > > pkg install gcc44 (So you can build illumos-omnios) > > and you're golden. > > Dan > > -- Best Regards Nan Xiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Apr 27 04:55:24 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 27 Apr 2015 00:55:24 -0400 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150426111409.17962ceb@emeritus> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> Message-ID: > On Apr 25, 2015, at 9:14 PM, Michael Mounteney wrote: > > Supplementary: > > 1. To revert, I booted from c2t2d0s0 then zpool replaced c2t0d0s0. > That went OK. Okay. > 2. The mass copying process (step 5 of TFA) died on one particular zfs > filesystem, which had child systems, although it had already > successfully copied another filesystem with child systems. I restarted > the machine and resumed mass-copying and it again died on the same > filesystem. Is it possible that the system contains features that LTS > can't handle ? Surely LTS would say so ? By "died" you mean the system hung? Did you have a concurrent shell running at the same time? Did that stop working? If you have a concurrent shell, it might be nice to take a system dump upon this freeze. > 3. Having reverted and replaced, I then copied the offending > filesystem within the same rpool, i.e.: > > root at world:/root# zfs snapshot -r rpool/gentoo at Z > root at world:/root# nice zfs send -R rpool/gentoo at Z | nice zfs recv rpool/G2 > > which went alright, so the filesystem itself does not appear to be > unreadable. > > Does the above provide any clues ? Where was the original zpool coming from? You mention an "upgrade" so I'm assuming it's from an earlier version of OmniOS. Can you send the snapshot to a file? It might be useful to debug the snapshot. Dan From danmcd at omniti.com Mon Apr 27 05:02:05 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 27 Apr 2015 01:02:05 -0400 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> Message-ID: <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> > On Apr 26, 2015, at 10:03 PM, Nan Xiao wrote: > > Hi Dan, > > Thanks very much for your answer! > > But I can't access both ms.omniti.com and http://pkg.omniti.com/omniti-ms ms.omniti.com, could you make sure they are available? Thanks very much! I'm pretty sure these are available. > > pkg set-publisher -g http://pkg.omniti.com/omniti-ms ms.omniti.com What did you get when you typed in the above-quoted command? Dan From xiaonan830818 at gmail.com Mon Apr 27 05:14:35 2015 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Mon, 27 Apr 2015 13:14:35 +0800 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> Message-ID: Hi Dan, I have installed the omniOS on vagrant. For some reasons, I can't configure OS to visit the internet, so let's why I want to get some out-of-box *.pkgs like Solaris. Best Regards Nan Xiao On Mon, Apr 27, 2015 at 1:02 PM, Dan McDonald wrote: > >> On Apr 26, 2015, at 10:03 PM, Nan Xiao wrote: >> >> Hi Dan, >> >> Thanks very much for your answer! >> >> But I can't access both ms.omniti.com and http://pkg.omniti.com/omniti-ms ms.omniti.com, could you make sure they are available? Thanks very much! > > I'm pretty sure these are available. > >> >> pkg set-publisher -g http://pkg.omniti.com/omniti-ms ms.omniti.com > > What did you get when you typed in the above-quoted command? > > Dan > -- Best Regards Nan Xiao From vab at bb-c.de Mon Apr 27 06:24:50 2015 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 27 Apr 2015 08:24:50 +0200 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> Message-ID: <21821.54834.173821.768752@glaurung.bb-c.de> Hello Nan! > I have installed the omniOS on vagrant. For some reasons, I can't > configure OS to visit the internet, so let's why I want to get some > out-of-box *.pkgs like Solaris. You need an internet connection to retrieve software from any publisher. If your Vagrant client cannot connect to the internet, you have to find another system that can. There, you can copy the package repository for the publisher you want, and then copy the repository via tar file or rsync to your client. As you can see, that is a bit tedious and complicated. It would be much better if you can fix your client's internet connection. Then, you can install the software you want "automatically". Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From hasslerd at gmx.li Mon Apr 27 07:01:26 2015 From: hasslerd at gmx.li (Dominik Hassler) Date: Mon, 27 Apr 2015 09:01:26 +0200 Subject: [OmniOS-discuss] Setting up KVM in a zone Message-ID: Dan, I am about to setting up my KVM's within zones. Making good progress so far. However it is not possible to add zvols as "dataset" resource as mentioned in the wiki ( http://omnios.omniti.com/wiki.php/VirtualMachinesKVM ) but as "device" resource: zonecfg> add device zonecfg> set match=/dev/zvol/rdsk/rpool/kvm-zvol zonecfg> end You might wanna fix the wiki or am I completely wrong? Kind regards Dominik From sjorge+ml at blackdot.be Mon Apr 27 07:03:42 2015 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 27 Apr 2015 09:03:42 +0200 Subject: [OmniOS-discuss] Setting up KVM in a zone In-Reply-To: References: Message-ID: <3d467c71034967ab7d73c9f0559e265c@blackdot.be> Yeah IIRC you need to add them as a device, as for the zone and qemu it's just a block device. Regards Jorge On 2015-04-27 09:01, Dominik Hassler wrote: > Dan, > > I am about to setting up my KVM's within zones. Making good progress > so far. However it is not possible to add zvols as "dataset" resource > as mentioned in the wiki ( > http://omnios.omniti.com/wiki.php/VirtualMachinesKVM ) but as "device" > resource: > > zonecfg> add device > zonecfg> set match=/dev/zvol/rdsk/rpool/kvm-zvol > zonecfg> end > > You might wanna fix the wiki or am I completely wrong? > > Kind regards > Dominik > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From natxo.asenjo at gmail.com Mon Apr 27 07:26:36 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 27 Apr 2015 09:26:36 +0200 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> Message-ID: hi, On Mon, Apr 27, 2015 at 7:14 AM, Nan Xiao wrote: > Hi Dan, > > I have installed the omniOS on vagrant. For some reasons, I can't > configure OS to visit the internet, so let's why I want to get some > out-of-box *.pkgs like Solaris. > do you have defined what your default gateway is? http://omnios.omniti.com/wiki.php/GeneralAdministration -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Mon Apr 27 07:30:35 2015 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 27 Apr 2015 09:30:35 +0200 Subject: [OmniOS-discuss] Ang: Re: Setting up KVM in a zone In-Reply-To: <3d467c71034967ab7d73c9f0559e265c@blackdot.be> References: <3d467c71034967ab7d73c9f0559e265c@blackdot.be>, Message-ID: Hi, Jorge and Dominik! I'd be very interested in adding LUN's here, as well as for the zone itself. Someone's been doing that? I've been doing it for the zone dataset before, both as a zfs dataset(from GZ pool made from LU), and from an explicit raw device from a LU. Now I would like to provide it also to the KVM VM in the zone. Rgrds Johan -----"OmniOS-discuss" skrev: ----- Till: Dominik Hassler Fr?n: Jorge Schrauwen S?nt av: "OmniOS-discuss" Datum: 2015-04-27 09:10 Kopia: omnios-discuss at lists.omniti.com ?rende: Re: [OmniOS-discuss] Setting up KVM in a zone Yeah IIRC you need to add them as a device, as for the zone and qemu it's just a block device. Regards Jorge On 2015-04-27 09:01, Dominik Hassler wrote: > Dan, > > I am about to setting up my KVM's within zones. Making good progress > so far. However it is not possible to add zvols as "dataset" resource > as mentioned in the wiki ( > http://omnios.omniti.com/wiki.php/VirtualMachinesKVM?) but as "device" > resource: > > ?zonecfg> add device > ?zonecfg> set match=/dev/zvol/rdsk/rpool/kvm-zvol > ?zonecfg> end > > You might wanna fix the wiki or am I completely wrong? > > Kind regards > Dominik > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From gate03 at landcroft.co.uk Mon Apr 27 08:16:11 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Mon, 27 Apr 2015 18:16:11 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> Message-ID: <20150427181611.0f5ec9cb@emeritus> On Mon, 27 Apr 2015 00:55:24 -0400 Dan McDonald wrote: > By "died" you mean the system hung? Did you have a concurrent shell > running at the same time? Did that stop working? If you have a > concurrent shell, it might be nice to take a system dump upon this > freeze. Pretty well. As I mentioned, pressing the power button caused a 'powerdown initiated on /dev/console' or similar (from memory) but shutdown did not proceed. I did have a ssh session open but although I could type into it, nothing happened after I pressed Enter. Nothing that required disk activity would work. > Where was the original zpool coming from? You mention an "upgrade" > so I'm assuming it's from an earlier version of OmniOS. Yes, OmniOS v11 r151013 > Can you send the snapshot to a file? It might be useful to debug the > snapshot. Do you mean a snapshot to the filesystem on which it hung? It's 69.5 GiB. In any case, as I mentioned, I could copy it once I was back on r151013, so I don't think there's anything unreadable there. Maybe some unsupported feature ? Michael. From danmcd at omniti.com Mon Apr 27 14:33:16 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 27 Apr 2015 10:33:16 -0400 Subject: [OmniOS-discuss] Setting up KVM in a zone In-Reply-To: <3d467c71034967ab7d73c9f0559e265c@blackdot.be> References: <3d467c71034967ab7d73c9f0559e265c@blackdot.be> Message-ID: <5BDFA874-6351-4E02-ABB2-30877582726C@omniti.com> > On Apr 27, 2015, at 3:03 AM, Jorge Schrauwen wrote: > > Yeah IIRC you need to add them as a device, as for the zone and qemu it's just a block device. I've updated the wiki. Thanks, Dan From lkateley at kateley.com Mon Apr 27 16:29:43 2015 From: lkateley at kateley.com (Linda Kateley) Date: Mon, 27 Apr 2015 11:29:43 -0500 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> Message-ID: <553E63F7.6010901@kateley.com> I think you need to add a dns nameserver.. I always have that problem when i load omni.. can you ping anything from the command line? #ping amazon.com linda On 4/27/15 2:26 AM, Natxo Asenjo wrote: > > hi, > > On Mon, Apr 27, 2015 at 7:14 AM, Nan Xiao > wrote: > > Hi Dan, > > I have installed the omniOS on vagrant. For some reasons, I can't > configure OS to visit the internet, so let's why I want to get some > out-of-box *.pkgs like Solaris. > > > do you have defined what your default gateway is? > > http://omnios.omniti.com/wiki.php/GeneralAdministration > > -- > regards, > natxo > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From KBruene at simmonsperrine.com Mon Apr 27 16:37:55 2015 From: KBruene at simmonsperrine.com (Kyle Bruene) Date: Mon, 27 Apr 2015 16:37:55 +0000 Subject: [OmniOS-discuss] COMSTAR vid and pid Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Hello everyone! We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom "vid" and everything worked fine, including MPIO. Now, on r151014, when we supply a custom "vid", Windows will not add the multipath. Any suggestions? Thanks, Kyle Bruene kbruene at simmonsperrine.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsmith at careyweb.com Mon Apr 27 16:59:25 2015 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 27 Apr 2015 12:59:25 -0400 Subject: [OmniOS-discuss] COMSTAR vid and pid In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Message-ID: <8954e534-e314-4c82-8c4b-586bcbd309ae@careyweb.com> What is a "vid." Can you give command/return examples? Where are you getting stuck on the multipath, in the MPIOCPL, or the multipath properties? From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Kyle Bruene Sent: Monday, April 27, 2015 12:38 PM To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] COMSTAR vid and pid Hello everyone! We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom "vid" and everything worked fine, including MPIO. Now, on r151014, when we supply a custom "vid", Windows will not add the multipath. Any suggestions? Thanks, Kyle Bruene kbruene at simmonsperrine.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Apr 27 17:15:25 2015 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 27 Apr 2015 13:15:25 -0400 Subject: [OmniOS-discuss] COMSTAR vid and pid In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Message-ID: > On Apr 27, 2015, at 12:37 PM, Kyle Bruene wrote: > > Hello everyone! > > > > We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom ?vid? and everything worked fine, including MPIO. Now, on r151014, Do you happen to know if 012 or even 010 exhibited this problem? Know that would help. Thanks, Dan From KBruene at simmonsperrine.com Mon Apr 27 17:18:01 2015 From: KBruene at simmonsperrine.com (Kyle Bruene) Date: Mon, 27 Apr 2015 17:18:01 +0000 Subject: [OmniOS-discuss] COMSTAR vid and pid In-Reply-To: References: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33ECCCFC@SPMAIL1.spae.local> I do not know about 012 or 010, however I know that 08 (6de5e81) did NOT have this issue. -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: Monday, April 27, 2015 12:15 PM To: Kyle Bruene Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] COMSTAR vid and pid > On Apr 27, 2015, at 12:37 PM, Kyle Bruene wrote: > > Hello everyone! > > > > We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom ?vid? and everything worked fine, including MPIO. Now, on r151014, Do you happen to know if 012 or even 010 exhibited this problem? Know that would help. Thanks, Dan From daleg at omniti.com Mon Apr 27 19:12:59 2015 From: daleg at omniti.com (Dale Ghent) Date: Mon, 27 Apr 2015 15:12:59 -0400 Subject: [OmniOS-discuss] COMSTAR vid and pid In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Message-ID: > On Apr 27, 2015, at 12:37 PM, Kyle Bruene wrote: > > Hello everyone! > > We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom ?vid? and everything worked fine, including MPIO. Now, on r151014, when we supply a custom ?vid?, Windows will not add the multipath. Any suggestions? Are the targets you are creating being made members of the default TPG, or are they off in their own one? /dale From KBruene at simmonsperrine.com Mon Apr 27 19:14:04 2015 From: KBruene at simmonsperrine.com (Kyle Bruene) Date: Mon, 27 Apr 2015 19:14:04 +0000 Subject: [OmniOS-discuss] COMSTAR vid and pid In-Reply-To: References: <202C92988C5CF249BD3F9F21B2B199CB33ECCCA0@SPMAIL1.spae.local> Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33ECCED9@SPMAIL1.spae.local> Default -----Original Message----- From: Dale Ghent [mailto:daleg at omniti.com] Sent: Monday, April 27, 2015 2:13 PM To: Kyle Bruene Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] COMSTAR vid and pid > On Apr 27, 2015, at 12:37 PM, Kyle Bruene wrote: > > Hello everyone! > > We have been using OmniOS to provide FC storage to our Windows 2012 Servers. On OmniOS versions previous to r151014, ie r151006, we were able to supply create-lu with a custom ?vid? and everything worked fine, including MPIO. Now, on r151014, when we supply a custom ?vid?, Windows will not add the multipath. Any suggestions? Are the targets you are creating being made members of the default TPG, or are they off in their own one? /dale From xiaonan830818 at gmail.com Tue Apr 28 02:19:13 2015 From: xiaonan830818 at gmail.com (Nan Xiao) Date: Tue, 28 Apr 2015 10:19:13 +0800 Subject: [OmniOS-discuss] Issues about OmniOS software installation package In-Reply-To: <553E63F7.6010901@kateley.com> References: <5D342235-F1E7-44E2-8264-8D199432E8A4@omniti.com> <3EB8A228-6C2B-4ED0-8BD2-D958731353CF@omniti.com> <553E63F7.6010901@kateley.com> Message-ID: Hi Dan, Volker, Natxo, Linda, Thanks very much for all your kind response!! For some security reasons and company policy, I can't open the internet connection for the OmniOS. So I am afraid I must consider some other solutions! Thanks very much for your help!! Best Regards Nan Xiao Best Regards Nan Xiao On Tue, Apr 28, 2015 at 12:29 AM, Linda Kateley wrote: > I think you need to add a dns nameserver.. I always have that problem when i > load omni.. > > can you ping anything from the command line? > > #ping amazon.com > > linda > > > On 4/27/15 2:26 AM, Natxo Asenjo wrote: > > > hi, > > On Mon, Apr 27, 2015 at 7:14 AM, Nan Xiao wrote: >> >> Hi Dan, >> >> I have installed the omniOS on vagrant. For some reasons, I can't >> configure OS to visit the internet, so let's why I want to get some >> out-of-box *.pkgs like Solaris. > > > do you have defined what your default gateway is? > > http://omnios.omniti.com/wiki.php/GeneralAdministration > > -- > regards, > natxo > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From sequoiamobil at gmx.net Tue Apr 28 12:09:40 2015 From: sequoiamobil at gmx.net (Sebastian Gabler) Date: Tue, 28 Apr 2015 14:09:40 +0200 Subject: [OmniOS-discuss] ZFS ACL Solaris CIFS and Windows client Message-ID: <553F7884.7050407@gmx.net> Hi, I am a bit stuck in getting my ACL management straight for the CIFS shares I run. What I would like to do is to set all the ACLs from Windows. What does not work right now is to assign ownership to a sharepoint or an object below it to a different user, i.e. to set ownership as the Domain Administrator to a specific user. I get an error message that a "Restore" privilege would be missing, but the error message is unclear if that applies to the current context (Domain Administrator), or the prospective owner. I can set full control for that user, however. Specifically, 1. I am wondering how to get, from my illumos machine, the privileges applicable on an object for a certain user. 2. finding out what is required to take/provide ownership, specifically of a sharepoint, from Windows, (ACLs, idmap, ZFS acl modes and inhertiance modes, etc), and in what hierarchy things apply. I am aware that this may be a FAQ, but I didn't find comprehensive documentation on the matter. The Oracle docs are focussed to explain how things work from the Solaris side, most HowTos that include the Windows side are not deep enough. Thanks for any hints. With best regards, Sebastian From cks at cs.toronto.edu Tue Apr 28 15:06:45 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 28 Apr 2015 11:06:45 -0400 Subject: [OmniOS-discuss] What should we look at in a memory exhaustion situation? Message-ID: <20150428150645.1A3477A00D8@apps0.cs.toronto.edu> We now have a reproducable situation where high NFS load can cause our specific fileserver configuration to lock up with what looks like a memory exhaustion deadlock. So far, attempts to get a crash dump haven't worked (although they may someday). Without a crash dump, what system stats and so on should we be looking at that would be useful for people to identify the kernel bugs involved here, either in the run up to the lockup or in kmdb after the fact once we break into it after the machine locks up? (Our specific fileserver is NFS to ZFS pools with mirrored vdevs where each side of the mirror is an iSCSI disk accessed over two backend iSCSI networks. We suspect that iSCSI is a contributing factor. Our fileservers have 64 GB of RAM.) So far we have vmstat, mpstat, network volume, arcstat, '::memstat' from mdb -k, and some homegrown NFS and ZFS DTrace activity monitoring scripts. These say that just before the lockup happens, free memory and ARC usage collapses abruptly and catastrophically, 'Kernel' memory usage goes to almost or totally 100%, all CPUs spike to over 90% system time, we see over a thousand runnable processes[*], and we have over a GB of in-flight NFS writes but there is very little actual ZFS (and NFS) IO either in flight or being completed. (The NFS service pool also reports a massively increasing and jaw-dropping number of 'Pending requests'; the last snapshot of '::svc_pool -v nfs' a few seconds before the crash has 376862 of them.) This seems to happen more often with lower values for the number of NFS server threads, but even very large values are not immune from it (our most recent lockup happened at 4096 threads). Slowdowns in NFS server IO responsiveness seem to make this more likely to happen; past slowdowns have come from both disk IO problems and from full or nearly full pools. Thanks in advance. - cks [*: this was with quite a lot of NFS server threads configured.] From lkateley at kateley.com Tue Apr 28 15:53:46 2015 From: lkateley at kateley.com (Linda Kateley) Date: Tue, 28 Apr 2015 10:53:46 -0500 Subject: [OmniOS-discuss] Open-ZFS Europe May 26 Paris Message-ID: <553FAD0A.3070408@kateley.com> All, I wanted to make sure everyone was aware of the Open-ZFS Europe conference in Paris on May 26th. Speakers will also be webcast. Festivities start at 8 am, Central European Summer time UTC +02 http://www.meetup.com/OpenZFS-Europe/events/218873174/ There is also an openzfs hackathon the next day May 27th. Details can also be seen from the open-zfs.org page. linda From alka at hfg-gmuend.de Tue Apr 28 17:22:34 2015 From: alka at hfg-gmuend.de (=?utf-8?Q?G=C3=BCnther_Alka?=) Date: Tue, 28 Apr 2015 19:22:34 +0200 Subject: [OmniOS-discuss] ZFS ACL Solaris CIFS and Windows client In-Reply-To: <553F7884.7050407@gmx.net> References: <553F7884.7050407@gmx.net> Message-ID: <9D064AA0-0C34-444F-9FF0-900F32EFF5B9@hfg-gmuend.de> Lets?s begin with ZFS properties - aclinhert: passthrough - aclmode: does not matter for CIFS Next, set idmappings - in Workgroup mode: do not set any user mappings (only group mappings) - in Domain mode: set domainadmins => root Next: join AD Domain (for domain mode) Next: SMB connect - use root (requires a passwd root to generate s SMB password) or - use an Domain Admin account (requires the idmapping to root) Windows version: - you need Windows Pro or Windows server (no home edition) Now you should be able to set ownership and ACL on files and folders. If you want to set ACL on shares, you must - SMB connect as a user that is a member of the Administrators group - use Computer Management on Windows and connect OmniOS Gea > Am 28.04.2015 um 14:09 schrieb Sebastian Gabler : > > Hi, > > I am a bit stuck in getting my ACL management straight for the CIFS shares I run. What I would like to do is to set all the ACLs from Windows. What does not work right now is to assign ownership to a sharepoint or an object below it to a different user, i.e. to set ownership as the Domain Administrator to a specific user. I get an error message that a "Restore" privilege would be missing, but the error message is unclear if that applies to the current context (Domain Administrator), or the prospective owner. I can set full control for that user, however. > Specifically, > 1. I am wondering how to get, from my illumos machine, the privileges applicable on an object for a certain user. > 2. finding out what is required to take/provide ownership, specifically of a sharepoint, from Windows, (ACLs, idmap, ZFS acl modes and inhertiance modes, etc), and in what hierarchy things apply. > I am aware that this may be a FAQ, but I didn't find comprehensive documentation on the matter. The Oracle docs are focussed to explain how things work from the Solaris side, most HowTos that include the Windows side are not deep enough. > > Thanks for any hints. > > With best regards, > > Sebastian > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From doug at will.to Tue Apr 28 19:08:09 2015 From: doug at will.to (Doug Hughes) Date: Tue, 28 Apr 2015 15:08:09 -0400 Subject: [OmniOS-discuss] What should we look at in a memory exhaustion situation? In-Reply-To: <20150428150645.1A3477A00D8@apps0.cs.toronto.edu> References: <20150428150645.1A3477A00D8@apps0.cs.toronto.edu> Message-ID: I've seen something similar to this in Solaris10 (that Oracle won't fix). It was diganosed as basically 'storage is too slow to service requests. Throw more hardware at it.". What happens is that nfs buffers just keep building up and building up (even if it's a read request storm) and the I/O system can't keep up with the request rate and eventually the system goes into panic/desperation swapping and then becomes totally unresponsive. You could verify if the same thing is happening by watching something like vmstat 3. Once memory starts to get around 3MB free, paging stats will climb (if it's the same issue) until numbers start showing up in 'de', and then you're dead. Anyway, it's plausible that the same thing would be possible. You could watch out for it and see if you see something similar. On Tue, Apr 28, 2015 at 11:06 AM, Chris Siebenmann wrote: > We now have a reproducable situation where high NFS load can cause our > specific fileserver configuration to lock up with what looks like a > memory exhaustion deadlock. So far, attempts to get a crash dump haven't > worked (although they may someday). Without a crash dump, what system > stats and so on should we be looking at that would be useful for people > to identify the kernel bugs involved here, either in the run up to the > lockup or in kmdb after the fact once we break into it after the machine > locks up? > > (Our specific fileserver is NFS to ZFS pools with mirrored vdevs where > each side of the mirror is an iSCSI disk accessed over two backend > iSCSI networks. We suspect that iSCSI is a contributing factor. Our > fileservers have 64 GB of RAM.) > > So far we have vmstat, mpstat, network volume, arcstat, '::memstat' > from mdb -k, and some homegrown NFS and ZFS DTrace activity monitoring > scripts. These say that just before the lockup happens, free memory and > ARC usage collapses abruptly and catastrophically, 'Kernel' memory usage > goes to almost or totally 100%, all CPUs spike to over 90% system time, > we see over a thousand runnable processes[*], and we have over a GB > of in-flight NFS writes but there is very little actual ZFS (and NFS) > IO either in flight or being completed. > > (The NFS service pool also reports a massively increasing and > jaw-dropping number of 'Pending requests'; the last snapshot of > '::svc_pool -v nfs' a few seconds before the crash has 376862 of them.) > > This seems to happen more often with lower values for the number of > NFS server threads, but even very large values are not immune from it > (our most recent lockup happened at 4096 threads). Slowdowns in NFS server > IO responsiveness seem to make this more likely to happen; past slowdowns > have come from both disk IO problems and from full or nearly full pools. > > Thanks in advance. > > - cks > [*: this was with quite a lot of NFS server threads configured.] > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valrhona at gmail.com Wed Apr 29 09:20:54 2015 From: valrhona at gmail.com (Valrhona) Date: Wed, 29 Apr 2015 05:20:54 -0400 Subject: [OmniOS-discuss] NVMe PCIe SSD support? Message-ID: Just wondering if anyone has gotten a NVMe-based PCIe SSD working with OmniOS? I just got an Intel SSD 750 PCIe drive, and it is not detected in my Dell T710 server with the "format" command, so it's not obvious how to create a zpool on it. Some recent comments suggest that it is not easy to make work: http://serverfault.com/questions/652005/nvme-driver-for-illumos-can-it-be-considered-usable FreeBSD appears to have a driver working: https://www.freebsd.org/cgi/man.cgi?query=nvme&sektion=4 Any ideas how to get this drive to work? Thanks! From danmcd at omniti.com Wed Apr 29 14:54:21 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 10:54:21 -0400 Subject: [OmniOS-discuss] NVMe PCIe SSD support? In-Reply-To: References: Message-ID: <8E87C572-06B1-46FA-A45E-3A326A9A93E8@omniti.com> > On Apr 29, 2015, at 5:20 AM, Valrhona wrote: > > Just wondering if anyone has gotten a NVMe-based PCIe SSD working with OmniOS? nvme would require its own driver. There was an attempt made to bring one up for illumos, but it failed. It would need to be a new device driver, and one that interfaced with the "blkdev" framework. It would be not unlike the sTec S112x driver, but with NVME device logic. Dan From valrhona at gmail.com Wed Apr 29 18:07:07 2015 From: valrhona at gmail.com (Valrhona) Date: Wed, 29 Apr 2015 14:07:07 -0400 Subject: [OmniOS-discuss] NVMe PCIe SSD support? In-Reply-To: <8E87C572-06B1-46FA-A45E-3A326A9A93E8@omniti.com> References: <8E87C572-06B1-46FA-A45E-3A326A9A93E8@omniti.com> Message-ID: Does anyone have any plans to make this driver work? Going forward, NVMe SSDs seem to be likely to grow in importance and prevalence, and it seems like a good idea for Illumos to get this working, since FreeBSD, Linux and Mac already support it. On Wed, Apr 29, 2015 at 10:54 AM, Dan McDonald wrote: > >> On Apr 29, 2015, at 5:20 AM, Valrhona wrote: >> >> Just wondering if anyone has gotten a NVMe-based PCIe SSD working with OmniOS? > > nvme would require its own driver. > > There was an attempt made to bring one up for illumos, but it failed. It would need to be a new device driver, and one that interfaced with the "blkdev" framework. It would be not unlike the sTec S112x driver, but with NVME device logic. > > Dan > From danmcd at omniti.com Wed Apr 29 18:10:10 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 14:10:10 -0400 Subject: [OmniOS-discuss] NVMe PCIe SSD support? In-Reply-To: References: <8E87C572-06B1-46FA-A45E-3A326A9A93E8@omniti.com> Message-ID: > On Apr 29, 2015, at 2:07 PM, Valrhona wrote: > > Does anyone have any plans to make this driver work? Going forward, > NVMe SSDs seem to be likely to grow in importance and prevalence, and > it seems like a good idea for Illumos to get this working, since > FreeBSD, Linux and Mac already support it. Agreed it's a good idea. You should ask this question in the illumos community. Dan From gate03 at landcroft.co.uk Wed Apr 29 19:13:07 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Thu, 30 Apr 2015 05:13:07 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150427181611.0f5ec9cb@emeritus> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> Message-ID: <20150430051307.2eecf93e@emeritus> On Mon, 27 Apr 2015 18:16:11 +1000 Michael Mounteney wrote: Can anyone help on this one ? if not, is there any information about when a kernel or ZFS update might be rolled in to r151014 ? Michael. From cks at cs.toronto.edu Wed Apr 29 19:21:03 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Wed, 29 Apr 2015 15:21:03 -0400 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? Message-ID: <20150429192103.D6B397A0605@apps0.cs.toronto.edu> We have a filesystem/dataset with no snapshots, no subordinate filesystems, nothing complicated (and no compression), that has a drastic difference in space used between what df/zfs list/etc report at the ZFS level and what du reports at the filesystem level. ZFS says NAME PROPERTY VALUE SOURCE fs0-core-01/cs/8 used 70.5G - fs0-core-01/cs/8 usedbydataset 70.5G - On the other hand, 'du -h' says 17 GB, which is what we'd expect. More alarmingly, this dataset seems to keep steadily growing at the ZFS level despite 'du -h' figures staying constant or even going down. On April 2nd it was reporting a 'du -h' of 22 GB but 48 GB used at the ZFS level; as you can see, it's added 22 GB of ZFS usage in less than a month while losing 5 GB at the user level. What sort of things should I be looking at to try to figure out why this is happening, including with eg zdb? Are there any obvious reasons why this would be happening? Is there any easy way to fix this short of 'copy all data to a new dataset, destroy old dataset, put new dataset in the place of the old?' (The entire pool is on mirrored vdevs and has ashift=12. And looking at it two other datasets in this pool have similar issues, although neither are as drastically divergent; one is 360 GB vs 302 GB, another is 28.8 GB vs 20 GB.) Thanks in advance. - cks From danmcd at omniti.com Wed Apr 29 19:23:06 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 15:23:06 -0400 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150427181611.0f5ec9cb@emeritus> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> Message-ID: > On Apr 27, 2015, at 4:16 AM, Michael Mounteney wrote: > > >> Can you send the snapshot to a file? It might be useful to debug the >> snapshot. > > Do you mean a snapshot to the filesystem on which it hung? It's 69.5 > GiB. In any case, as I mentioned, I could copy it once I was back on > r151013, so I don't think there's anything unreadable there. Maybe > some unsupported feature ? If you can send the snapshot to a file (doesn't matter where) using '014, then the bug is more likely to be in the receive code instead of the send code. You're piping, so you were exercising both send and receive. I asked in an attempt to narrow the problem down. Dan From danmcd at omniti.com Wed Apr 29 19:35:15 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 15:35:15 -0400 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150430051307.2eecf93e@emeritus> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> <20150430051307.2eecf93e@emeritus> Message-ID: <3737EC6D-7A11-427F-88FB-CA9A20E0F3F2@omniti.com> > On Apr 29, 2015, at 3:13 PM, Michael Mounteney wrote: > > On Mon, 27 Apr 2015 18:16:11 +1000 > Michael Mounteney wrote: > > Can anyone help on this one ? if not, is there any information about > when a kernel or ZFS update might be rolled in to r151014 ? If you are updated to omnios-170cea2, some ZFS fixes came in with that. There are only four more ZFS changes after what you have in the latest '014. It doesn't look like you're receiving from a version 1 (yes 1) pool, nor are you triggering any actual panics. Here are the four additional changes not in '014: commit f40b29ce2a815bcc0787acf6f520a2b74258b785 Author: Paul Dagnelie Date: Sun Apr 26 15:26:13 2015 -0700 5809 Blowaway full receive in v1 pool causes kernel panic Reviewed by: Matthew Ahrens Reviewed by: Alex Reece Reviewed by: Will Andrews Approved by: Gordon Ross usr/src/uts/common/fs/zfs/dmu_send.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) commit 732885fca09e11183dd0ea69aaaab5588fb7dbff Author: Matthew Ahrens Date: Sun Apr 26 15:27:36 2015 -0700 5810 zdb should print details of bpobj Reviewed by: Prakash Surya Reviewed by: Alex Reece Reviewed by: George Wilson Reviewed by: Will Andrews Reviewed by: Simon Klinkert Approved by: Gordon Ross usr/src/cmd/zdb/zdb.c | 97 +++++++++++++++++++++++++++++++---- usr/src/uts/common/fs/zfs/bpobj.c | 5 +- usr/src/uts/common/fs/zfs/sys/bpobj.h | 3 +- 3 files changed, 90 insertions(+), 15 deletions(-) commit 8df173054ca442cd8845a7364c3edad9d6822351 Author: Matthew Ahrens Date: Sun Apr 26 15:29:43 2015 -0700 5812 assertion failed in zrl_tryenter(): zr_owner==NULL Reviewed by: George Wilson Reviewed by: Alex Reece Reviewed by: Will Andrews Approved by: Gordon Ross usr/src/uts/common/fs/zfs/zrlock.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) commit b67dde11a73a9455d641403cbbb65ec2add41b41 Author: Will Andrews Date: Sun Apr 26 15:30:46 2015 -0700 5814 bpobj_iterate_impl(): Close a refcount leak iterating on a sublist. Reviewed by: Prakash Surya Reviewed by: Matthew Ahrens Reviewed by: Paul Dagnelie Reviewed by: Simon Klinkert Approved by: Gordon Ross usr/src/uts/common/fs/zfs/bpobj.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Dan From danmcd at omniti.com Wed Apr 29 19:51:18 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 15:51:18 -0400 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: <20150429192103.D6B397A0605@apps0.cs.toronto.edu> References: <20150429192103.D6B397A0605@apps0.cs.toronto.edu> Message-ID: <4C72F972-CB61-4F54-BAE8-C2C5F5825796@omniti.com> > On Apr 29, 2015, at 3:21 PM, Chris Siebenmann wrote: > > We have a filesystem/dataset with no snapshots, You're sure about no snapshots? "zfs list -t snapshot" has surprised me once or twice in the past. :-/ > no subordinate > filesystems, nothing complicated (and no compression), that has a > drastic difference in space used between what df/zfs list/etc report at > the ZFS level and what du reports at the filesystem level. ZFS says > > NAME PROPERTY VALUE SOURCE > fs0-core-01/cs/8 used 70.5G - > fs0-core-01/cs/8 usedbydataset 70.5G - > > On the other hand, 'du -h' says 17 GB, which is what we'd expect. > More alarmingly, this dataset seems to keep steadily growing at the > ZFS level despite 'du -h' figures staying constant or even going down. > On April 2nd it was reporting a 'du -h' of 22 GB but 48 GB used at the > ZFS level; as you can see, it's added 22 GB of ZFS usage in less than > a month while losing 5 GB at the user level. This almost sounds like there's a process with an open file, which was removed, but the process in question still has it open. pfiles(1) on your processes may be very helpful here. > What sort of things should I be looking at to try to figure out why > this is happening, including with eg zdb? Are there any obvious reasons > why this would be happening? Is there any easy way to fix this short of > 'copy all data to a new dataset, destroy old dataset, put new dataset > in the place of the old?' I take it that a reboot of this machine (which would kill any processes with an open-but-deleted file) has already been done? Dan From cks at cs.toronto.edu Wed Apr 29 20:00:34 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Wed, 29 Apr 2015 16:00:34 -0400 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: danmcd's message of Wed, 29 Apr 2015 15:51:18 -0400. <4C72F972-CB61-4F54-BAE8-C2C5F5825796@omniti.com> Message-ID: <20150429200034.78A497A0735@apps0.cs.toronto.edu> > > On Apr 29, 2015, at 3:21 PM, Chris Siebenmann wrote: > > > > We have a filesystem/dataset with no snapshots, > > You're sure about no snapshots? "zfs list -t snapshot" has surprised > me once or twice in the past. :-/ Completely sure. 'zfs list -t snapshot' has nothing and all of the usedby* figures for anything except 'usedbydataset' are 0; no space used by snapshots, children, or refreservation. I forgot to mention: this is an NFS server with no local processes. So if there's any deleted files being held open by user processes on client machines, they should be being held open via NFS '.nfs*' silly-rename files. fuser says nothing on the fileserver is using anything (which is what I'd expect). > > What sort of things should I be looking at to try to figure out why > > this is happening, including with eg zdb? Are there any obvious > > reasons why this would be happening? Is there any easy way to fix > > this short of 'copy all data to a new dataset, destroy old dataset, > > put new dataset in the place of the old?' > > I take it that a reboot of this machine (which would kill any > processes with an open-but-deleted file) has already been done? A reboot of the machine hasn't been done because it would have a very high user impact (this fileserver holds several of our most crucial core filesystems) and so far there's no sign that a reboot would fix things (eg by forcing some process to die and relinquish an open file). Here I need to cough, shuffle my feet, and admit that this machine is running r151010, not r151014, and may not be running the very latest r151010 kernel at that. Are there any potentially relevant bug fixes in ZFS (or NFS) between r151010 and r151014? - cks From henson at acm.org Wed Apr 29 20:12:19 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 29 Apr 2015 13:12:19 -0700 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: <20150429192103.D6B397A0605@apps0.cs.toronto.edu> References: <20150429192103.D6B397A0605@apps0.cs.toronto.edu> Message-ID: <05b101d082b8$cd3e7440$67bb5cc0$@acm.org> > From: Chris Siebenmann > Sent: Wednesday, April 29, 2015 12:21 PM > > ZFS level; as you can see, it's added 22 GB of ZFS usage in less than > a month while losing 5 GB at the user level. There was a thread late last year on the developer list that described similar symptoms: http://lists.open-zfs.org/pipermail/developer/2014-October/000887.html Have you by any chance done zfs recv into this filesystem, and then further have the async_destroy feature enabled? If so, you could possibly be hitting this issue. zdb -bb on the pool would show an increasing amount of deferred frees over time. I see from a more recent message you're running a rather ancient kernel, so you might not even have this feature. But it feels like we are in the throw darts at the wall stage of problem solving ATM, so here you go :), good luck. From cks at cs.toronto.edu Wed Apr 29 20:23:27 2015 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Wed, 29 Apr 2015 16:23:27 -0400 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: Your message of Wed, 29 Apr 2015 13:12:19 -0700. <05b101d082b8$cd3e7440$67bb5cc0$@acm.org> Message-ID: <20150429202327.682747A0735@apps0.cs.toronto.edu> > > From: Chris Siebenmann > > [...] ZFS level; as you can see, it's added 22 GB of ZFS usage in > > less than a month while losing 5 GB at the user level. > > There was a thread late last year on the developer list that described > similar symptoms: > > http://lists.open-zfs.org/pipermail/developer/2014-October/000887.html > > Have you by any chance done zfs recv into this filesystem, and then > further have the async_destroy feature enabled? If so, you could > possibly be hitting this issue. zdb -bb on the pool would show an > increasing amount of deferred frees over time. We have done 'zfs recv' into this filesystem (and all of the other ones; they were all migrated from our old Solaris fileservers to our new OmniOS ones). However I just ran 'zdb -bb' and it kind of suggests we aren't seeing this: Blocks LSIZE PSIZE ASIZE avg comp %Total Type [...] 30 346K 62.5K 372K 12.4K 5.54 0.00 deferred free In general, nothing in 'zdb -bb's list of types is over a GB in LSIZE or PSIZE except 'ZFS plain file'. (On the other hand, maybe 'deferred free' is not blocks that are going to be freed but instead blocks serving as indexes to etc, in which case this might be a significant number. I don't have data from anything else to cross-check against.) - cks From danmcd at omniti.com Wed Apr 29 20:25:44 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 16:25:44 -0400 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: <20150429200034.78A497A0735@apps0.cs.toronto.edu> References: <20150429200034.78A497A0735@apps0.cs.toronto.edu> Message-ID: <379F03D9-6E50-4C38-ABCF-25699EE2C328@omniti.com> > On Apr 29, 2015, at 4:00 PM, Chris Siebenmann wrote: > > Here I need to cough, shuffle my feet, and admit that this machine is > running r151010, not r151014, and may not be running the very latest > r151010 kernel at that. Are there any potentially relevant bug fixes > in ZFS (or NFS) between r151010 and r151014? There are lots of fixes in both between 010 and 014. Whether or not they are *relevant* would involve a lot of eyestrain over the output of "git whatchanged origin/r151010.." in an checked-out r151014 branch. Dan From gate03 at landcroft.co.uk Wed Apr 29 20:40:07 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Thu, 30 Apr 2015 06:40:07 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <3737EC6D-7A11-427F-88FB-CA9A20E0F3F2@omniti.com> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> <20150430051307.2eecf93e@emeritus> <3737EC6D-7A11-427F-88FB-CA9A20E0F3F2@omniti.com> Message-ID: <20150430064007.604c24fa@emeritus> On Wed, 29 Apr 2015 15:35:15 -0400 Dan McDonald wrote: > > > On Apr 29, 2015, at 3:13 PM, Michael Mounteney > > wrote: > > > > On Mon, 27 Apr 2015 18:16:11 +1000 > > Michael Mounteney wrote: > > > > Can anyone help on this one ? if not, is there any information > > about when a kernel or ZFS update might be rolled in to r151014 ? > > If you are updated to omnios-170cea2, some ZFS fixes came in with > that. There are only four more ZFS changes after what you have in > the latest '014. It doesn't look like you're receiving from a > version 1 (yes 1) pool, nor are you triggering any actual panics. I'm on omnios-eb4c8f3 currently. /etc/release has r151013. That's right; no panics; all disk activity just stops. > Here are the four additional changes not in '014: > > [...] > > 5809 Blowaway full receive in v1 pool causes kernel panic That one looks worth waiting for. Any idea when it (and the other three presumably) will find their way into r151014 ? And when they do, is there any way I can find out what's going wrong, if the problem is still present ? Presumably dtrace it. Uh oh, another technology to learn. Thanks for your help on this Dan. Michael. From gate03 at landcroft.co.uk Wed Apr 29 20:40:25 2015 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Thu, 30 Apr 2015 06:40:25 +1000 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> Message-ID: <20150430064025.66a34d43@emeritus> On Wed, 29 Apr 2015 15:23:06 -0400 Dan McDonald wrote: > If you can send the snapshot to a file (doesn't matter where) using > '014, then the bug is more likely to be in the receive code instead > of the send code. You're piping, so you were exercising both send and > receive. I asked in an attempt to narrow the problem down. Just goes to show how easily misunderstandings can arise. I thought you meant "send it to us for analysis". Hence my 69.5 GiB comment. Michael. From danmcd at omniti.com Wed Apr 29 21:01:07 2015 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 29 Apr 2015 17:01:07 -0400 Subject: [OmniOS-discuss] LTS just comes to a halt doing mass-copy In-Reply-To: <20150430064007.604c24fa@emeritus> References: <20150425180311.5119405f@emeritus> <20150426111409.17962ceb@emeritus> <20150427181611.0f5ec9cb@emeritus> <20150430051307.2eecf93e@emeritus> <3737EC6D-7A11-427F-88FB-CA9A20E0F3F2@omniti.com> <20150430064007.604c24fa@emeritus> Message-ID: > On Apr 29, 2015, at 4:40 PM, Michael Mounteney wrote: > > On Wed, 29 Apr 2015 15:35:15 -0400 > Dan McDonald wrote: > >> >>> On Apr 29, 2015, at 3:13 PM, Michael Mounteney >>> wrote: >>> >>> On Mon, 27 Apr 2015 18:16:11 +1000 >>> Michael Mounteney wrote: >>> >>> Can anyone help on this one ? if not, is there any information >>> about when a kernel or ZFS update might be rolled in to r151014 ? >> >> If you are updated to omnios-170cea2, some ZFS fixes came in with >> that. There are only four more ZFS changes after what you have in >> the latest '014. It doesn't look like you're receiving from a >> version 1 (yes 1) pool, nor are you triggering any actual panics. > > I'm on omnios-eb4c8f3 currently. /etc/release has r151013. That's > right; no panics; all disk activity just stops. I thought you were having a problem in 014, and NOT having one in '013. I'm confused now. >> 5809 Blowaway full receive in v1 pool causes kernel panic > > That one looks worth waiting for. Any idea when it (and the other > three presumably) will find their way into r151014 ? If they are all indeed localized to ZFS (I'll need to check) it could happen sooner rather than later. I've uttered kernel updates for 006 in the past that weren't complete (not all modules updated) which caused more problems than it fixed. I need to be cautious with any backports (especially those which require reboots). > And when they do, is there any way I can find out what's going wrong, > if the problem is still present ? Presumably dtrace it. Uh oh, > another technology to learn. > > Thanks for your help on this Dan. Sorry I can't be of more immediate assistance, Dan From henson at acm.org Wed Apr 29 21:32:46 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 29 Apr 2015 14:32:46 -0700 Subject: [OmniOS-discuss] Clues for tracking down a drastic ZFS fs space difference? In-Reply-To: <20150429202327.682747A0735@apps0.cs.toronto.edu> References: <05b101d082b8$cd3e7440$67bb5cc0$@acm.org> <20150429202327.682747A0735@apps0.cs.toronto.edu> Message-ID: <20150429213246.GC19246@bender.unx.cpp.edu> On Wed, Apr 29, 2015 at 04:23:27PM -0400, Chris Siebenmann wrote: > (On the other hand, maybe 'deferred free' is not blocks that are going > to be freed but instead blocks serving as indexes to etc, in which case > this might be a significant number. I don't have data from anything > else to cross-check against.) Not sure; you could ask on the zfs developer list, but their first response will probably be to update to a more current system :). Here's zdb output from one of my production pools that's not misbehaving. It's a backup for another box so it pretty much gets zfs recv all day and it has async destroy enabled: Blocks LSIZE PSIZE ASIZE avg comp %Total Type 4.55K 60.9M 30.1M 90.3M 19.8K 2.02 0.39 deferred free FWIW :). From sequoiamobil at gmx.net Thu Apr 30 06:56:21 2015 From: sequoiamobil at gmx.net (Sebastian Gabler) Date: Thu, 30 Apr 2015 08:56:21 +0200 Subject: [OmniOS-discuss] ZFS ACL Solaris CIFS and Windows client In-Reply-To: References: Message-ID: <5541D215.2020603@gmx.net> Am 29.04.2015 um 20:07 schrieb omnios-discuss-request at lists.omniti.com: > Message: 3 > Date: Tue, 28 Apr 2015 19:22:34 +0200 > From: G?nther Alka > To: omnios-discuss > Subject: Re: [OmniOS-discuss] ZFS ACL Solaris CIFS and Windows client > Message-ID: <9D064AA0-0C34-444F-9FF0-900F32EFF5B9 at hfg-gmuend.de> > Content-Type: text/plain; charset=utf-8 > > Lets?s begin with ZFS properties > - aclinhert: passthrough Thanks. It was on "restricted". I applied the change, but that makes no difference to my original problem. > - aclmode: does not matter for CIFS Thanks. Do you have any sources for that for futher studies? > > Next, set idmappings > - in Workgroup mode: do not set any user mappings (only group mappings) > - in Domain mode: set domainadmins => root That's already the case. On that occasion: how would one delegate operator permissions for ACL assignment to other users. i.e. if I want certain Domain Users to change ACLs, permissions, and privileges, on shares of the illumos machine, who are not member of the domain admin group? > > Next: join AD Domain (for domain mode) > > Next: SMB connect > - use root (requires a passwd root to generate s SMB password) or > - use an Domain Admin account (requires the idmapping to root) I am using the domain admin account. Note: what specifically is not working is to set ownership on behalf of a different domain user. > > Windows version: > - you need Windows Pro or Windows server (no home edition) Known. > > Now you should be able to set ownership and ACL on files and folders. > > If you want to set ACL on shares, you must > - SMB connect as a user that is a member of the Administrators group > - use Computer Management on Windows and connect OmniOS Trying the latter ends up in "access denied". Maybe there is something broken with the user mapping. (i.e., the domain admin >root mapping was done, but how do I check if it is in effect, how do I check if root (who is in my understanding the provider of the permissions to domain admin, right?) has the required privs? > > > Gea > > >> Am 28.04.2015 um 14:09 schrieb Sebastian Gabler : >> >> Hi, >> >> I am a bit stuck in getting my ACL management straight for the CIFS shares I run. What I would like to do is to set all the ACLs from Windows. What does not work right now is to assign ownership to a sharepoint or an object below it to a different user, i.e. to set ownership as the Domain Administrator to a specific user. I get an error message that a "Restore" privilege would be missing, but the error message is unclear if that applies to the current context (Domain Administrator), or the prospective owner. I can set full control for that user, however. >> Specifically, >> 1. I am wondering how to get, from my illumos machine, the privileges applicable on an object for a certain user. >> 2. finding out what is required to take/provide ownership, specifically of a sharepoint, from Windows, (ACLs, idmap, ZFS acl modes and inhertiance modes, etc), and in what hierarchy things apply. >> I am aware that this may be a FAQ, but I didn't find comprehensive documentation on the matter. The Oracle docs are focussed to explain how things work from the Solaris side, most HowTos that include the Windows side are not deep enough. >> >> Thanks for any hints. >> >> With best regards, >> >> Sebastian >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > From danmcd at omniti.com Thu Apr 30 20:21:37 2015 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 30 Apr 2015 16:21:37 -0400 Subject: [OmniOS-discuss] Yet-another cURL fix Message-ID: <84C13D3F-58B3-4EF6-8976-FEE85ADDCF7D@omniti.com> Curl's up to 7.42.1 now. So are the supported repos (006, 012, and 014). Bloody will get updated the next time I update bloody. Happy curl-updating! Dan