Switch to DuckDuckGo Search
   March 22, 2013  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >

bottom
[00:01:02] *** CarlosC has quit IRC
[00:02:08] *** gkyildirim has left #smartos
[00:03:26] *** CarlosC has joined #smartos
[00:03:41] *** szaydel has joined #smartos
[00:06:50] *** emocakes has joined #smartos
[00:08:30] *** scarcry has quit IRC
[00:09:06] *** Xenith has quit IRC
[00:09:32] *** scarcry has joined #smartos
[00:10:27] *** Xenith has joined #smartos
[00:14:26] *** enmand has quit IRC
[00:22:00] *** szaydel has quit IRC
[00:24:10] *** tonyarkles has joined #smartos
[00:38:46] *** szaydel has joined #smartos
[00:51:13] *** szaydel has quit IRC
[00:55:28] *** enmand has joined #smartos
[00:58:08] *** szaydel has joined #smartos
[00:58:56] *** mrj has quit IRC
[01:10:42] *** dysinger has quit IRC
[01:12:36] *** szaydel has quit IRC
[01:25:15] *** dysinger has joined #smartos
[01:26:17] <ira> Anyone seeing odd build issues around perl and cw nori knowing what to do with -fPIC?
[01:26:43] <wesolows> someone mentioned something like this on the mailing list, I think
[01:27:56] <ira> Ok.. so there's some regression.  Oddly, I built this code not too long ago.  So there's something odd here.
[01:28:13] <wesolows> the problem is that no one here is seeing it
[01:28:25] <wesolows> so it comes down to figuring out what's different
[01:28:46] <ira> (nod) I'm trying to figure out what is going on… I don
[01:28:55] <ira> 't know if you can even get that error off timing.
[01:29:13] <wesolows> well, it's obvious that some gcc flag is being passed to cw
[01:29:31] <wesolows> which suggests pollution, since cw takes only Studio flags
[01:30:27] *** CarlosC has quit IRC
[01:31:32] <ira> Ok...
[01:36:37] <ira> Exact same error.
[01:37:47] *** leecallen has quit IRC
[01:39:36] *** porkbelt has quit IRC
[01:39:49] *** leecallen has joined #smartos
[01:40:31] <wesolows> it's conceivable that it's caused by a change in the platform on the build system, since the build machine I think most people here use has one from 20130111.
[01:40:42] <wesolows> that's a bit more stale than usual
[01:40:54] <ira> Interesting...
[01:41:01] <ira> I did upgrade that host..
[01:41:21] <ira> (to absolute latest bits.)
[01:41:26] *** porkbelt has joined #smartos
[01:41:41] <ira> I can't downgrade it right now… :/
[01:41:42] <nahamu> When this weeks release comes out I can try to find a time to upgrade my home machine and run a full build from scratch.
[01:43:15] <ira> Now that you say it… It makes sense… the question is… what regressed or progressed ;)
[01:45:28] <ira> Found it…
[01:45:35] <ira> I think… I'll see if I can fix it.
[01:45:58] <ira> (at least it looks exactly like what I am looking for… X_x.)
[01:46:26] <ira> https://github.com/joyent/illumos-extra/commit/b9cadd24a396e17d238f395c56a36aa3fa0c1cef ; Could do it?
[01:51:00] <ira> It should be in your base also...
[01:51:12] <ira> No… 0111.. you'd miss it.
[01:51:32] *** szaydel has joined #smartos
[01:56:15] <ira> wesolows: What damage would I do reverting the -fPIC to -KPIC?
[01:59:50] *** tonyarkles has quit IRC
[02:02:22] *** ryancnelson has quit IRC
[02:07:59] *** dap has quit IRC
[02:08:30] <wesolows> ira: if you can find the place that's setting the flag, you can figure out the bug.
[02:08:50] <ira> :ok.
[02:09:00] <wesolows> and yeah, fixing that seems like the right answer
[02:09:04] <wesolows> that's my fault :-(
[02:09:13] <wesolows> but... how did this work for me?!
[02:09:24] <ira> It has to be coming off the platform.
[02:09:32] <ira> Which is really screwy.
[02:09:40] <wesolows> no, this is still broken.  If we are using the platform stuff to decide how to build perl, that's a bug
[02:10:07] <wesolows> I deliberately set this to -fPIC because people using gcc to build perl add-on modules will want that
[02:10:18] <ira> I agree 100%.  But I know I built this code last night… before I upgraded....
[02:10:26] <wesolows> oh I don't doubt that's what broke it
[02:10:42] <wesolows> but if the platform's config.pm is being used here, that's a much more serious bug than the build being broken
[02:10:47] <ira> Alas, I have things running on the machine… I can make a build zone on another machine, import my code, and see if I can get a build off.
[02:10:57] <wesolows> you can obviously change that on the running system and presumably get a build, but it's still busted
[02:11:12] <ira> Agreed.
[02:12:16] <ira> And it is a catch 22, when I thought about it.  If the flags used in the compile get baked in… You've got 2 sets of flags that differ.
[02:12:53] <wesolows> That's why we have Config_heavy vs config.over
[02:13:03] <wesolows> one is supposed to be used at build time, the other is installed for consumers
[02:13:15] <wesolows> of course, no one is supposed to be building stuff against the platform perl anyway, really.
[02:13:38] <wesolows> everyone should be using the pkgsrc one
[02:14:07] <wesolows> Most likely this is just another way in which perl does not know how to be cross-compiled.
[02:14:18] <wesolows> i.e., to isolate itself from what's on the build machine
[02:16:44] *** chorrell has quit IRC
[02:21:28] <ira> wesolows: Seems likely… though I'm wondering when we'll stop hurting ourselves with studio :)
[02:25:24] <nahamu> ira / wesolows let me know if there's anything useful I can do to help untangle that stuff.
[02:27:23] *** wolfeidau has quit IRC
[02:27:45] *** wolfeidau has joined #smartos
[02:29:15] *** alpharender has joined #smartos
[02:29:35] *** sebasp has joined #smartos
[02:31:55] *** axonpoet has quit IRC
[02:33:32] <ira> wesolows
[02:33:51] <ira> wesolows: The thought I'm having is build perl twice… Which is just gross.
[02:34:39] <ira> Once with the flags for the build and rooted to proto.strap… then the real one for the platform like you currently do...
[02:35:57] <ira> (I'm not sure that works with it being the platform perl… Because it must end up with one set of flags…)
[02:43:40] *** cmang has joined #smartos
[02:47:23] <cmang> howdy, y'all
[02:53:10] *** khushildep has quit IRC
[02:56:07] *** szaydel has quit IRC
[03:17:18] *** dysinger has quit IRC
[03:18:36] *** dysinger has joined #smartos
[03:34:02] *** denizr has joined #smartos
[03:36:29] *** miine_ has joined #smartos
[03:36:47] *** miine_ has joined #smartos
[03:38:39] *** miine has quit IRC
[03:38:39] *** miine_ is now known as miine
[03:39:05] *** denizr has quit IRC
[03:43:38] <Licenser> hmm how much work is kstat for the kernel?
[03:43:58] <ira> wesolows, nahamu: Well, I've established that's the cause, and that a file put in the fake-subset fixes it.
[03:44:13] <wesolows> ira: ok.  so, back to the drawing board then. :-(
[03:44:15] <ira> (Or at least gets me past the break...)
[03:44:25] <ira> wesolows: Can you set a path?
[03:44:26] <Licenser> I am running 3 kstat requests every second for stat gathering and VMWare's load goes up to 50% of (1 core half used) which already is pretty much when it's usually <10% when ideling
[03:44:35] <wesolows> it's absolutely critical that we not use what's in the build system to feed the build process
[03:45:14] <ira> Absolutely…. But perl may make that very difficult/impossible unless you build a special build perl...
[03:45:23] <wesolows> ira: that's really not good enough.  The proto.strap idea is intriguing, but ultimately we know that perl can build on a system that doesn't have perl.  So it needs to be able to build on a system that does, exactly as it would if it didn't.
[03:45:47] <wesolows> I'll poke at this next week, most likely.
[03:45:59] <wesolows> my preference, frankly, is to rip out perl entirely
[03:46:09] * jesse_ seconds that
[03:46:12] <wesolows> but I think there are still a couple of things in ON that are using it
[03:46:19] <ira> As long as I have a way to get Solaris::Kstat, I'm ok :)
[03:46:45] <wesolows> "Sorry, Larry; come back when you have a sane build system"
[03:47:30] <Licenser> heh
[03:48:17] <ira> wesolows: I suspect setting a path of where to pick up this file… would work here, and break the circle.
[03:49:49] <wesolows> if we could set that path to null, that might be ok
[03:50:07] <wesolows> CONFIG_PM_PATH_FROM_BUILD_SYSTEM_POLLUTE_ME_PLEASE=/dev/null
[03:50:15] <ira> You need to pickup the file to actually know what settings to build with… :/
[03:50:47] <wesolows> we shouldn't.  that's what config.over is for, or at least that's the intent
[03:51:11] <wesolows> as I said, I need to spend more time on this apparently.  more fucking spaghetti bullshit insane code to try to understand
[03:51:17] <wesolows> this week I won't have time.
[03:51:59] <ira> no problem… Thanks for your help working around it.
[03:51:59] <wesolows> if you can unwind it, and figure out how to make sure we don't use anything from the build system, I would be very happy to integrate whatever you come up with though!
[03:53:32] <ira> If I have an idea, I'll work it. :)
[03:57:53] *** ira has quit IRC
[04:15:01] *** avrntsv has quit IRC
[04:20:22] *** Daemonik has joined #smartos
[04:31:40] *** xmerlin has quit IRC
[04:32:46] *** szaydel has joined #smartos
[04:33:22] *** Daemonik has quit IRC
[04:47:38] *** szaydel has quit IRC
[04:53:17] *** nefilim has quit IRC
[04:54:34] *** nefilim has joined #smartos
[04:57:00] *** nefilim has joined #smartos
[05:00:55] *** emocakes has quit IRC
[05:30:37] *** dysinger has quit IRC
[05:35:55] *** sachinsharma has joined #smartos
[05:36:24] <rmustacc> Licenser: kstat shouldn't be that bad, but you may want to use libkstat itself as opposed to the command line interface.
[05:36:43] <Licenser> hmm that isn't a bad idae
[05:36:45] <Licenser> :)
[05:37:22] <rmustacc> Basically what happens is that when you use kstats, you take a snapshot of the current state and iterate over it.
[05:37:36] <rmustacc> Taking a snapshot can be a little expensive.
[05:37:56] <rmustacc> But ideally you can gather all the information you want from one snapshot.
[05:38:36] *** enmand has quit IRC
[05:38:59] <Licenser> makes sense
[05:40:06] *** avrntsv has joined #smartos
[05:40:22] <Licenser> thanks rmustacc !
[05:41:04] <rmustacc> Sure.
[05:41:33] <rmustacc> While I'm sure you want the equivalent in erlang, an example of interfacing with libkstat from another language is: https://github.com/bcantrill/node-kstat
[05:45:11] <Licenser> ^^
[05:46:05] <Licenser> I'm never shy to write it myself if it doesn't exist yet :) just means I get the chacne to learn new stuff
[05:48:57] *** alpharender has quit IRC
[06:11:17] *** leecallen has quit IRC
[06:11:42] *** leecallen has joined #smartos
[06:39:20] *** nefilim has quit IRC
[07:55:54] *** ChrisPartridge has quit IRC
[08:01:53] *** bluezenix has joined #smartos
[08:21:06] *** texarcana has quit IRC
[08:22:18] *** texarcana has joined #smartos
[08:28:19] *** bluezenix has quit IRC
[08:30:33] *** Cpt-Oblivious is now known as Cpt-Oblivious|af
[08:42:37] *** alucardX has joined #smartos
[08:42:46] <alucardX> morning
[08:52:20] *** bens1 has joined #smartos
[09:08:41] *** bluezenix has joined #smartos
[09:18:07] *** alcir has joined #smartos
[09:30:00] *** ktkNA is now known as ktk
[09:31:30] *** ivan\ has quit IRC
[09:32:29] *** ivan\ has joined #smartos
[10:02:39] *** theup has joined #smartos
[10:02:44] *** khushildep has joined #smartos
[10:04:32] <theup> Hello everyone. I 'm having trouble accessing KVM machines via VNC. vmadm info <uid> returns nothing, and even when setting a vncport manually I can't get a connection. Does anyone have some insight on this?
[10:05:18] *** kaladis has quit IRC
[10:06:42] <ktk> theup: what does vmadm list say?
[10:07:16] <theup> [root@00-1e-67-6f-91-47 /var/machines]# vmadm list
[10:07:16] <theup> UUID                                  TYPE  RAM      STATE             ALIAS
[10:07:16] <theup> 767765ba-0ad8-4f84-abbb-6a2a3c5f0053  KVM   1024     running           -
[10:07:16] <theup> 759a958f-d34f-4ad4-b331-207049ff87dd  OS    2048     running           central
[10:07:16] <theup> f836c094-2757-4f6e-add3-c5a7eefe2977  OS    8192     running           confluence
[10:07:16] <theup> facf9426-1de6-4f69-a2be-279894a70c01  OS    8192     running           file
[10:07:46] <theup> As you can see, I have 3 zones running fine, plus a newly created KVM
[10:07:50] <ktk> and vmadm info 767765ba-0ad8-4f84-abbb-6a2a3c5f0053 returns like *nothing*??
[10:08:00] *** dysinger has joined #smartos
[10:08:09] <theup> Nada.
[10:08:10] <theup> [root@00-1e-67-6f-91-47 /var/machines]# vmadm info 767765ba-0ad8-4f84-abbb-6a2a3c5f0053
[10:08:11] <theup> [root@00-1e-67-6f-91-47 /var/machines]#
[10:08:18] <ktk> wtf, never had that
[10:08:29] <ktk> theup: I'm pretty noob too, can't help more sorry
[10:08:44] <theup> I've looked around and so far found one guy who had the same problem, but no solution :-/
[10:08:53] <ktk> you have a recent release?
[10:09:03] <theup> Yes, the current one.
[10:09:29] <ktk> theup: I would recommend to post on the list, USA is probably still asleeep mostly
[10:09:56] <theup> Will have to do that, wanted to give IRC a try first :)
[10:10:12] <ktk> yeah for IRC you will be more lucky in around 8 hours :)
[10:10:48] <theup> Well, thanks anyway.
[10:16:25] <alcir> so
[10:16:30] <alcir> I'm here again
[10:16:36] *** dysinger has quit IRC
[10:16:37] <alcir> if I have two zpools
[10:17:18] <alcir> can I add a second zfs dataset living on a different zpool than zones, to a vm?
[10:19:09] *** KermitTheFragger has joined #smartos
[10:22:02] <MerlinDMC> ktk, what is the exit code for the vmadm info command? != 0?
[10:24:33] <ktk> MerlinDMC: theup has the issue :)
[10:24:52] <MerlinDMC> hmm ... yeah ... too early here -.-
[10:25:06] <MerlinDMC> theup, what is the exit code for the vmadm info command? != 0?
[10:26:01] <ktk> wow I managed to kill my v4 connectivity in obviously screwing up ipv6 config
[10:26:37] <ktk> but guests still can be reached :-D
[10:28:41] <theup> MerlinDMC: sorry, was afk for a second - exit status is 0
[10:29:35] *** Cpt-Oblivious|af has quit IRC
[10:34:27] *** trentster has quit IRC
[10:35:31] <MerlinDMC> theup, can you post the newest logfile of vmadmd and vmadm from /var/log/vm/ somewhere
[10:36:06] <MerlinDMC> the info command should give data back or exit non-zero afaik ... so there is something not OK in there
[10:36:32] *** trentster has joined #smartos
[10:38:10] <theup> yep, just a sec...
[10:39:47] <theup> There's one error listed in there:
[10:39:47] <theup> {"name":"vmadm","hostname":"00-1e-67-6f-91-47","pid":8014,"action":"info","vm":"767765ba-0ad8-4f84-abbb-6a2a3c5f0053","level":50,"err":{"message":"connect ECONNREFUSED","name":"Error","stack":"Error: connect ECONNREFUSED\n    at errnoException (net.js:773:11)\n    at Object.afterConnect [as oncomplete] (net.js:764:19)","code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"},"msg":"connect
[10:39:48] <theup> ECONNREFUSED","time":"2013-03-24T10:38:21.086Z","v":0}
[10:43:06] <theup> Though I am reasonably sure to have checked the logs when trying to get it to work yesterday with no error message given, but that is of course hard to prove now...
[10:50:59] *** arunoda has joined #smartos
[10:51:57] <arunoda> I've installed gcc with  pkgin in scmgit-base gcc47, but gcc binary is not there
[10:52:10] <arunoda> am I doing it correct?
[10:58:48] <theup> Okay, I am a moron. To everyone interested: The issue with me being unable to connect to KVM via VNC and vmadm returning nothing was caused by me changing the IP for the global zone via DHCP. vmadmd does not survive an IP change it seems and needs to be restarted / the system to be rebooted.
[11:00:29] *** theup has left #smartos
[11:01:59] *** theup has joined #smartos
[11:04:31] <MerlinDMC> theup, yeah something like that happend before - i think there also was an issue for this
[11:04:57] *** abnormal has joined #smartos
[11:05:22] <MerlinDMC> theup, https://github.com/joyent/smartos-live/issues/145
[11:06:49] <theup> MerlinDMC: Thanks a lot - rather obvious in retrospect I guess, but then again it always is. One could, however, argue that vmadm info should throw an error when it can't connect to vmadmd
[11:08:17] <theup> Anyway, thanks to everyone who responded
[11:09:06] *** bens1 has quit IRC
[11:11:41] *** bens1 has joined #smartos
[11:21:24] <arunoda> okay i figure it out gcc will be installed into /opt/local/gcc47/bin
[11:26:51] *** khushildep has quit IRC
[11:47:56] *** khushildep has joined #smartos
[11:51:33] *** wolfeidau has quit IRC
[11:55:26] *** khushildep has quit IRC
[11:57:19] *** kamilr has joined #smartos
[11:58:18] <kamilr> does anybody have experience in creating DHCP server on KVM in VLAN's ?
[12:08:06] *** emocakes has joined #smartos
[12:13:53] *** ira has joined #smartos
[12:20:42] *** bens1 has quit IRC
[12:24:13] *** wolfeidau has joined #smartos
[12:26:36] *** sachinsharma has quit IRC
[12:29:09] *** bens1 has joined #smartos
[12:36:50] *** szaydel has joined #smartos
[12:41:11] *** theup has left #smartos
[12:47:16] *** alucardX has quit IRC
[13:06:41] <alcir> kamilr no
[13:06:54] <alcir> first of all there is an option
[13:07:17] <alcir> dhcp_server
[13:08:44] *** enmand has joined #smartos
[13:10:51] *** bluezenix has quit IRC
[13:16:26] <kamilr> alcir: i know
[13:16:32] <kamilr> i have it already
[13:30:41] *** avrntsv has quit IRC
[13:43:20] *** bluezenix has joined #smartos
[14:04:18] *** ktk has quit IRC
[14:18:08] *** dysinger has joined #smartos
[14:20:42] *** dysinger has quit IRC
[14:35:31] *** neophenix has joined #smartos
[14:37:37] *** eliasgs has joined #smartos
[14:39:35] <eliasgs> Why does / have ownership 7084:other in smartos zone can I change it to root:root without something breaking?
[14:43:40] *** denizr has joined #smartos
[14:45:25] <nahamu> eliasgs: which image are you using for that zone?
[14:46:01] *** bluezenix1 has joined #smartos
[14:46:04] <eliasgs> its the a0f8cf30-f2ea-11e1-8a51-5793736be67c image
[14:47:48] *** bluezenix has quit IRC
[14:48:30] *** sachinsharma has joined #smartos
[14:51:40] *** abnormal has quit IRC
[14:53:24] <nahamu> that's a very old image.
[14:53:45] <nahamu> well, perhaps not very old, but certainly old.
[14:54:35] <nahamu> I think you can safely alter / to be owned root:root.
[14:55:22] <eliasgs> it is, lol - I thought this was the newest! I'll just install a newer then:)
[14:56:36] <jesse_> alcir, I have other pools delegated to a zone
[14:57:07] <jesse_> I needed to add them with zonecfg as vmadm doesn't support it (and hence it is unsupported)
[14:57:37] <jesse_> zonecfg -z <uuid> ; add dataset ; set name=<zfsname> ; end ; verify ; commit ; exit  (with ; being enter, I've only done it interactively)
[14:58:36] <jesse_> (there are some gotchas, too, I think if you delete the vm it'll delete your delegated pools, too)
[14:59:14] <MerlinDMC> eliasgs, if you don't need the "standard" image ... use the base one
[15:02:15] <eliasgs> yeah thanks - I just thought I'd save some time installing packages, ended up wasting more time with the ownership of / :)
[15:04:51] *** arunoda has quit IRC
[15:08:14] <nhubbard> does smartos support storing a zone on NFS? it looks like it does according to something I found in the documentation, but I'm not finding anything about how to do it?
[15:10:49] <wesolows> no.  you can however mount NFS filesystems within the zone
[15:12:25] <nhubbard> wesolows: ok that's what I thought just wanted to double check
[15:12:31] <szaydel> nhubbard: I think best bet is iSCSI or FCoE/FC if you wanted to have data for zones elsewhere.
[15:13:56] <szaydel> technically, you want a pool named zones, however that's not a hard requirement, though you probably should avoid building a pool with another name, which will def. make your life much more painful.
[15:14:03] *** chorrell has joined #smartos
[15:14:13] <alcir> jesse_ I see
[15:14:16] <alcir> it works
[15:14:28] <alcir> and it delete the dataset on zone deletion
[15:14:41] <alcir> :-O
[15:14:59] <wesolows> neither of those is supported either
[15:15:05] <wesolows> *local* *storage*
[15:15:35] <wesolows> it is obviously possible to hack together almost anything, but the entire design of the system is that the backing store for zones and VMs is purely local
[15:16:00] <szaydel> "Technically" iSCSI or FC/FCoE is "equivalent" to local. Almost. :)
[15:16:08] <wesolows> except that it isn't.
[15:16:36] <szaydel> So, with FC, I think we can basically say local, everything else, there is a big "*"!
[15:17:10] <wesolows> SANs have radically different failure characteristics and require external configuration that often cannot be performed locally
[15:17:32] <szaydel> Well true, but I was actually thinking locally attached FC DAS.
[15:17:35] <wesolows> anyway, the point is moot: the platform does not contain fcp(7d).
[15:20:18] <szaydel> I see little reason to attach anything other than say a JBOD for hosting the zones pool or any other pool. That seems to be counter to the design.
[15:25:12] *** Jadelrab has joined #smartos
[15:27:54] <alcir> another simple question
[15:27:59] <alcir> I have 4 nics
[15:28:20] <alcir> I want 1 nic in a subnet as admin interface
[15:28:42] <alcir> and other nics on other subnets
[15:28:51] <alcir> and at least 1 on vlans
[15:28:55] <alcir> tagged vlans
[15:29:12] <alcir> I don't need to assign ip to the GZ on such interfaces
[15:29:39] *** denizr has quit IRC
[15:29:59] *** denizr has joined #smartos
[15:34:55] *** noahmehl has joined #smartos
[15:35:44] <ira> The old trick of just one big manifest in an index.html isn't supported anymore for imgadm?
[15:38:06] *** enmand has quit IRC
[15:38:36] *** scarcry has quit IRC
[15:38:48] *** scarcry has joined #smartos
[15:39:29] *** nefilim has joined #smartos
[15:40:02] *** enmand has joined #smartos
[15:40:34] *** Jadelrab has quit IRC
[15:42:09] <MerlinDMC> ira, it is if you add a /ping backend as well
[15:42:32] <MerlinDMC> ira, can be static should contain smth like: http://datasets.at/ping
[15:43:32] <MerlinDMC> but maybe you'll also need to force json content type for the response
[15:44:28] *** avrntsv has joined #smartos
[15:44:40] <ira> Could be...
[15:45:33] <jesse_> alcir, but you should be able to remove the delegation with zonecfg before deleting the zone. But I haven't needed to test that, yet=)
[15:46:13] <alcir> jesse_ this is ok
[15:46:18] <alcir> thank you
[15:47:03] *** emocakes has quit IRC
[15:47:17] <ira> ok… I stripped it down to just Joyent's server… that still seems unhappy.
[15:47:22] <jesse_> vmadm really needs to support arbitrary delegation and full fs CRUD...
[15:49:51] <ira> And yes… the type would need to be json.
[16:07:35] *** ryancnelson has joined #smartos
[16:11:44] <ira> Ok… The ghetto solution works.  No need to force the type it seems.
[16:11:51] *** dysinger has joined #smartos
[16:12:48] *** Cpt-Oblivious|af has joined #smartos
[16:14:20] *** axonpoet has joined #smartos
[16:14:39] *** CarlosC has joined #smartos
[16:15:48] *** axonpoetsphere has joined #smartos
[16:18:45] *** axonpoet has quit IRC
[16:18:46] *** axonpoetsphere is now known as axonpoet
[16:27:00] *** dap has joined #smartos
[16:30:53] *** ryancnelson has left #smartos
[16:31:15] *** ryancnelson has joined #smartos
[16:32:09] *** bens1 has quit IRC
[16:35:57] *** sachinsharma has quit IRC
[16:37:44] *** tonyarkles has joined #smartos
[16:47:11] *** eliasgs has quit IRC
[16:47:28] *** kamilr has quit IRC
[17:05:33] *** bens1 has joined #smartos
[17:07:13] *** alcir has quit IRC
[17:09:07] *** szaydel has quit IRC
[17:16:53] *** szaydel has joined #smartos
[17:19:29] *** vsomes_ has joined #smartos
[17:20:13] *** Trixboxer has joined #smartos
[17:27:19] <Trixboxer> Hi, can some one help in installing iperf ?
[17:32:04] *** tonyarkles has quit IRC
[17:32:36] *** denizr has quit IRC
[17:33:19] *** denizr has joined #smartos
[17:35:43] *** KermitTheFragger has quit IRC
[17:38:02] <rmustacc> Trixboxer: What's your issue?
[17:39:00] *** avrntsv has quit IRC
[17:43:21] *** avrntsv has joined #smartos
[17:45:15] *** marsell has joined #smartos
[17:48:49] *** siezer has left #smartos
[17:54:30] *** chorrell has quit IRC
[17:57:12] *** abnormal has joined #smartos
[18:11:51] *** leecallen has quit IRC
[18:12:02] *** leecallen has joined #smartos
[18:12:29] *** denizr has quit IRC
[18:16:48] <opeth__> I've to revoke what I said about replicating to a legacy pool's legacy dataset - I don't know why but half of it didn't work - only one-half though :)
[18:17:11] <opeth__> so rsync time for me as well instead
[18:27:29] *** jim80net has joined #smartos
[18:28:26] *** bluezenix1 has quit IRC
[18:28:30] <opeth__> linuxprof: got my e-mail?
[18:28:39] <linuxprof> i did, tnx
[18:29:23] <opeth__> it was easier to dig it up and mail it than to describe my work-around
[18:29:38] <opeth__> I assume you could adapt it?
[18:30:14] <linuxprof> wasnt what i was looking for, but tnx =)
[18:30:25] <opeth__> yes it was actually
[18:30:42] <opeth__> it will build the parameter list for prstat so that it returns all zones
[18:31:06] <opeth__> I told you in advance that it was written to extract another 2 columns but that part wasn't even relevant
[18:31:11] <linuxprof> actually, cant even remember what i was looking for. hehe
[18:31:22] <opeth__> then it's really smart to say it wasn't that
[18:31:30] <opeth__> you wanted prstat to return all your non-global zones
[18:31:58] <linuxprof> oh, right
[18:32:10] <linuxprof> im on another problem now, hehe
[18:32:16] <opeth__> it will suppress most unwanted lines but return all non-global zones, so there
[18:32:22] <opeth__> but anyway, I wanted to help
[18:32:23] <opeth__> :)
[18:33:34] <linuxprof> tnx =)
[18:33:51] <linuxprof> ill have another look at it when i've resolved my current os x-based problem
[18:34:12] <opeth__> kk
[18:34:36] <linuxprof> you dont happen to know about a simple terminal program that gives me cpu load per core in os x?
[18:35:17] <opeth__> sorry, no; wouldn't the iStat dashboard widget be able?
[18:35:28] <opeth__> but well you need a text approach
[18:35:34] <opeth__> so no.
[18:35:35] <linuxprof> yeah
[18:35:50] <linuxprof> sar does what i need except it's not per core
[18:36:48] <opeth__> I wonder if anything will do that
[18:38:26] <jesse_> linuxprof, google for something that does that with dtrace, it might work as-is?
[18:45:11] <linuxprof> trying, but no success
[18:47:22] *** dalethion has joined #smartos
[18:47:55] <Trixboxer> rmustacc: Thanks. I have installed using https://help.joyent.com/entries/23213066-Using-Iperf-to-derive-network-bandwidth
[18:48:27] <Trixboxer> rmustacc: was trying to do network benchmarks
[18:49:14] *** dalethion has left #smartos
[18:49:52] *** jdefelice has quit IRC
[18:49:53] *** ryancnelson has left #smartos
[18:50:42] <Trixboxer> rmustacc: I'm still interested to know the way to install iperf via pkg
[18:52:24] <rmustacc> What dataset are you on?
[18:56:01] <Trixboxer> SmartOS Live Image v0.147+ build: 20130222T000747Z
[18:56:09] <bbarker> I (think) I "installed" smartos yesterday from USB; I typed in 8 very long disk names (took me 3 tries). Now, when I boot up from USB, it is asking me to go through the configuration again.
[18:56:36] <bbarker> Just wondering what I might have done wrong, though it is probably a pretty wide-open question...
[18:57:47] <bbarker> I guess I will go in to recovery mode and see if the zpool zones is there at least
[18:58:37] <Triskelios> that's probably the right step
[19:00:28] *** Cpt-Oblivious|af is now known as Cpt-Oblivious
[19:05:24] *** le^zeek has joined #smartos
[19:06:36] *** le^zeek has left #smartos
[19:07:29] *** ryao has joined #smartos
[19:07:49] <ryao> Does SmartOS support virtio-net and virtio-blk when it is being virtualized?
[19:08:13] <nahamu> It has whatever illumos has
[19:08:24] <nahamu> I think it currently has one but not the other, but I forget which.
[19:08:36] <nahamu> (I only run it on bare metal)
[19:08:52] <LeftWing> I believe we have the block driver.
[19:09:12] <richlowe> a net driver exists, and people talk about it every so often.
[19:09:16] <richlowe> but I think it's in the same state as vmxnet3, where everyone is a bit lazy.
[19:09:29] <LeftWing> I think it's probably much worse than vmxnet3.
[19:09:39] <LeftWing> In that the virtio net stuff is a bit batshit insane.
[19:09:47] <ryao> lol
[19:09:47] <richlowe> jperkin: this may seem like a silly question, but it has a purpose:  How big is a fully built pkgsrc tree (presumably a completely populated /opt/local, with everything installed)?
[19:10:11] <richlowe> jperkin: disk size good, number of files perhaps better.
[19:10:18] <LeftWing> So, I think it's about 10G...
[19:10:29] <LeftWing> Assuming you're not trying to install things that conflict
[19:10:53] <ryao> You guys piqued my interest. I am installing SmartOS in a KVM guest backed by a zvol. Is there an easy way to make the guest pool use ashift=12? Are there any specific hardware configuration suggestions that you can make?
[19:11:02] <ryao> Well, virtual hardware.
[19:11:46] <ryao> Hmm... the ISO doesn't boot properly. I get a ton of dots followed by the BIOS.
[19:12:39] <rmustacc> What procssor are you running this on?
[19:12:57] <ryao> rmustacc: An AMD Phenom II X6 1090T.
[19:12:58] <rmustacc> *processor
[19:13:03] <rmustacc> Okay, then I think you hit a known illumos bug.
[19:13:17] <ryao> I hit bugs without trying all the time. ;/
[19:13:17] <rmustacc> You could verify it by appending -k to the boot options.
[19:13:24] *** abnormal has quit IRC
[19:13:35] <rmustacc> Well, it's specific to virtualization on amd processors where it's trying to fix various errata.
[19:13:55] <ryao> rmustacc: What does -k do?
[19:14:30] <rmustacc> Well, the assumption I'm making is that grub and your hypervisor aren't broken.
[19:14:42] <rmustacc> And that you hit a case where the machine may have panicked while you weren't looking.
[19:14:55] <rmustacc> If that's the case -k will not cause it to immediately reboot but drop you into the kernel debugger.
[19:14:58] <ryao> I don't see a panic message. It is literally a stream of dots and then the BIOS post.
[19:15:03] <ryao> Ah, cool.
[19:15:13] <rmustacc> The stream of dots is from grub.
[19:16:12] <opeth__> now that I see ashift=12 mentioned
[19:16:24] <opeth__> would there be a way to have smartos build its zones pool that way?
[19:16:34] <ryao> Hmm... I probably should update my hypervisor. It is Linux 3.2.40. I can install kvm-kmod from Linux 3.8 to get the latest fixes.
[19:16:43] *** richlowe_ has joined #smartos
[19:16:47] <ryao> Well, that and QEMU 1.3.1
[19:16:56] <opeth__> could I tweak the sd driver config after having booted it in noinstall mode?
[19:16:58] <ryao> rmustacc: It dropped me to the kernel debugger.
[19:18:30] <rmustacc> With a panic message?
[19:18:34] <ryao> rmustacc: Is this a regression?
[19:18:43] <ryao> rmustacc: I do not have enough scrollback to get the panic.
[19:18:49] <rmustacc> Type '$C'
[19:18:50] <richlowe_> ::msgbuf
[19:19:00] <richlowe_> will page the console messages, $C will get you a stack
[19:19:46] <ryao> Does the Live CD support a serial connection for debugging? It would be much easier to just use that.
[19:19:56] <ryao> s/Live CD/ISO/
[19:20:54] <ryao> This is as much as I could get from it: http://bpaste.net/show/85661/
[19:21:03] <ryao> I am going to try a virtual serial line.
[19:21:13] <wesolows> it certainly should.  worst case you can just add console=ttyX,ttyX-mode="115200,8,n,1,-" or whatever to the boot arguments before booting
[19:21:23] <wesolows> if that doesn't work, it's a bug
[19:36:46] <ira> wesolows: Build a "proto.strap" perl.  And just leave it there.  Take away the build process' knowledge of the path to perl, and let the path do its job… Rebuild later with the right flags.
[19:36:55] <ira> Install into wherever...
[19:37:08] <ira> so flipping gross...
[19:37:57] <wesolows> yes, it's awful
[19:38:13] <wesolows> though we can't change paths, only change the perl that we run
[19:38:38] <ryao> rmustacc, richlowe_, wesolows: http://pastebin.com/0By6jaKZ
[19:38:42] <wesolows> everything in the build is really supposed to be using explicit full paths; the value of $PATH should never do anything
[19:39:06] <ira> Ah, so it all knows the right build prefix and can be happy there...
[19:39:19] <rmustacc> ryao: Yes, the exact bug I mentioned.
[19:39:26] <ira> (well, as happy as a gross perl hack is.)
[19:39:37] <ryao> rmustacc: Do you have a link to the illumos issue?
[19:39:41] <rmustacc> No.
[19:40:44] <ryao> Is there an illumos issue filed?
[19:40:45] *** jim80net has quit IRC
[19:41:20] <rmustacc> Don't know.
[19:41:37] <rmustacc> I discussed it with someone the other day in #illumos and helped them root cause it.
[19:41:41] <rmustacc> I don't know if they filed a bug or not.
[19:42:07] <ryao> rmustacc: Do you know if it is a regression? I have an old Open Indiana install that I did which did not seem to be affected by this.
[19:42:23] <rmustacc> What are you using for the value of -cpu?
[19:42:58] <rmustacc> No one to my knowledge has added new errata workarounds for AMD CPUs.
[19:42:59] <ryao> rmustacc: -cpu host
[19:43:24] <rmustacc> Use something else then.
[19:43:29] <ryao> I am booting the VM to see if it is affected. It has not been started in a while.
[19:43:30] <nahamu> I wonder if "-cpu qemu64" would work around the issue
[19:43:34] <rmustacc> It should.
[19:43:47] <rmustacc> Because it will no longer correctly identify as an AMD cpu.
[19:44:13] <ryao> It sounds like an AMD-specific fix was done incorrectly.
[19:44:45] <rmustacc> Because of virtualization, yes.
[19:44:54] <rmustacc> It isn't using a cheked rdmsr.
[19:44:57] <rmustacc> Or wrmsr
[19:44:59] <rmustacc> It needs to.
[19:45:05] <nahamu> ryao: when you're not cleaning up ZFSonLinux bugs, illumos and SmartOS have plenty of fun stuff to hack on... ;)
[19:45:25] <beau-_> of the tools that log system data to graphite (collectd, collectl, hoardd, diamond) is there one that works better than others on SmartOS? (i've attempted all of the previously mentioned and run into problems so am looking for one that people have had better luck with)
[19:45:44] <ryao> nahamu: We shall see.
[19:48:39] <ryao> rmustacc: I have confirmed it. Open Indiana is booting with -cpu host.
[19:49:15] <rmustacc> Well, what release of it?
[19:51:07] <ryao> rmustacc: I will tell you as soon as I login. I never finished setting this VM up, so it doesn't have a proper serial console or SSH server running.
[19:53:31] <ryao> rmustacc: oi_151a2
[19:54:21] *** richlowe has quit IRC
[19:56:13] *** bens1 has quit IRC
[20:11:38] *** bixu has joined #smartos
[20:14:03] *** bluezenix has joined #smartos
[20:15:28] <bixu> can someone help me interpret this prctl information from the JPC?
[20:15:30] <bixu> https://gist.github.com/bixu/5223926
[20:15:40] <bixu> Feel free to add comments to the gist.
[20:22:22] *** porkbelt has quit IRC
[20:24:28] *** porkbelt has joined #smartos
[20:26:39] <ira> wesolows: Is there a commit associated with OS-1828?
[20:27:08] <richlowe_> wesolows: I could have sworn I'd tried to make sure cmd/perl was doing the right thing still, did I just completely botch it?
[20:32:27] <bixu> I'm trying to figure out the the relationship between usage/privileged/system in that output.
[20:33:28] <bixu> Especially in cpu-cap
[20:35:17] *** porkbelt has quit IRC
[20:36:00] *** richlowe_ is now known as richlowe
[20:36:26] *** porkbelt has joined #smartos
[20:37:08] *** copec has quit IRC
[20:39:34] *** sebasp has quit IRC
[20:41:01] <wesolows> ira: no, it's open
[20:41:22] <ira> ok… Is there a place to see it outside joyent's walls? :)
[20:41:42] <wesolows> richlowe: I don't think it's your fault.  The use of /usr is considered ok for non-SmartOS build environments (i.e., sloppy ones :-) and the rest of the badness is inherent in perl itself.
[20:42:04] <wesolows> ira: there can be, I'll make a gist of it.
[20:43:11] <wesolows> https://gist.github.com/wesolows/3ec2663f9847a68c8bc6/raw/ee5405d7fc345705f3af043ba981279fa226d17a/gistfile1.txt
[20:43:24] <wesolows> that's the entire sad story.
[20:43:29] *** copec has joined #smartos
[20:44:08] <ira> Yucko.
[20:44:18] <ryao> What is not open?
[20:44:39] <wesolows> the joyent bug database.
[20:44:51] <ira> And I 100% respect that :)
[20:45:03] <wesolows> which is why I've pasted the contents of this bug, which has absolutely no confidential information in it
[20:45:37] <ryao> ira: What is the problem that you are seeing?
[20:45:42] *** denizr has joined #smartos
[20:46:31] <ira> ryao: The build fell over, when I upgraded my platform.  (A build that worked before doesn't now.)
[20:46:59] <ira> I fixed it for myself short term… but I filed a bug so people were aware of it and would fix it in a less sucky way than I did ;)
[20:47:01] <ryao> The concept of building native tools and executing them as part of a build system is inherently broken. That isn't cross compiler compatible.
[20:47:15] <ryao> I wonder how we handle that in Gentoo.
[20:47:35] *** richlowe has quit IRC
[20:47:48] <ryao> ira: I am checking... we might have a patch to fix your issue.
[20:47:59] <rmustacc> No, building native tools can entirely be cross-compiler compatible.
[20:48:09] <rmustacc> The trick is making sure your tools understand other architectures.
[20:48:22] <ryao> rmustacc: Only if you build the prerequisites on the host.
[20:48:26] <rmustacc> A cross compiler is a native tool.
[20:48:42] <ryao> Or do you mean that your build system would be aware of the difference between the cross compiler and native compiler?
[20:48:56] <rmustacc> The build system should be.
[20:49:03] <wesolows> right, there have to be two different ways things get built: one for things run on the host, one for the target
[20:49:07] <ryao> I don't think the build system should have any idea.
[20:49:26] <wesolows> this applies regardless of whether you're actually cross-compiling or just (as we do) need a build that doesn't depend on the build system
[20:49:29] <ryao> Ideally, it should just know to use X toolchain to get the binaries. It shouldn't know anything else.
[20:49:48] <wesolows> it's not that simple
[20:49:51] <rmustacc> If you want to overly restrict the amount of things you can do in a build process, then fine.
[20:49:57] <ryao> wesolows: I am aware.
[20:50:04] <rmustacc> But in that world you've just lost your shell and make.
[20:50:04] <wesolows> building hello world is simple like that, yes, especially if you use an all-GNU toolchain which we do not.
[20:50:31] <ira> wesolows: I still think using cw is a bug here, intermediate term. :)
[20:50:39] <ryao> rmustacc: There are things known as host dependencies.
[20:51:19] <ryao> It is reasonable to have a POSIX shell, the compiler, linker, assembler, perl, python, make, automake, autoconf, etcetera as host dependendies.
[20:51:33] <wesolows> ira: everything about perl is a bug
[20:51:43] <rmustacc> But it's unreasonable to have my program write a little c program to help autogenerate stuff for the rest of the build?
[20:51:50] <ryao> rmustacc: Yes.
[20:51:56] <ryao> That should be a separate package.
[20:52:08] <ira> wesolows: I'd agree… though I'm more wondering about the rest of the illumos build.
[20:53:05] <rmustacc> We'll have to agree to disagree.
[20:53:10] <ryao> rmustacc: Lets disagree. :)
[20:54:57] <ryao> I don't see how we handle cross compilation: http://bpaste.net/show/85692/
[20:56:03] <ryao> I know that it works because that is how our stage3 tarballs are made. :/
[20:56:14] <ryao> Wait... is perl part of illumos or is this from pkgsrc?
[20:58:00] <rmustacc> Neither.
[20:58:02] <wesolows> this is perl from illumos-extra
[20:58:06] <wesolows> and the perl modules in ON
[20:58:11] <wesolows> pkgsrc is not involved at all
[20:59:11] <bbarker> is it possible to start the smartos install script from "recovery"? if so, where is the script? I just created a raidz2 pool "zones", so I think that should be the next step
[21:01:45] <nahamu> bbarker: you could also just reboot and boot the normal mode.
[21:01:49] <bbarker> ok
[21:01:51] <bbarker> thanks
[21:02:10] <nahamu> and then when it asks about disks, just give it a single disk to get it to shut up. it will use your existing pool.
[21:02:24] <bbarker> ah ok
[21:02:27] <ryao> ira: What is your use case for perl?
[21:03:34] <rmustacc> To build illumos.
[21:04:03] <rmustacc> This perl is only for illumos and for running various utilities inside of illumos.
[21:04:08] <ryao> Could pkgsrc's perl be used for this?
[21:04:11] <rmustacc> Otherwise you just use the pkgsrc perl and everything's fine.
[21:04:21] <rmustacc> No.
[21:04:27] <rmustacc> You need to ship it in the platform.
[21:05:57] <wesolows> I've tried to explain the problems in OS-1588, OS-1828, and illumos-extra#9
[21:07:14] <wesolows> understanding them requires understanding the premise around which our build system is designed, namely that it should (in principle) be possible to build on any system.  In practice it is not, and bugs like these are among the stumbling blocks to achieving that.
[21:07:48] <wesolows> more importantly, no delivered artifact may depend in any way upon the tools installed on the build system itself, or the headers or libraries it contains
[21:08:22] <ryao> wesolows: Wait... does that mean that I can build Illumos from Linus?
[21:08:27] <ryao> s/Linus/Linux/
[21:08:39] <wesolows> in principle, yes
[21:08:44] <wesolows> in fact, no, not at all
[21:08:50] <wesolows> (and not illumos, but smartos-live)
[21:09:17] <wesolows> that you can't is a result of huge numbers of bugs, some of which are easier to fix than others.
[21:09:38] <wesolows> but for example, a more immediate and practical goal is to be able to build on both 1.6.3 and multilib zones
[21:09:43] <ryao> I was under the impressionthat Illumos et al had no interest in permitting builds outside of Illumos.
[21:09:59] <wesolows> #illumos is over there --->
[21:10:09] <ryao> et al includes smartos.
[21:10:25] <ryao> Anyway, it is great to hear that my impression was wrong.
[21:10:32] <LeftWing> We're not specifically trying to make our stuff build on Linux, because there's little point.
[21:10:45] <LeftWing> But it is a knock-on effect of doing all the right things anyway.
[21:10:52] <wesolows> well, the point is that if we never link with anything on the build system except to build build tools, then only those build tools need to care about being portable.
[21:10:55] <ryao> Does this mean that you would take patches to make it work?
[21:11:10] <wesolows> probably, depending on what they are
[21:11:10] <LeftWing> Provided they make sense, patches are always welcome.
[21:11:19] <ryao> Cool.
[21:11:32] <rmustacc> But, no. Most people probably don't want to see a bunch of #ifdef linux patches in sgs and co.
[21:11:47] <ryao> lol
[21:11:48] <wesolows> there are really three basic levels here: building on "arbitrary" illumos-derived systems, as I mentioned above; building on illumos-derived systems of a different ISA; building on arbitrary Unix systems
[21:12:02] <wesolows> the first of these is a definite goal
[21:12:18] <wesolows> the second is essential to being able to cross-build and support new and/or small architectures
[21:12:18] <LeftWing> and the second one is something that people are, at least, working on.
[21:12:28] <ryao> wesolows: I can add another level. Building on non-UNIX systems. :P
[21:12:32] <wesolows> the third is a non-goal that may fall out of the others, but is much less important
[21:12:55] <wesolows> and tends to clutter things with gross bullshit to work around shoddily built systems (cf rm's #ifdef linux)
[21:13:20] <wesolows> everything required for 1 and 2 to be correct is also required for 3
[21:13:30] <wesolows> so if you personally care about 3, help us fix 1 and 2
[21:13:37] <wesolows> 4 is irrelevant
[21:13:50] <wesolows> non-Unix systems are not interesting at all
[21:14:38] <LeftWing> But how will I build illumos on my Macintosh SE/30 running System 7.1 ?!
[21:15:01] <nahamu> LeftWing: with a butterfly like a real programmer.
[21:15:07] <rmustacc> And demerit.
[21:15:26] <rmustacc> (To LeftWing)
[21:15:31] <LeftWing> aww.
[21:16:17] <ryao> I think you can build NetBSD on Windows.
[21:16:26] <ryao> nahamu: Nice comment. :)
[21:17:40] *** JT-EC has quit IRC
[21:18:04] <bixu> Joyent guys really take this boy scout thing seriously.  Cantrill influence?
[21:18:26] *** JT-EC has joined #smartos
[21:20:14] <rmustacc> What do you mean?
[21:20:56] <wesolows> trying to help trolls learn, and old ladies across the street?
[21:21:23] <LeftWing> Perhaps he means the way I tie my shoes now?
[21:21:31] <EMH_Mark3> hm weird... seems stderr redirection using &> is causing either bash or svcadm to go nuts
[21:21:46] <bixu> The demerits.
[21:22:14] <rmustacc> Those are entirely different from scouting.
[21:22:34] <bixu> Oh - okay :)
[21:22:35] <LeftWing> You win demerits by trolling your peers.
[21:22:47] <bixu> Oh, so demerits are a *good* thing...
[21:23:06] <LeftWing> wesolows: HEY MAN, I THINK WE SHOULD GO BACK TO USING HARDWARE RAID THIS ZFS SHIT IS UNRELIABLE
[21:23:10] <LeftWing> (for example)
[21:23:25] <bixu> Yeah, you should use PERCs.
[21:23:29] <LeftWing> Heaps.
[21:23:31] <LeftWing> PERCs are the shit.
[21:23:42] * bixu awards himself a demerit.
[21:23:45] <LeftWing> Also, demerits are not good.  Stop hurting people. :P
[21:23:47] <nahamu> LeftWing: only if the RAID volumes are accessed over a SAN
[21:23:54] <EMH_Mark3> LeftWing: no shit! zfs was giving me tons of checksum errors. I prefer my errors to be silent!
[21:23:55] <LeftWing> Oh god, what have I done.
[21:24:01] <LeftWing> I'
[21:24:04] <LeftWing> ve created a monster.
[21:27:16] <nahamu> As long as you regret it.
[21:34:28] *** xmerlin has joined #smartos
[21:37:15] <bbarker> anyone know of some decently pertitent docs to running openvpn in the global zone?
[21:37:30] <bbarker> problem is I can't remotely access this system with ssh without a vpn, afaik
[21:37:50] <nahamu> I know we do some sort of black magic to do it.
[21:37:58] <nahamu> I don't know if it's documented.
[21:38:32] <nahamu> joshie might know off the top of his head if he's around...
[21:39:02] <bbarker> nahamu ok, thanks
[21:39:14] *** nefilim has quit IRC
[21:40:18] <nahamu> let me take a quick look to see if I can find anything
[21:41:14] *** xmerlin has quit IRC
[21:42:56] <nahamu> oh, you said in the global zone...
[21:42:59] <nahamu> we do it in local zones.
[21:43:08] <nahamu> I've got nothing.
[21:43:41] <bixu> So about prtctl...
[21:44:04] <bixu> What's the difference between zone.cpu-shares 'usage' and 'privileged'?
[21:44:35] *** nefilim has joined #smartos
[21:47:40] <wesolows> let me look at the docs; the expert in this is not here and is busy on something else
[21:47:53] <wesolows> iirc, 'privileged' is the cap, and 'usage' is current actual
[21:48:59] <bixu> I think you are right about that, except it's in the case of zone.cpu-cap
[21:49:00] <bixu> zone.cpu-cap usage 3 - - -
[21:49:19] <bixu> zone.cpu-shares values seem to be fixed regardless of workload.
[21:49:33] <wesolows> and it looks like for this, because you always "have" the shares even if you aren't using them, usage and privileged would normally be the same; i.e., usage would be the lowest of all the caps
[21:49:44] <wesolows> this is for shares, not caps... the cap is a separate thing entirely
[21:50:04] <bixu> So, essentially, shares are the 'guarantee' and caps are the 'burst'?
[21:50:29] <wesolows> shares govern how time on CPU is allocated when access to CPU is contended
[21:50:49] <wesolows> see FSS(7)
[21:50:53] <bixu> Right.
[21:51:02] <wesolows> the cap limits you absolutely, regardless of contention
[21:51:03] <bixu> I'm just trying to confirm my understanding.
[21:51:06] <wesolows> so, as you say, bursting
[21:51:07] <bixu> Right.
[21:51:24] <bixu> Cap takes effect only if there's more than enough spare cpu on the compute node.
[21:51:33] <wesolows> essentially, yes.
[21:51:45] <bixu> But you still (reasonably) limit the amount I can consume with the hard zone.cpu-cap
[21:52:10] <bixu> I'm writing a circonus/nad hook to pull this data and graph it, and I want to make sure I'm naming it reasonably.
[21:52:41] <wesolows> so, back to the shares 'usage' vs 'privileged', the 'privileged' is just the name of a resource limit.  In this case, it limits the number of shares you get.  Usage will be the lowest of all the limits, meaning that's how many FSS shares you always have.  It has nothing to do with caps.
[21:52:47] <wesolows> right
[21:53:31] <bixu> So zone.cpu-shares 'usage' and 'privileged' here represent the upper and lower bounds of the 'preallocated' slice of cpu for this zone.
[21:53:44] <bixu> Not actual cpu pinning, but a fraction of the total cpu available.
[21:54:01] <wesolows> well, in practice they'll be the same, since the 'privileged' shares limit is the only limit
[21:54:25] *** Tekni has joined #smartos
[21:54:26] <bixu> Or maybe I can think of zones.cpu-shares as a reservation for cpu?
[21:54:29] <wesolows> the rctl system is designed to allow for things that are more dynamic than CPU shares, which are really a static thing
[21:54:36] <bixu> Right.
[21:54:52] <wesolows> yes, you can think of it that way.  On any non-overprovisioned system, that's your reservation.
[21:55:27] <bixu> What about a system that's overprovisioned?  Am I guaranteed the amount specified in the 'privileged' field?
[21:55:56] <wesolows> well, 'usage' and 'privileged' probably always have the same value, which is just the number of shares your zone is allocated.
[21:56:03] <wesolows> so we can dispense with the distinction between them
[21:56:19] *** xinkeT has quit IRC
[21:56:20] <wesolows> on an overprovisioned system, you get that number of shares
[21:56:31] <bixu> Perfect.
[21:56:45] <wesolows> however, what I don't think you can necessarily know is how many shares other zones get.  It's your shares / total shares that govern your access to CPU
[21:57:13] <wesolows> that's true regardless of whether a system is overprovisioned.  On a fully or underprovisioned system, total shares will be <= 100 * the number of logical CPUs
[21:57:26] <wesolows> so you'll always be guaranteed at least that number of CPUs / 100.
[21:57:40] <wesolows> on an overprovisioned system, it really would depend on how overprovisioned it is.
[21:57:47] <bixu> Right.
[21:58:19] <bixu> So are you saying that I can't assume that the total shares across all zones add up to zone.cpu-shares system?
[21:59:14] <wesolows> You cannot.  It may be less, as your system may be underprovisioned.
[21:59:44] <wesolows> whether systems are allowed to be overprovisioned I do not know.  You would need to ask Support as that's a Sales/Operations type question.
[21:59:54] <bixu> Okay.
[21:59:59] <wesolows> The software supports it and will behave as I've described it here.
[22:00:24] <bixu> So you could theoretically assign a total number of shares that's great than zone.cpu-shares?
[22:00:34] <bixu> er
[22:00:39] <bixu> zone.cpu-shares  system
[22:02:17] <wesolows> I'm trying to figure out where the system limit to the number of shares comes from
[22:02:41] <wesolows> it seems like it's just a fixed quantity that has nothing to do with the size of capabilities of the system
[22:04:21] <wesolows> the important thing to keep in mind here is that what matters is the ratio of your shares to the total shares (or your shares to the total of zones with threads on run queues, I suppose)
[22:04:39] *** denizr has quit IRC
[22:04:53] <bixu> Right, the ratio is what I'd paying attention to for capacity planning.
[22:05:19] <bixu> I just want to know if the aggregate of all the zone share limits can exceed the system share limit.
[22:05:37] <bixu> If the aggregate can't, then I can trust these numbers :)
[22:05:47] <wesolows> as I though... the system value is just FSS_MAXSHARES, from sys/fss.h
[22:06:34] <wesolows> which means that no zone may have more than 64k shares.  But I don't know whether that means anything about the *total* number, and I'm pretty sure it does not.
[22:06:57] <bixu> Makes sense.
[22:07:26] <wesolows> in other words, the figure you need to really interpret your cpu share count is probably not available to you in a zone
[22:08:02] <wesolows> that being the total number of shares across all zones.  Of course, even if it were, the global for example has some large number of shares, but it's not meaningful because it's unlikely that the global has many threads on the run queue
[22:08:06] <bixu> Well, I can do this: prctl -P -n zone.cpu-shares -i zone $(zonename)
[22:08:16] <bixu> Which yeilds: zone.cpu-shares system 65535 max none -
[22:09:42] *** porkbelt has quit IRC
[22:12:25] *** deirdres has joined #smartos
[22:12:43] <bixu> From the resource_control manpage:
[22:13:20] <bixu> A resource control is guaranteed to have one system value, which is  defined by the system, or resource provider. The system value represents how much of the resource the current implementation of the operating system is capable of providing.
[22:13:52] *** porkbelt has joined #smartos
[22:14:05] <bixu> So I think I can use that value to calculate what fraction of the system cpu resources are being reserved for me in case of contention.
[22:14:08] *** wolfeidau has quit IRC
[22:16:30] <rmustacc> The total number of shares depends on the number of zones.
[22:27:50] *** marsell has quit IRC
[22:31:41] <bixu> Yes.
[22:41:50] *** Trixboxer has quit IRC
[22:55:39] *** neophenix has quit IRC
[23:00:25] *** bixu has quit IRC
[23:13:18] *** bens1 has joined #smartos
[23:14:00] *** szaydel has quit IRC
[23:14:48] *** bens1 has quit IRC
[23:16:16] *** richlowe has joined #smartos
[23:16:30] *** daleg has quit IRC
[23:27:50] *** marsell has joined #smartos
[23:34:08] *** wolstena has left #smartos
[23:38:16] *** axonpoet has quit IRC
[23:43:14] *** porkbelt has quit IRC
[23:45:55] *** porkbelt has joined #smartos
[23:53:42] *** emocakes_ has joined #smartos
[23:54:22] *** emocakes_ is now known as emocakes
top

   March 22, 2013  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >