Switch to DuckDuckGo Search
   March 1, 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:00:24] <rmustacc> I'd start by looking at mpstat.
[00:00:35] *** ipalreadytaken has joined #smartos
[00:00:40] <rmustacc> prstat only runs at an interval.
[00:00:46] <rmustacc> Recall it will miss short lived processes.
[00:01:10] <trentster> rmustacc: so what diagnostic route would you proceed with?
[00:01:24] <trentster> run a dtrace on the dtrace ;-)
[00:02:07] <rmustacc> I'm not sure I understand what your problem actually is.
[00:02:35] <chorrell> re: mpstat, this might be helpful http://wiki.joyent.com/wiki/display/gen/Using+mpstat
[00:02:42] <rmustacc> As far as I understand it, someone told your machine to reboot, so it did.
[00:02:51] <rmustacc> At least, that's how it was described ot me.
[00:02:53] <rmustacc> *to me
[00:02:59] <Licenser> rmustacc the system froze up entirely
[00:03:51] <Licenser> happening on two different systems both right after running said script it sounds not too much as an coincidence
[00:04:08] <Licenser> but I totally understand that we don't have much data to work with :(
[00:04:30] <trentster> chorrell: thanks
[00:05:05] *** jamesd has joined #smartos
[00:05:31] <rmustacc> Then the next thing you have to do is to run ipmi chassis power diag.
[00:05:40] <rmustacc> And get a dump.
[00:05:54] <rmustacc> But if you do that, the DTrace deadman will time it out and kill it shortly.
[00:05:57] *** ryancnelson has left #smartos
[00:06:02] <rmustacc> But looking at every syscall doesn't realy kill the system.
[00:06:12] <rmustacc> We have that in CA.
[00:06:18] <rmustacc> That said you can improve your script rather substantially.
[00:07:34] <Licenser> rmustacc no question I'm a dtrace amateur ^^
[00:07:38] <trentster> Licenser: yup it just killed my system again
[00:07:44] <Licenser> trentster cool!
[00:07:50] <Licenser> now do the dump thing
[00:07:56] <rmustacc> Just as simple as dtrace -n 'syscall:::enter{ self->t = vtimestamp; }' -n 'syscall:::return/self->t/{ @[probefunc] = lquantize()... }'
[00:07:56] <Licenser> sorry not cool of cause :P but good timing
[00:08:17] <trentster> Licenser: I dont think its dumping
[00:08:22] <rmustacc> Then a final -n 'syscall:::return{ self->t = 0; }'
[00:08:24] <trentster> gonna watch the console now..
[00:08:57] <trentster> what i did see via mpstat when it was running is one cpu core went from 99 idle to 50% idle other than that not much
[00:09:08] <rmustacc> On what interval?
[00:09:15] <rmustacc> I mean, having busy cpus is generally a fine thing.
[00:09:41] <rmustacc> I always look at one second intervals with any *stat tool because that's the only way to get mostly useful data.
[00:09:48] <rmustacc> A five second interval is just way too long for cpus.
[00:09:57] <trentster> rmustacc: as mentioned previously this is a new empty node, it has 1 zone on it, and the zone is doing nothing if I zlogin to the vm zone it shows a load average of 0.0
[00:10:11] <trentster> and the interval I ran mpstat with is (2) seconds
[00:10:19] <rmustacc> Sure, the load average is different for a zone and the GZ.
[00:10:24] <Licenser> trentster does the node have ipmi?
[00:10:45] <trentster> it takes about 10-15 seconds with the script running for the node to A) stop responding B) reboot
[00:11:03] <rmustacc> As in you initiate a reboot or it does so on its own?
[00:11:11] <trentster> Licenser: yes it does have ipmi.
[00:11:17] <Licenser> okay
[00:11:22] <trentster> rmustacc: it does it on its own.
[00:11:52] <trentster> rmustacc: in licensers case his system totally from up and he had to reboot it via (RMM)
[00:12:27] <rmustacc> If it does it on its own, and you said fans are reving up, it could be any number of things.
[00:12:40] <trentster> rmustacc: as in?
[00:13:09] <rmustacc> Well, hardware resets itself in various conditions.
[00:14:29] <rmustacc> The fact that your fans are spinning themselves up should be worrisome.
[00:14:33] <rmustacc> And the OS doesn't do that.
[00:16:29] <trentster> rmustacc: as general best practice what are the option that should be disabled / enabled in the Bios of server grade systems?
[00:18:41] <trentster> The reason I ask is this system was running openindiana with an uptime of about a year previously without any issue, which makes me think it may be some setting in the bios which SmartOS does not like.
[00:19:06] *** axonpoet has joined #smartos
[00:19:50] <rmustacc> That's bios specific.
[00:20:30] *** wolstena has joined #smartos
[00:22:07] *** neophenix has quit IRC
[00:22:56] <wesolows> trentster: there is no general best practice, because the set of things that are configurable and even their meaning varies so much from system to system
[00:23:25] <wesolows> also, most BIOSes are extremely buggy, and it's often necessary to set certain parameters to work around the specific set of bugs your BIOS has
[00:23:49] <wesolows> if you want to know what we're doing, there is a dictionary of settings in download.joyent.com/pub/manufacturing
[00:24:04] <wesolows> they obviously apply only to these specific boards and BIOS revisions
[00:25:23] <rmustacc> Does your board have ipmi?
[00:27:19] *** Guest71226 has quit IRC
[00:27:20] <trentster> yes
[00:27:58] <trentster> wesolows: thanks
[00:29:58] <rmustacc> Then maybe the bmc has some kind of log.
[00:30:51] <elijah-mbp> ipmitool sel print
[00:30:56] <elijah-mbp> if you're lucky.
[00:32:22] <wesolows> gotta wonder how anyone ever thought ipmi is a good idea
[00:33:22] <wesolows> there's really nothing at all good about it.  it's not easy to use.  it's not easy to write a client.  it's not easy to write a server.  it's big.  it's complex.  it's insecure.  it's inflexible.  it has terrible error semantics.
[00:33:25] <trentster> rmustacc: wesolows Licenser There is nothing like watching a crash occur http://cl.ly/2y0K0q0Y2g2I
[00:36:02] <Licenser> there is something about bad trap
[00:36:14] <Licenser> and a kstat  fault
[00:36:25] <rmustacc> Why don't you have a dump device?!
[00:37:54] <rmustacc> Please create a dump device. Without that, there's nothing we can do.
[00:38:04] <rmustacc> The normal install process should create it.
[00:38:07] <Licenser> doesn't smartOS do that automatically?
[00:38:14] <wesolows> your machine double-faulted.  Unfortunately because you're using the fucking ikvm bullshit instead of the serial console, and have neither mkdb loaded nor a dump device, it's absolutely impossible to debug any further
[00:38:36] <rmustacc> Licenser: Yes, it should.
[00:38:43] <Licenser> okay
[00:38:59] <rmustacc> But if you manually create the zpool or something like that, then it could be skipped.
[00:39:16] <Licenser> we'll since trenster can recrash his system he can add a domp device and we just wrack it dead again :D
[00:39:42] <wesolows> we trapped in dtrace_bcopy, called from dtrace_dynvar+532.
[00:39:52] <wesolows> unfortunately without a dump, it's pretty hopeless.
[00:40:26] <wesolows> it would also be useful to know if this feature of fifo just runs dtrace or runs it with -w.
[00:40:46] <Licenser> wesolows it runs it via libdtrace
[00:41:06] <trentster> ok let me create a dump device. Never done this manually before, what do I do?
[00:41:12] <rmustacc> Do you set the option?
[00:41:22] <rmustacc> Via libdtrace.
[00:41:46] <trentster> rmustacc: was a standard install of smartos… at install time I gave it 2 drives for zones and rebooted.
[00:42:08] <trentster> only thing I did after that was plug in another set of drives and zpool import another pool.
[00:42:19] <rmustacc> Really? Okay. That's a bit surprising then.
[00:42:24] <trentster> so afaik the dump should have been created as it was a standard install
[00:42:34] <Licenser> nope
[00:42:49] <rmustacc> Does zfs list | grep dump show anything?
[00:42:51] *** chorrell has quit IRC
[00:43:22] <Licenser> just set:   dtrace_setopt(handle->handle, "bufsize", "4m"); dtrace_setopt(handle->handle, "aggsize", "4m");
[00:44:28] <trentster> rmustacc: no it doesent
[00:44:38] <trentster> shows there is no dump
[00:45:51] <Licenser> does dumpadm show anything?
[00:46:02] <wesolows> the only place you can be is dtrace.c:2029.  Get a dump and debug from there.
[00:46:23] <rmustacc> Let me dig up the dump stuff, one moment.
[00:47:01] <rmustacc> This is basically what it does to create it: https://github.com/joyent/smartos-overlay/blob/master/smartdc/bin/smartos_prompt_config.sh#L299
[00:48:15] *** Andy has quit IRC
[00:48:27] <rmustacc> Basically you want to create a zvol of sufficient size and then turn it on with dumpadm.
[00:48:30] <trentster> [root@smartosn6 ~]# dumpadm
[00:48:30] <trentster>       Dump content: kernel pages
[00:48:31] <trentster>        Dump device: none (dumps disabled)
[00:48:31] <trentster> Savecore directory: /var/crash/volatile
[00:48:31] <trentster>   Savecore enabled: no
[00:48:31] <trentster>    Save compressed: on
[00:49:25] <rmustacc> Yeah, the dump device being none is the problem.
[00:49:48] <trentster> ok creating it now
[00:53:33] <trentster> [root@smartosn6 ~]# dumpadm
[00:53:33] <trentster>       Dump content: kernel pages
[00:53:33] <trentster>        Dump device: /dev/zvol/dsk/zones/dump (dedicated)
[00:53:33] <trentster> Savecore directory: /var/crash/volatile
[00:53:34] <trentster>   Savecore enabled: no
[00:53:34] <trentster>    Save compressed: on
[00:53:55] <trentster> Do I need to enable Savecore ?
[00:53:57] <rmustacc> No.
[00:54:17] <trentster> ok gonna trigger the crash again now
[00:58:23] <Licenser> :D
[01:06:19] *** bradleymeck has joined #smartos
[01:10:39] *** deedubs has quit IRC
[01:13:02] <trentster> rmustacc: weselow	Licenser you are not going to believe this. Since I created the dump device that node does not crash when the script is run. BUT now I have another node that is rebooting. Different hardware altogether
[01:13:30] <Licenser> hah did the other node have a crash device?
[01:13:39] <trentster> Do I need to call the Ghostbusters :-P
[01:13:46] <trentster> Licenser: looking
[01:13:57] <Licenser> trentster you should check all your servers ;)
[01:14:09] <trentster> waiting for it to pxeboot
[01:15:05] <trentster> Licenser: yes the new node that just rebooted does have a dump device
[01:15:09] <Licenser> cool!
[01:16:19] *** ipalread_ has joined #smartos
[01:18:08] <trentster> ok we now have a valid crash dump on another node..
[01:19:16] *** ipalreadytaken has quit IRC
[01:22:56] *** bradleymeck has quit IRC
[01:26:25] *** bradleymeck has joined #smartos
[01:29:19] *** marsell has quit IRC
[01:32:13] *** szaydel has quit IRC
[01:36:40] *** leecallen has joined #smartos
[01:36:41] *** leecallen35 has quit IRC
[01:39:19] <enmand> Has anyone had any luck compiling uwsgi on SmartOS?
[01:39:24] *** Cpt-Oblivious has quit IRC
[01:39:34] <trentster> rmustacc: https://gist.github.com/trentster/8d8b9cfad014ba96c203 what do you want me to do with the dump?
[01:40:01] *** ipalread_ has quit IRC
[01:40:11] <trentster> wesolows: ?
[01:44:37] <wesolows> debug it?
[01:44:57] *** szaydel has joined #smartos
[01:45:43] <rmustacc> If you make it available other folks can take a look at it, but it'll be a slow proecss.
[01:46:37] <wesolows> yeah.  choices are, post it somewhere and put the URL in a bug report, or debug it yourself.
[01:46:56] *** ipalreadytaken has joined #smartos
[01:46:58] <wesolows> debugging a dump via remote hands is suicide-inducing
[01:47:22] <trentster> rmustacc: weselows is there anything you want me to do while I have mdb open.
[01:49:05] <sheppard> wesolows: yes
[02:10:40] *** denizr has joined #smartos
[02:14:41] *** ipalreadytaken has quit IRC
[02:23:49] *** denizr has quit IRC
[02:24:02] *** Licenser_ has quit IRC
[02:27:22] *** deedubs has joined #smartos
[02:27:35] *** dap has quit IRC
[02:40:34] *** porkbelt has quit IRC
[02:40:56] *** wolstena has quit IRC
[02:41:00] <tallship> Time for a SPAM Sannich buoys and gulls: http://martinvalasek.com/blog/pictures-from-a-developers-life
[02:43:49] *** wolstena has joined #smartos
[02:44:51] *** potatosalad has quit IRC
[02:45:14] *** denizr has joined #smartos
[02:51:51] *** papertigers_lapt has joined #smartos
[03:31:51] <richlowe> rmustacc: I'll take a copy.
[03:32:58] <richlowe> not that I'd probably be much more useful than with the damn apix crap
[03:33:01] <richlowe> which is still driving me a bit crazy
[03:38:22] <trentster> richlowe: that makes 2 of us ;-)
[03:41:29] <richlowe> Well, I'll certainly look at the dtrace thing.
[03:41:32] <richlowe> especially if nobody else is going to
[03:42:38] <richlowe> trentster: So, on this apix system you have 4 instance of pci-ide.
[03:43:00] <trentster> richlowe: thanks so much! its appreciated.
[03:43:06] <richlowe> trentster: in the prtconf when it's working, you don't seem to have anything attached below that
[03:43:17] <richlowe> when we're crashing, we're trying to attach ata to one of the ide nodes below that.
[03:43:38] <richlowe> does that make any sense at all?
[03:44:58] *** abhishekvasisht has joined #smartos
[03:52:59] *** abhishekvasisht has quit IRC
[03:55:34] <richlowe> rmustacc: booting -Bdisable-apix=true is effective, right?
[04:00:53] *** bradleymeck has quit IRC
[04:01:42] *** wolstena has quit IRC
[04:16:27] <richlowe> Well, I have a theory, at least.
[04:19:09] <Licenser> hmm so the crash has to do with apix? or am I missing part of the discussion?
[04:19:25] <richlowe> Licenser: separate bugs, sorry, I was trying to debug a separate problem trentster hit.
[04:19:32] <Licenser> ohhh okay
[04:19:39] <Licenser> I was kind of surprised ^^
[04:19:41] <Licenser> sorry
[04:21:54] *** bradleymeck has joined #smartos
[04:24:12] *** bradleymeck has quit IRC
[04:24:54] <richlowe> rmustacc, wesolows: So, in dtrace_dynvar if another CPU is screwing around when we are we "tailcall" dtrace_dynvar to try again
[04:25:10] <richlowe> notice how his (buggered) stack has two entries for dtrace_dynvar for the same args, and the offset seems likely correct for the "tail" call
[04:25:16] <richlowe> notice also that ::stackinfo is massively truncated from his dump
[04:25:55] <richlowe> what I'm not immediately sure of is a convenient way to prove that as a theory.
[04:26:19] <richlowe> but the circumstances surely all fit for it being something that silly.
[04:26:54] *** bradleymeck has joined #smartos
[04:29:07] *** bradleymeck has quit IRC
[04:30:30] *** bradleymeck has joined #smartos
[04:30:58] <richlowe> I'm about as convinced as I can be though
[04:32:16] <Licenser> richlowe I admid beforhand that I only understnad half of what you say but let my try to gasp it, two things are messing around in paralell and there is a very deep callchain involved?
[04:32:41] *** artimus has joined #smartos
[04:33:04] *** artimus is now known as Guest44928
[04:38:05] *** Guest44928 has quit IRC
[04:39:53] *** ipalreadytaken has joined #smartos
[04:40:38] <richlowe> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/dtrace/dtrace.c#1878
[04:41:06] <richlowe> and then blowing the stack in the most obvious fashion
[04:49:45] *** szaydel has quit IRC
[04:50:50] <Licenser> hmm so it's a real bug o.O
[04:53:53] *** szaydel has joined #smartos
[04:58:10] *** marsell has joined #smartos
[05:04:18] *** denizr has quit IRC
[05:11:21] *** szaydel has quit IRC
[05:20:22] <rmustacc> richlowe: Thanks for taking a look at that. I'll try and get that off to Bryan so he can take a look tomorrow. Hopefully he will.
[05:20:44] <rmustacc> richlowe: disable-apix=true should be effective, depends on what you're trying to make it effective against.
[05:23:30] <Licenser> we should give trentster  a 'I broke Solaris' T-Shirt
[05:23:53] <richlowe> rmustacc: I filed 3599, and am finding a way to test the obvious fix
[05:23:57] <trentster> lol
[05:24:16] <Licenser> richlowe give it trentster, if someone can break it agian it's him
[05:25:16] <richlowe> trentster: oh, and if -Bdisable-apix=true is effecting, that should let your other system run newer smartos
[05:25:26] <richlowe> uh, effictive, even.
[05:26:20] <trentster> Dear bug, kneel before me, " I hereby night thee sir MegaBug"
[05:27:46] <rmustacc> richlowe: I've definetely used it several times previously. I think I even suggested it previously for the apix bug that Trentster was hitting.
[05:28:26] <Licenser> I wonder why we're the frist people hit by the dtrace thing o.O
[05:29:02] <trentster> richlowe: thanks for the verifying that it is indeed a bug and confirming its not just a case of licenser and myself smoking our socks again :-D
[05:30:01] <trentster> richlowe: rmustacc yeah i haven't tried the -Bdisable-apix=true yet, but I will soon as I have a gap to power down the vm's on that node and test it.
[05:31:30] <richlowe> Licenser: same reason I can't work out how to test it, the level of activity that'd be required to recurse so damn deep.  (presuming I'm not totally crazy and wrong)
[05:34:15] <trentster> rmustacc: richlowe pls let me know if you think Bryan will want the dump, and I can start to upload it somewhere.
[05:34:38] <trentster> but as you mentioned you don't think the dump will help..
[05:34:59] *** szaydel has joined #smartos
[05:36:42] <rmustacc> Not sure what he'll want or if he'll get around to it, but he generally does.
[05:38:12] <rmustacc> richlowe: Did you include bmc as a watcher on that ticket?
[05:38:28] <rmustacc> Just trying to figure out if I should forward it on to him or not.
[05:39:28] <richlowe> rmustacc: I did, but I'm never sure if or when he pays attention to anything.
[05:44:41] *** szaydel has quit IRC
[06:05:53] *** ipalreadytaken has quit IRC
[06:10:28] *** papertigers_lapt has quit IRC
[06:28:12] *** jamesd has quit IRC
[06:30:12] *** wolfeidau has quit IRC
[06:31:28] *** ivan\_ has joined #smartos
[06:32:10] *** ivan\ has quit IRC
[06:33:47] *** ivan\_ is now known as ivan\
[06:36:25] *** ipalreadytaken has joined #smartos
[06:44:57] *** papertigers_lapt has joined #smartos
[06:45:51] *** ipalreadytaken has quit IRC
[06:49:27] *** papertigers_lapt has quit IRC
[06:49:32] *** papertig_ has joined #smartos
[06:50:30] *** wolfeidau has joined #smartos
[06:58:46] *** des2 has quit IRC
[07:03:58] *** papertig_ has quit IRC
[07:05:25] *** des2 has joined #smartos
[07:07:18] *** nefilim has quit IRC
[07:12:13] *** enmand has quit IRC
[07:15:25] *** ipalreadytaken has joined #smartos
[08:02:45] *** porkbelt has joined #smartos
[08:37:31] *** mamash has joined #smartos
[08:40:33] *** alucardX has joined #smartos
[08:53:30] *** chh has joined #smartos
[09:14:00] *** alcir has joined #smartos
[09:16:58] *** serengeti has joined #smartos
[09:20:03] *** serengeti has left #smartos
[09:20:17] *** texarcana has quit IRC
[09:21:33] *** texarcana has joined #smartos
[09:33:39] *** abhishekvasisht has joined #smartos
[09:33:51] *** jamesd has joined #smartos
[09:33:53] *** abhishekvasisht has quit IRC
[09:36:15] *** bens1 has joined #smartos
[09:39:44] *** jamesd has quit IRC
[09:47:33] *** ipalreadytaken has quit IRC
[09:51:07] *** bluezenix has joined #smartos
[09:57:24] *** KermitTheFragger has joined #smartos
[10:11:05] *** cornet has left #smartos
[10:28:37] *** xenol has quit IRC
[10:28:53] *** xenol has joined #smartos
[10:32:00] *** Azbruh has quit IRC
[10:33:16] *** Azbruh has joined #smartos
[10:44:35] *** Andy has joined #smartos
[11:12:51] *** bluezenix1 has joined #smartos
[11:16:42] *** bluezenix has quit IRC
[11:48:32] *** ipalreadytaken has joined #smartos
[12:38:33] *** nikolam has joined #smartos
[13:07:47] *** nikolam has quit IRC
[13:12:01] *** nikolam has joined #smartos
[13:12:52] *** nikolam has quit IRC
[13:27:27] *** alucardX has quit IRC
[13:35:12] *** szaydel has joined #smartos
[13:37:04] *** leecallen35 has joined #smartos
[13:37:05] *** leecallen has quit IRC
[13:43:43] *** kamilr has joined #smartos
[13:43:46] <kamilr> Hi there
[13:44:31] <kamilr> I had zpool 100GB, it was to small so i have extended it to 200GB
[13:44:44] <kamilr> And now when i try to create VM i got this:
[13:44:48] <kamilr> [root@e8-9a-8f-a0-13-44 /data]# vmadm create -f linux.json
[13:44:48] <kamilr> Command failed: cannot create 'data/687e68ca-ed6a-4552-b265-cadadcb9f96f-disk0': 'refreservation' is greater than current volume size
[13:45:04] <kamilr> but zfs shows me 100GB of free space
[13:46:33] <kamilr> any ideas?
[13:46:42] <szaydel> kamilr: You need to look at refreservation. `zfs get -o space` and zfs get refreservation name/of/dataset
[13:48:03] <kamilr> The data pool has "data  refreservation        none                    default"
[13:48:07] *** dn2k is now known as dn2k2
[13:48:09] *** dn2k2 is now known as dn2k
[13:49:59] <kamilr> When i enter zfs create -V 50G data/test
[13:50:03] <kamilr> it is created
[13:50:07] <kamilr> without problems
[13:51:25] <kamilr> in my manifest for VM i have "image_size": 20000
[13:51:28] <kamilr> only 20G
[13:51:34] <kamilr> so i don't understand the problem
[13:54:36] *** krisa has joined #smartos
[13:59:35] <szaydel> try a much smaller image_size out of curiosity.
[14:03:17] <kamilr> i allready tried
[14:03:21] <kamilr> 10G is ok
[14:03:23] <MerlinDMC> size not image_size
[14:03:24] <kamilr> 20G no
[14:03:32] <kamilr> i tried both
[14:03:57] <kamilr> with size i got
[14:03:59] <kamilr> Missing required properties: disks.0.image_size
[14:04:00] <MerlinDMC> image_size only if you use image_uuid also ... and then it should match the manifest of the dataset you're using
[14:04:15] <kamilr> hm...
[14:07:32] *** jamesd has joined #smartos
[14:07:45] <kamilr> so here is mistake http://wiki.smartos.org/display/DOC/How+to+create+a+KVM+VM+%28+Hypervisor+virtualized+machine+%29+in+SmartOS ?
[14:07:57] <kamilr> i mean
[14:07:58] <kamilr>   "disks": [
[14:07:58] <kamilr>     {
[14:07:58] <kamilr>       "image_uuid": "e483afce-10b2-11e1-86bc-ff468add832f",
[14:07:58] <kamilr>       "boot": true,
[14:07:58] <kamilr>       "model": "virtio",
[14:07:59] <kamilr>       "size": 10240
[14:08:01] <kamilr>     }
[14:08:03] <kamilr>   ]
[14:08:08] <kamilr> shouldn't be image_size ?
[14:08:57] <MerlinDMC> yes it has to be image_size
[14:15:06] <kamilr> hm...
[14:15:24] <kamilr> is it hardcoded that i can create KVM vm with only 10240 MB ?
[14:15:46] *** ira has joined #smartos
[14:15:49] <kamilr> when i give 1024G more, then i go this error
[14:16:13] <kamilr> got*
[14:16:56] <kamilr> in dsmanifest i have "image_size": "641"
[14:17:11] <kamilr> 1024M not 1024G ;-)
[14:18:26] *** enmand has joined #smartos
[14:29:08] *** kschiess has joined #smartos
[14:29:19] <natefoo> so i'm using policy-based routing on my network hardware to forward packets to an interface used by a native VM i was hoping to use for NAT.
[14:29:57] <natefoo> but unless i am missing something, there is not going to be a way to get crossbow to forward those packets to the vnic in the correct zone.
[14:30:38] <natefoo> maybe with ipf in the GZ.
[15:02:49] *** serengeti has joined #smartos
[15:04:59] *** serengeti has left #smartos
[15:15:05] *** artimus has joined #smartos
[15:15:28] *** artimus is now known as Guest34187
[15:15:36] *** khushildep has joined #smartos
[15:17:28] *** enmand has quit IRC
[15:17:48] *** bens1 has quit IRC
[15:24:00] *** enmand has joined #smartos
[15:38:04] *** axonpoet has quit IRC
[15:38:51] *** neophenix has joined #smartos
[15:39:50] *** chh has quit IRC
[15:45:25] <jefferai> is ZFS in SmartOS considered stable?
[15:46:12] <jperkin> I should certainly hope so ;)
[15:46:29] <jefferai> Well
[15:46:30] <EMH_Mark3> it's a fork from opensolaris, so I guess so
[15:46:39] <jefferai> I got a new system up and running two days ago
[15:46:48] <jefferai> yesterday ZFS was complaining about unrecoverable errors
[15:46:56] <jefferai> ran a scrub, it found even more errors
[15:46:58] <jefferai> so I complained to the hoster
[15:47:03] <jefferai> who ran a full hardware diagnostic
[15:47:04] <jefferai> and found nothing
[15:47:06] <nahamu> "who you gonna believe? ZFS or a hard drive?"
[15:47:14] <szaydel> It is surely a hardware issue. :)
[15:47:23] <szaydel> That's why we use ZFS in the first place.
[15:47:26] <szaydel> Drives lie.
[15:47:28] <yofuh> i could think of a driver issue also
[15:47:29] <jefferai> nahamu: well, I'd say ZFS, but the problem is thatI'm not sure that I can convince the hoster of that
[15:47:55] <jefferai> iostat -E did not show any errors other than unrecognized command errors
[15:48:04] <szaydel> So, problem is often that drives either under-report, or what they do report is not interpreted correctly.
[15:48:04] <yofuh> if the driver get things wrong, it would at least explain why both disks got the same errors
[15:48:19] <nahamu> yofuh makes a good point
[15:48:28] <nahamu> what controller are you using?
[15:48:29] <szaydel> Far too often they do signal problems, but those who observe this diagnostic data do not understand its meaning.
[15:48:46] *** denizr has joined #smartos
[15:48:53] <jefferai> nahamu: whatever was built onto the motherboard on the box that the hoster is using
[15:48:54] *** mamash has left #smartos
[15:49:00] <jefferai> if there's a way to check, I'm open to suggestions
[15:49:16] <nahamu> yeah, something with prtconf...
[15:49:30] <yofuh> jefferai: start with smbios, to see what hardware you are using and if there is ecc on etc.
[15:50:00] <jefferai> yofuh: there is ECC RAM and I've verified in the BIOS at some point when I had access to it that it's on
[15:50:10] <jefferai> actually, the bios has it on "Auto", but the only other option is "Disabled"
[15:50:33] <szaydel> jefferai: Are you accessing global zone, or using Smart Machines?
[15:50:42] <jefferai> so, it's an ASUS P8BWS
[15:50:48] <jefferai> szaydel: both
[15:51:16] <szaydel> OK
[15:51:59] <Alasdairrr> jefferai: are you doing the RAID with ZFS or via the mobo's hardware RAID (asusming you have more than 1 disk)?
[15:52:22] <jefferai> ZFS
[15:52:26] <jefferai> two-disk mirror
[15:52:44] <Alasdairrr> the mobo claims to have 6 sata ports, two 6Gbps and two 3Gbps
[15:52:51] <Alasdairrr> you could try asking the host to swap the cables onto the 3Gbps ports
[15:53:27] <yofuh> in the other news... i'm seeing all snapshots of all zvol that appear on the zones pool, in one zone. i got an other zpool, i don't see snapshots from this pool, i dont see snapshots from datasets of type filesystem and i don't see the snapshot in any other zone and have confgured nothing special to that zone which is seeing the snapshots (it's filesystem is not even on the zones pool). anyone any idea why that happens or at least seen such behaviour?
[15:53:29] <Alasdairrr> The Intel C206 chipset is fairly new, this could very well be a buggy driver scenario
[15:53:31] <szaydel> I would ask your host what a "FULL" diagnostic actually is.
[15:53:40] <jefferai> Alasdairrr: that's a good idea
[15:53:48] <jefferai> Alasdairrr: although 2+ 2 != 6
[15:53:50] <jefferai> :-)
[15:53:53] <jefferai> szaydel: Yeah, I can do that too
[15:54:04] <jefferai> I do know that the diagnostic system is Linux-based
[15:54:16] <Alasdairrr> "Additionally, the C206 comes with two SATA 6Gb/s and four SATA 3Gb/s ports"
[15:54:23] <szaydel> Well, if it is like memtest, it is surely not a lot.
[15:54:42] <szaydel> If it is some sort of a stress test tool, also obviously not enough.
[15:55:01] <szaydel> And again, I will say that drives do report a lot, and often this data is not understood.
[15:55:44] <jefferai> sure
[15:55:51] * jefferai looks for a block diagram in the manual
[15:57:19] <jefferai> so at least it's Intel SATA chips
[15:57:22] <jefferai> not something totally random
[15:57:50] <jefferai> Alasdairrr: I can ask them to swap the cables, but if someone wants to try to figure out if it's a buggy driver scenario, I am also happy to work with someone to try to figure that out
[15:58:29] <Alasdairrr> jefferai: That might be a struggle, the people who work on drivers for illumos tend to also work on complex subsystems and as a consequence be quite busy
[15:58:33] <nahamu> My home machine has a C206 chipset and has a pair of SSDs plugged in to the 6GB/s ports and I haven't had any issues.
[15:58:35] <Alasdairrr> (from what I've observed anyway!)
[15:58:57] <Alasdairrr> jefferai: are you seeing issues on both ports? or just one?
[15:59:01] <Alasdairrr> ports/drives
[15:59:06] <nahamu> err, no. C204... hrm
[15:59:18] <jefferai> on both drives I see Illegal Request errors from iostate -E
[15:59:22] <jefferai> er, iostat -E
[15:59:23] <jefferai> no other errors
[15:59:43] <jefferai> and FWIW I also see Illegal Request errors on the USB stick that's plugged into it
[16:00:06] <Alasdairrr> illegal request errors aren't usually a big deal
[16:00:13] <jefferai> right
[16:00:28] <Alasdairrr> but usually they only come from things like smartctl
[16:00:46] <jefferai> smartctl isn't running
[16:00:47] <Alasdairrr> i haven't seen any illegal request errors in a normal usage scenario, so it again might indicate a driver issue
[16:00:51] <jefferai> but the number does go up
[16:00:57] <szaydel> What about `fmdump`,  are you seeing anything there?
[16:01:15] <jefferai> I see a lot of things, although I'm not sure how to interpret it
[16:01:17] <nahamu> my machine has some Illegal Request errors but is behaving just fine: http://paste.ec/?9cf350d6e9da8a30#JramF8xS+jigo1RlCaFu9F+OuwcbcMWVEzmoLsSrLMA=
[16:01:36] <jefferai> http://paste.kde.org/684950/
[16:02:45] *** khushildep has quit IRC
[16:03:37] <jefferai> additionally: http://paste.kde.org/684956/
[16:03:37] *** tonyarkles has joined #smartos
[16:05:03] <szaydel> Those checksum errors are clearly indicative that some bits are getting flipped at some point.
[16:05:35] <EMH_Mark3> on an unrelated note, does anyone else have issues with nfs performance in kvms? I'm getting 100MB/s top vs 400MB/s in os vm. vnic is virtio, and os is stock joylent-built ubuntu
[16:06:12] <nahamu> EMH_Mark3: are you talking about as a client or as a server?
[16:06:58] <nahamu> even with virtio, I'd expect to run into a performance ceiling on a KVM VM that would be much lower than for a zone.
[16:07:04] <EMH_Mark3> nahamu: client. trying to read data from gz into kvm
[16:07:25] <EMH_Mark3> cpu usage is getting maxed out in vm
[16:09:39] <nahamu> Perhaps walk through Brendan's USE method checklist? http://dtrace.org/blogs/brendan/2012/03/07/the-use-method-linux-performance-checklist/
[16:10:09] <rmustacc> EMH_Mark3: https://github.com/joyent/illumos-kvm/issues/12
[16:10:26] <nahamu> or that
[16:11:40] <krisa> Hi there, Do you guys know why vnic(net0) shown as '?' under "dladm show-link", i couldn't do anything to this link under gz
[16:12:16] <EMH_Mark3> rmustacc: well at least I'm not getting THAT slow :)
[16:12:45] <rmustacc> krisa: Why the link has a ? in the zone itself?
[16:13:14] <rmustacc> In the GZ you need to use -z <zone>
[16:13:16] <krisa> LINK        CLASS     MTU    STATE    BRIDGE     OVER
[16:13:16] <krisa> e1000g0     phys      1500   up       vmwarebr   --
[16:13:16] <krisa> vmwarebr0   bridge    1500   up       --         e1000g0
[16:13:16] <krisa> net0        vnic      1500   ?        --         e1000g0
[16:13:36] <rmustacc> Please don't paste command output into the channel in the future and use something like a gist or pastebin.
[16:13:43] <krisa> sorry
[16:13:48] <rmustacc> It's fine.
[16:14:51] <rmustacc> I would guess because the GZ gave the nic to a zone that you don't see it there.
[16:15:02] <rmustacc> However, if you run dladm show-link inside the corresponding zone, it will show as up.
[16:15:09] *** CarlosC has joined #smartos
[16:15:30] <krisa> yes that's correct
[16:17:19] *** vsomes__ has quit IRC
[16:17:20] <krisa> according to this site http://dtrace.org/blogs/brendan/2012/12/19/the-use-method-smartos-performance-checklist/
[16:17:22] <rmustacc> I'm not sure that it can know the state given the fact that it's been given to the zone's networking stack.
[16:17:42] <krisa> I just want to see link throughput from GZ
[16:18:06] <rmustacc> Best way is to grab nicstat and use that. We really just need to ship it in the image.
[16:18:33] <krisa> that would be cool
[16:20:40] *** bens1 has joined #smartos
[16:22:25] *** nefilim has joined #smartos
[16:23:34] <jefferai> szaydel: EMH_Mark3: nahamu: yofuh: Sorry, to circle back around to my issue...I really, really don't know what to do
[16:23:45] <jefferai> it seems I can either put Linux on the box instead and hope that the problem is a driver issue
[16:23:54] <jefferai> which isn't unreasonable since it's very new hardware
[16:24:01] <jefferai> and not specific server hardware that might be well-supported
[16:24:08] <jefferai> that's option a
[16:24:19] <jefferai> option b: argue with the hoster about their hardware being faulty, which likely won't get anywhere
[16:24:36] <szaydel> jefferai: Problem isolation is key. Can the drives be moved to a different controller?
[16:24:42] <jefferai> option c: keep SmartOS on, and ignore the ZFS errors even as the knowledge of them gnaws away at my soul
[16:24:55] <EMH_Mark3> option c isn't really an option...
[16:24:55] <jefferai> szaydel: for me to move them to a hardware controller would cost me 30 euro per month
[16:25:05] <jefferai> I can't afford it
[16:25:08] <szaydel> I mean for testing.
[16:25:13] <jefferai> hm
[16:25:19] <jefferai> Maybe
[16:25:22] <szaydel> If there is an issue, is your host willing to help you diagnose?
[16:25:38] <szaydel> I mean this is typically a diagnosis is required kinda thing.
[16:25:44] <jefferai> yeah, I know
[16:25:50] <szaydel> You have to eliminate things one at a time.
[16:25:53] <jefferai> maybe I could tell them that I am still seeing errors, and that I was asked by support to see if a different disk controller would help
[16:26:00] <jefferai> and see if they will "loan" me one for a month
[16:26:26] <szaydel> For example, are you positive the drives are OK? In other words, can you have 2 more drives added, and then use them for testing, for a period of time?
[16:26:38] <EMH_Mark3> if you could boot into a live linux cd and get similar problems, that'd go a long way to pointing towards hw problem
[16:26:52] <jefferai> EMH_Mark3: I could boot into a live cd, yes
[16:26:59] <jefferai> but since I'm not sure exactly what's causing the errors...
[16:27:04] <jefferai> If we assume that the CPU is fine
[16:27:06] <EMH_Mark3> could install zfs-for-linux and go from there
[16:27:11] <jefferai> and we assume that the ECC memory is working as designed
[16:27:28] <jefferai> EMH_Mark3: I've done zfs-on-linux and sometimes it's worked really well and other times it's worked very poorly
[16:27:30] <szaydel> Problem is that with Linux only the most severe stuff will make it into the logs, nothing else. ZFS on Linux may be a good option.
[16:27:38] <jefferai> you mean for testing?
[16:27:44] <jefferai> I'm not sure I trust zfs on linux for production, yet
[16:27:45] <EMH_Mark3> did you figure if you could enable ipmi log?
[16:28:04] <EMH_Mark3> jefferai: I meant live linux for testing
[16:28:07] <jefferai> sure
[16:28:07] <EMH_Mark3> to see if you get same checksum errors
[16:28:14] <jefferai> I could overwrite the usb stick in the server with a live linux distro
[16:28:18] <jefferai> would have to find one with zfs on linux
[16:28:19] <jperkin> I know folks with absolutely gobs of storage on zfs for linux, it's very stable.
[16:28:31] <jefferai> jperkin: I've had severe problems with it
[16:28:53] <jefferai> like, where the write speed drops (no compression, no dedup) to ~30KB/sec
[16:29:05] <jefferai> granted, inside VMs
[16:29:54] *** KermitTheFragger has quit IRC
[16:30:42] <jefferai> but, multiple VMs
[16:30:46] <szaydel> jefferai: I am not sure I have seen much testing with KVM, which I am assuming you are using, since you mentioned inside VMs. Or, do you mean you have a Linux guest, behind say a SmartOS system, and you install ZFS on it?
[16:31:16] <jefferai> I've had a linux host running Ubuntu 12.04 with linux guests running Ubuntu 12.04
[16:31:28] <jefferai> in the guests, I have / on ext4 and /storage on ZFS-on-linux (latest)
[16:31:55] <jefferai> I've talked to the zfsonlinux guys, nobody has any clue
[16:31:58] <jefferai>  /storage writes at about 30KB/sec, while / writes at about 10MB/s
[16:32:06] <szaydel> But the guests are on SmartOS or other Illumos-based distro?
[16:32:07] <jefferai> (sorry, that got lost by my client since it started with /)
[16:32:12] <jefferai> no, this is totally separate
[16:32:20] <jefferai> from smartos, or my current issue on this box
[16:32:24] <jefferai> just, in the past, my experience with zfsonlinux
[16:32:39] <jefferai> the guests are Ubuntu 12.04, on an Ubuntu 12.04 host
[16:32:52] <szaydel> OK, so scratch that for now. Point was to do testing and see if same checksum errors will appear.
[16:34:01] <jefferai> szaydel: that's a totally different box on a totally different network
[16:34:04] <jefferai> no common hardware
[16:34:08] <jefferai> so, I can do testing
[16:34:15] <jefferai> I'm not sure how to try to cause the checksum errors
[16:34:22] <jefferai> but I could write lots of files and delte them, and so on
[16:34:27] <szaydel> Right, just do functionality, not performance testing.
[16:34:35] <szaydel> See if you can expose same checksum errors.
[16:34:50] <jefferai> yeah
[16:35:21] <nefilim> wonder if its even remotely related to my issue: https://github.com/joyent/illumos-kvm/issues/12
[16:37:33] *** scarcry has quit IRC
[16:38:20] <jefferai> szaydel: turns out the gentoo livedvd can be copied to a usbstick and comes with zfsonlinux built in, so I will boot off of that, wipe my zfs pool, recreate one, and see how it goes
[16:40:24] <EMH_Mark3> nefilim: I get speeds as crappy as that guy when I use very large rsize like he does... best speed I get is when I use rsize=8192,wsize=8192
[16:40:25] <szaydel> That's a good option for sure.
[16:40:46] <EMH_Mark3> jefferai: you can probably just import your existing pool
[16:40:58] <EMH_Mark3> might need to be imported with altroot tho
[16:40:59] <jefferai> but it has a ton of errors
[16:41:12] <szaydel> Yeah, I'd say do a fresh start.
[16:41:15] <jefferai> how would I know if errors were pre-existing or not
[16:41:22] <szaydel> Make sure slate is clean and go from there.
[16:41:26] <jefferai> yeah
[16:42:00] <EMH_Mark3> point. when I had problems, it was checksum issues only, which could be cleared with zpool clear
[16:42:15] <jefferai> I didn't actually try zpool clear
[16:42:17] <jefferai> I did try a scrub
[16:42:29] <jefferai> but it said it had permanent errors
[16:43:55] <EMH_Mark3> yeah my error wern't that bad. starting fresh might be best thing to do
[16:44:12] <jefferai> is there a way to find out the flags used at creation time?
[16:44:21] <jefferai> if possible I'd like the new pool to reflect the old as much as possible
[16:44:40] *** bens1 has quit IRC
[16:44:42] *** Meths has quit IRC
[16:44:43] *** spaam has quit IRC
[16:44:44] *** _lb_ has quit IRC
[16:44:46] *** deraps has quit IRC
[16:44:46] *** Esmil has quit IRC
[16:45:13] <EMH_Mark3> it's in the smartos create script
[16:45:42] *** bens1 has joined #smartos
[16:45:42] *** _lb_ has joined #smartos
[16:45:42] *** Meths has joined #smartos
[16:45:43] *** spaam has joined #smartos
[16:45:43] *** Esmil has joined #smartos
[16:45:43] *** deraps has joined #smartos
[16:46:03] <jefferai> ok
[16:46:11] <jefferai> I think that's in github in the overlay IIRC
[16:46:13] <EMH_Mark3> can't remember where it's at...
[16:46:28] *** krisa has quit IRC
[16:46:30] <jefferai> at least, that's where the stuff is that prompts you for info to create /usbkey/config
[16:46:35] <jefferai> so it must be there
[16:46:51] <EMH_Mark3> right. there's separate options for the pool and the filesystems
[16:47:05] <EMH_Mark3> only thing I remember is that it was setting noatime on the fs
[16:59:04] *** khushildep has joined #smartos
[16:59:44] *** ryancnelson has joined #smartos
[17:02:33] <yofuh> anyone here who can tell my something about how /usr/lib/brand/joyent/platform.xml got applied? i've got a zone where the <device match="zvol/dsk/%P/%z/*" /> and <device match="zvol/rdsk/%P/%z/*" /> get expanded to the wrong devies (if %P is pool, we got the wrong pool and if %z is the zone, we got the wrong zone also)
[17:06:26] *** jim80net has joined #smartos
[17:21:32] <yofuh> so, %P is: svccfg -s smartdc/init listprop '*/zpool'
[17:21:37] <yofuh> that is so wrong...
[17:27:38] *** bcn37 has joined #smartos
[17:27:58] <natefoo> apologies for the repeat, i think everyone was asleep when i brought this up earler:
[17:28:14] <natefoo> i'm using policy-based routing on my network hardware to forward packets to an interface used by a native VM i was hoping to use for NAT.
[17:28:29] <natefoo> unless i am missing something, there is not going to be a way to get crossbow to forward those packets to the vnic in the correct zone.
[17:29:23] <ryancnelson> you're using policy-based routing to send *packets*, or *etherframes*?  what layer are we talking about here?
[17:29:28] *** bradleymeck has quit IRC
[17:30:02] <natefoo> packets.
[17:30:29] <natefoo> or at least that's what extreme calls them in the documentation, i'll double check that they're not lying.
[17:30:58] <ryancnelson> that sounds reasonable… just figuring out our terms here, first :)
[17:30:59] <ryancnelson> ok… and you want to use your vm as a nat router?
[17:31:07] <natefoo> yep.
[17:31:08] <ryancnelson> or something?
[17:31:16] <ryancnelson> did you turn off anti-spoof?
[17:31:30] <ryancnelson> you know what i'm talking about?
[17:31:32] <natefoo> yes.
[17:31:56] <natefoo> i haven't gotten quite that far yet, but i saw those options and was going to turn them off.
[17:32:54] <ryancnelson> so, then you'll be fine… your juniper is going to say "what's next hop for this packet?" , and look up "oh, it's that ip of the vm over there"… which is on the same subnet as one of it's interfaces
[17:32:57] <natefoo> the concerning part is that the router isn't rewriting the destination address (which would be required for NAT to work anyway), it just sends the packets to a different interface on the switch.
[17:33:13] <natefoo> s/concerning/key/
[17:33:31] <ryancnelson> … so it arps for that IP, and the *vnic* responds with it's mac address.
[17:33:41] <natefoo> yeah.
[17:33:49] <ryancnelson> you're not talking to the global zone, you're talking *thru* it
[17:33:57] <natefoo> right.
[17:34:14] <ryancnelson> it's like there's a teeny dumb hub inside your ethernet cable, no?
[17:34:15] <natefoo> okay, so the packets are delivered to the right ethernet address.
[17:34:23] <natefoo> which is the vnic.
[17:34:26] <ryancnelson> yes
[17:34:38] *** dap has joined #smartos
[17:34:43] <ryancnelson> at any rate, i use zones/vms as nat gateways *all the time*
[17:34:48] <natefoo> i wasn't thinking far enough down the osi burrito. ;)
[17:35:04] <natefoo> this is a much less traditional setup though, i was planning to only have one IP interface on this.
[17:35:08] *** kamilr has quit IRC
[17:35:09] <natefoo> the public/nat IP.
[17:35:23] <natefoo> basically what cisco calls nat on a stick.
[17:35:36] <ryancnelson> … i'm doing something called "forced March", which is a blog entry every day in march.  A howto on "make a nat router zone" is probably a good one to start with
[17:35:58] <ryancnelson> yeah, one-legged box should still be ok
[17:36:10] <ryancnelson> … so your private network is all inside the box
[17:36:26] <ryancnelson> … in which case, maybe you make the global zone be your natting thingy
[17:36:50] <natefoo> yeah i thought about doing nat in the GZ, cept that it doesn't have a public interface right now..
[17:37:06] <natefoo> the private network is all outside the box, except that the GZ's admin interface is on the private network.
[17:37:13] <natefoo> actually there are multiple private networks.
[17:37:31] <natefoo> so the reasoning here is that i don't want to create an interface in the NAT zone for every single private network we make.
[17:37:54] *** iyp has joined #smartos
[17:37:55] <natefoo> why solve with systems what you can solve with fancy network hardware. ;)
[17:37:55] <iyp> poiu
[17:38:08] <iyp> err
[17:38:24] <iyp> I have a compute node coming up with a duplicate IP on the admin network.
[17:38:47] <iyp> The dhcpd zone handles giving those out, right? Any reccomendations on a fix?
[17:39:34] <ryancnelson> so, anyway… to your original question about "making crossbow do this"… it's not really crossbow, unless you're running illumos stuff in your vm… it's just "put that vnic on the right segment", then use whatever the os in that vm does.  I've built/seen smoothwall and pfsense vms work well in a smartos-vm
[17:39:38] *** alcir has quit IRC
[17:40:02] <ryancnelson> iyp, if you're talking about "dhcpd zone", you mean SDC, right?
[17:40:17] <iyp> yessir
[17:40:46] <natefoo> yeah, i was thinking that the packets would not be handed to the VM because they weren't addressed to the VM, but i wasn't thinking correctly that they are delivered at layer 2, not layer 3.
[17:41:18] <ryancnelson> the dhcpd zone does, in fact, hand out ip's to your compute nodes.  how'd you get a conflict?  some other device on the network?
[17:41:48] <natefoo> the vm is a native/illumos/zone, just gonna use the provided ipfilter service.
[17:41:54] <iyp> It's a clean network. Maybe I messed something up in the configuration?
[17:42:06] <natefoo> so, okay, now that i know it *should* work, i'll go try it out.
[17:42:10] <natefoo> thanks for the help. =)
[17:42:52] <ryancnelson> iyp, i doubt it… what ip address is in conflict?  something low in your range?
[17:43:08] <iyp> 10.10.0.20
[17:43:17] <iyp> I cant see anything else that has that address either
[17:43:32] <iyp> there are really only two machines plugged into that network at the moment. Head node and one compute
[17:43:50] <iyp> headnode took 10.10.0.10
[17:43:53] <ryancnelson> how do you know you have a conflict?  does ifconfig -a show DUPLICATE in the flags?
[17:44:12] <ryancnelson> can you gist your /usbkey/config file, and paste it to me privately?
[17:44:45] <iyp> When I plug in to the compute, the duplicate error gets spit out repeatedly on screen
[17:44:50] <iyp> gisting
[17:46:30] *** bcn37 has quit IRC
[17:48:34] <iyp> ryancnelson: sent it, sorry for the delay
[18:17:46] *** bradleymeck has joined #smartos
[18:19:09] *** mamash has joined #smartos
[18:19:49] *** bradleymeck has quit IRC
[18:21:51] *** ryancnelson has quit IRC
[18:24:47] *** potatosalad has joined #smartos
[18:34:53] <_lb_> Hi! I am having a bit of trouble setting syslogd to forward logs to the outside world...
[18:36:34] <_lb_> I am supposing syntax is same as in BSD... So I am appending "*.*          @log.server.net:12345" at the end of /etc/syslog.conf
[18:36:47] <_lb_> Is that the "smart" way to do it?
[18:40:50] *** axonpoet has joined #smartos
[18:41:03] *** ryancnelson has joined #smartos
[18:41:30] *** iyp has quit IRC
[18:45:27] *** ksalman has quit IRC
[18:45:40] *** ksalman has joined #smartos
[18:52:22] *** ryancnelson has left #smartos
[18:54:42] *** iyp has joined #smartos
[18:56:16] *** Cpt-Oblivious has joined #smartos
[19:05:19] *** estibi has left #smartos
[19:06:14] *** wolstena has joined #smartos
[19:07:52] *** Triluch has quit IRC
[19:19:09] *** ipalreadytaken has quit IRC
[19:19:23] *** ipalreadytaken has joined #smartos
[19:26:41] *** porkbelt has quit IRC
[19:28:14] *** tallship has quit IRC
[19:31:15] *** denizr has quit IRC
[19:45:46] *** ira has quit IRC
[19:48:39] *** dysinger has joined #smartos
[19:50:30] *** dysinger has quit IRC
[19:57:09] *** porkbelt has joined #smartos
[19:58:13] *** iyp has quit IRC
[20:04:01] *** denizr has joined #smartos
[20:11:01] *** szaydel has quit IRC
[20:12:15] *** tonyarkles has quit IRC
[20:12:40] *** axonpoet has quit IRC
[20:13:17] *** iyp has joined #smartos
[20:16:44] *** szaydel has joined #smartos
[20:24:50] *** bluezenix1 has quit IRC
[20:46:04] *** amuldowney has joined #smartos
[20:47:23] *** neophenix has quit IRC
[20:47:41] *** ipalreadytaken has quit IRC
[20:47:58] <amuldowney> I have two physical machines with a direct connection between two NICs, each on the external0 interface.  Despite the link being seen as up, they can't talk to each other.  ifconfig is fine, routes are fine, but there is nothing in the ARP table.  snoop shows no traffic received.  Any suggestions on what to check?
[20:50:07] <EMH_Mark3> are they on same subnet? do they have different ips?
[20:50:45] <amuldowney> Same subnet, different IPs
[20:51:23] <EMH_Mark3> well I'm stumped. :)
[20:51:33] <amuldowney> They are just directly connected.  The physical interface bounces as it should when I reboot one, then re-negotiates to 1000/full.
[20:51:40] *** axonpoet has joined #smartos
[20:53:52] *** ryancnelson has joined #smartos
[21:07:05] <trentster> ryancnelson: That "Forced March" assuming you are not kidding is gonna need a ton of discipline, I am interested to hear about your mileage ;-)
[21:07:57] <ryancnelson> last year, i maybe got 9 out of 30 days... hoping to do much better this year
[21:10:54] <trentster> ryancnelson: the zones based firewall article would be cool, i know there are a ton of people interested in it. It would also be cool if there was some exisiting basic web ui could eb adapted for it to make changes. I dont think thats going to happen as I did some googling for it, and seems that most of the project that used to support ipfw have moved onto "pf"
[21:16:26] <EMH_Mark3> isn't there a post on the wiki about that?
[21:17:25] <EMH_Mark3> ah no it was done using a kvm.
[21:17:36] <EMH_Mark3> and it's on some dude's site. http://be.groovie.org/2012/09/17/trying_out_smartos_and_openindiana.html
[21:18:20] <natefoo> ryancnelson: great success with the nat stuff, thanks again.
[21:20:21] *** bluezenix has joined #smartos
[21:23:21] *** Guest34187 has quit IRC
[21:24:26] *** artimus has joined #smartos
[21:24:50] *** artimus is now known as Guest65980
[21:43:11] *** Trixboxer has joined #smartos
[21:46:38] *** kschiess has quit IRC
[21:47:50] *** ipalreadytaken has joined #smartos
[21:48:14] <nshalman> EMH_Mark3: search for NAT in the wiki
[21:48:55] <nshalman> Nevermind. You meant with a web GUI.
[21:50:18] <yofuh> anyone knows if zoneadmd is compilet with assertion disabled in smartos?
[21:50:34] <EMH_Mark3> nshalman: was replying to someone else.
[22:02:07] *** ipalreadytaken has quit IRC
[22:02:33] *** ipalreadytaken has joined #smartos
[22:05:14] <Trixboxer> hi, how can I find open ports of my os ?
[22:12:18] <ryancnelson> natefoo: worked for you?  great to hear
[22:29:52] <arai1> Checking the zfs attributes on an initial install of SmartOS .... is it me or shouldn't primarycache be turned off for zones/swap?
[22:31:26] <natefoo> ryancnelson: yes, trivial to set up on the host side.
[22:31:33] *** Azbruh has quit IRC
[22:31:33] <natefoo> network gear was a pain as network gear is.
[22:32:22] <amuldowney> Trixboxer: netstat -an
[22:32:54] <Trixboxer> amuldowney: Thanks
[22:33:17] *** Azbruh has joined #smartos
[22:33:36] <amuldowney> Trixboxer: Also wouldn't hurt to run mmap from another host
[22:34:24] <Trixboxer> yeah I ran nmap which shows port 80 and 443 as extra
[22:41:36] <amuldowney> I asked this earlier without much response.  I have an external NIC configured on two global zones, and they are directly connected to each other.  The physical interface is up on both sides.  How, no traffic is passing.  There is no ARP other than the local MAC on each machine.  Oddly, netstat -i shows packet count increases in and out when doing pings.  Any suggestions on where else to look?
[22:42:09] <amuldowney> snoop shows no traffic as well, despite increasing packet counts in netstat -i
[22:43:44] *** ipalreadytaken has quit IRC
[22:44:21] *** ipalreadytaken has joined #smartos
[22:45:14] *** ipalreadytaken has quit IRC
[22:45:39] *** ipalreadytaken has joined #smartos
[22:45:49] *** CarlosC has quit IRC
[22:46:26] *** wolstena has quit IRC
[22:47:11] *** ipalreadytaken has quit IRC
[22:50:38] *** iyp has quit IRC
[22:53:11] *** bixu has joined #smartos
[22:54:42] *** iyp has joined #smartos
[22:57:14] *** iyp has quit IRC
[23:01:09] <ryancnelson> what do you mean you "have an *external* nic configured on two global zones" ... a vnic, then?
[23:01:40] <ryancnelson> ... 'cause "external" means "vnic on the external nictag", which is contradicted by "physical interface is up"
[23:01:45] <ryancnelson> we're confusing terms here
[23:02:41] <ryancnelson> you could start by gisting your config file, dladm show-phys , dladm show-phys -m , ifconfig -a , dladm show-vnic
[23:06:49] *** Andy has quit IRC
[23:24:35] *** ira has joined #smartos
[23:27:39] *** denizr has quit IRC
[23:27:40] *** axonpoet has quit IRC
[23:30:33] *** frnthsks has joined #smartos
[23:31:13] *** wolstena has joined #smartos
[23:33:04] *** tonyarkles has joined #smartos
[23:37:21] *** mamash has left #smartos
[23:37:35] <Licenser> man installing anything but OS X in a macbook is a pain :(
[23:41:00] *** iyp has joined #smartos
[23:44:19] *** bluezenix has quit IRC
[23:45:39] *** tonyarkles has quit IRC
[23:46:21] <LeftWing> It sure is.
[23:46:57] *** bens1 has quit IRC
[23:47:07] <wesolows> so hard for AAPL to monetise those other platforms
[23:50:34] <richlowe> Licenser: did you have a crashdump from that dtrace thing, too?
[23:50:39] <LeftWing> I don't think it would make much of a difference.  The people spending money in App Stores and on Music are not the people that just want to run Linux or whatever.
[23:51:03] *** wolstena has quit IRC
[23:51:20] <Licenser> richlowe sadly not
[23:51:22] *** wolstena has joined #smartos
[23:51:32] <Licenser> but good that I see you I had an idea how to test for it (or at least somewhat)
[23:51:35] <richlowe> ah, bmc wanted a copy, and I guess it's the weekend where trentster is.
[23:52:10] <ryancnelson> and conversely, the linux folks aren't paying for macbooks to run it on.  like sparcstations, the only macbooks that're running an OS they didn't come with are secondhand ones
[23:52:13] <Licenser> the main question was when I am not mistaken: does the compiler do TCO
[23:53:39] <Licenser> so what could be tested is a simple case where with a function that has somewhat the same body an heck if it does TCO with the given options
[23:53:46] <Licenser> it's far fetched but at least could work as a positive
top

   March 1, 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 | >