[01:11] *** Webhostbudd has joined #arpnetworks [01:40] *** gcw|mini1 has joined #arpnetworks [01:42] *** LT has joined #arpnetworks [01:42] *** gcw|mbpro has quit IRC (Ping timeout: 246 seconds) [02:16] *** Webhostbudd has quit IRC (Ping timeout: 250 seconds) [06:33] *** fink has joined #arpnetworks [06:36] jlgaddis: no web frontend to powerdns, it just powers my Reverse DNS manager [06:38] jdoe: mercutio : the comparable Intel stuff is sexy too, but way expensive [06:43] up_the_irons: do the new cpus support bulldozer? [06:43] err i mean are they bulldozer [06:45] i actually have no ideahow much cpu ssh would be taking up [06:45] but i like the idea of it being accelerated :0 [06:47] mercutio: they are bulldozer, yes. would ssh even take advantage of the hardware aes-ni? like, how would it know it's there.. probably need a new version of ssh [06:50] if it's anything like the old VIA AES instructions it just requires the right openssl setup for most things to use it [06:51] ah cool [06:53] 'openssl engine' [06:55] *** irons|xchat has quit IRC (Ping timeout: 246 seconds) [06:56] *** HighJinx has quit IRC (*.net *.split) [06:56] *** arenlor has quit IRC (*.net *.split) [06:56] *** teneightypea_ has quit IRC (*.net *.split) [06:56] *** dferris has quit IRC (*.net *.split) [06:56] *** Igneous has quit IRC (*.net *.split) [06:56] up_the_irons: openssl needs to be up to date [06:57] *** arenlor has joined #arpnetworks [06:57] lt: ubuntu doesn't show it in openssl engine now [06:57] do you have one of those cpus now? [06:57] *** HighJinx has joined #arpnetworks [06:57] *** dferris has joined #arpnetworks [06:57] *** Igneous has joined #arpnetworks [06:57] openssl speed -evp aes-256-cbc [06:57] you want to run that command [06:58] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [06:58] *** teneightypea has joined #arpnetworks [06:58] aes-256-cbc 202878.63k 208678.91k 206311.52k 225509.62k 222816.90k [06:58] if it's anything like as high as that it's accelerated [06:58] if it's more like: [06:58] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [06:58] aes-256-cbc 73896.75k 74157.50k 75189.17k 75321.54k 75582.84k [06:58] then it's not [07:00] hmm rhel stilll shows it in engine [07:00] aes-256-cbc 614184.36k 684397.85k 696434.09k 699525.12k 701133.83k [07:00] that's accelerated numbers :) [07:00] *** fink has quit IRC (Quit: fink) [07:00] actually i wonder if that first one is accelerating properly [07:01] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [07:01] aes-256-cbc 164786.10k 183756.50k 189753.15k 190754.71k 191059.91k [07:01] cos that's the number of non accelerated core 2 duo [07:03] actually mine wasn't accelerated... [07:03] really? [07:03] how come? [07:03] options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) [07:04] # openssl engine [07:04] (rsax) RSAX engine support [07:04] (dynamic) Dynamic engine loading support [07:04] is there something else that has to be done too? [07:05] hmm... you have me wondering now [07:06] the first number is xeon e5420 [07:07] actually xeon E5345 [07:07] model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz [07:07] and you''re like nearly 10 as fast [07:07] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [07:08] aes-256-cbc 134099.06k 152144.10k 157358.49k 158168.27k 157409.28k [07:08] e5420 is quite a bit faster [07:08] actually i wonder if i'm accelerated properly [07:10] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1001424 [07:11] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [07:12] aes-256-cbc 213802.95k 687449.25k 1094622.32k 1083138.24k 1088128.52k [07:12] oh yeah it is accelerating, I thought I could trick it by setting -engine to something else but it seems to load the engine anyway [07:12] it's a lot quicker when you pass -decrypt [07:12] -decrypt time decryption instead of encryption (only EVP). [07:13] The 'numbers' are in 1000s of bytes per second processed. [07:13] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [07:13] aes-256-cbc 59636.47k 41641.90k 141532.70k 150321.79k 152577.39k [07:13] but e5345 still sucks at decrypt [07:14] aes-256-cbc 613619.75k 1452257.90k 1860791.98k 1988995.41k 2028642.30k [07:14] lt: what cpu is that? [07:14] X5690 [07:14] hmm [07:14] oh that's really high ghz isn't it? [07:15] 3.47ghz ? [07:15] versus 2 ghz [07:16] it's the first intel series to support aes-ni i think [07:19] wow those things are expensive :/ [07:20] yes... but useful if you're stuck running something single threaded [07:21] like dos? [07:22] the new e5s latency reduction thing sounds intersting [07:22] i suppose it'll come into desktops soon [07:23] opteron 6276 seems similar speed to x5650 [07:23] e5-2690 is like 50% faster [07:23] but e5-2690 is like what the recent version of what you're using [07:23] ie: expensive :/ [07:24] it's also power hungry [07:24] http://www.anandtech.com/print/5553 [07:24] reading that [07:25] what opteron 6276 is expensive too :/ [07:26] *** fink has joined #arpnetworks [07:26] *** fink has quit IRC (Client Quit) [07:26] oh it's cheaper than X5670 [07:26] and X5690 isn't even sold here :/ [07:27] the latest new thing always is expensive - we tend to wait until the next new thing is out then buy up the best of the last generation on the cheap [07:28] ahh i see [07:28] i prefer lower spec newer stuff generally [07:28] but end up with lower spec older stuff :/ [07:29] the e5-2620 is actually pretty good value [07:30] and all the opterons seem to be branded hp [07:33] up_the_irons: what cpus are in the kvm nodes atm? kvm hides the cpu type [07:34] it says 2.641 ghz [07:34] but that's about as much [07:35] x3450? [07:35] i'm guessing it's 2.66ghz [07:36] or e5430 [07:36] or e5150 [07:45] you have to tell ssh to use aes [07:45] otherwise it defaults to blowfish [07:47] without acceleration aes256-cbc and blowfish are about the same speed and aes128-cbc is faster [07:48] and ptuty defaults to aes rater than blowfish [07:49] openssh defaults to aes128... [07:49] does it? [07:49] aes128-cbc? [07:49] Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc [07:49] i actually foudn this [07:49] commented out [07:50] blowfish isn't even in that last? [07:50] but if i change that first entry to be aes128-cbc ssh to localhost with dd'ed zero data is faster [07:50] oh hmm [07:50] that really isn't a good test is it [07:51] default is in the ssh_config man page... probably varies due to version, but aes has been preferred for many many versions [07:51] it's aes128-ctr versus aes128-cbc? [07:51] what's the diff [07:52] i was reading something old that said blowfish default :) [07:52] one is ctr mode one is cbc mode :p [07:53] ctr is meant to be easily parallelisable, cbc isn't [07:54] 209715200 bytes (210 MB) copied, 6.54909 s, 32.0 MB/s [07:54] versus [07:54] 209715200 bytes (210 MB) copied, 2.4191 s, 86.7 MB/s [07:54] and non-zero file [07:54] oh? [07:54] first is ctr second is cbc [07:54] dd if=/var/www/testfile.zip bs=1024k | ssh -c aes128-cbc root@localhost 'dd of=/dev/null' [07:55] hmm# gzip -cv /var/www/testfile.zip| wc [07:55] /var/www/testfile.zip: -0.0% 820474 4625767 209749312 [07:55] so non compressable [07:56] it would be nice to be like more than 50% faster than that :) [07:57] so that ssh can be liek gigabit speeds with encrpytion [08:04] if you want fast ssh you need the hpn version - that actually has a parallel version of aes-ctr [08:04] oh? [08:05] i don't really need faster ssh [08:05] i was just curious how much diff these acceleration things made [08:05] and i'm not getting a lot of diff [08:06] aes128-cbc is faster than aes128-ctr on xeon e5435 too though.. [08:06] maybe there's no acceleration for ctr but there is for cbc? dunno [08:06] does the hpn version work on openbsd? [08:07] xeon 5435 has no acceleration aynway [08:07] err i meant 5345 [08:08] but i think that could be right too LT [08:08] cos i foudn a rhel bug about such, i cant' acecss it though to see more about it [08:10] cbc is a pretty standard way of doing things that's been around for ages, but ctr is newer and I think the ssh people might even have invented it [08:10] hmm [08:11] well the ssh people took out the none cypher [08:11] i like the idea of encrypting auth but not data :) [08:12] the hpn version adds none back [08:12] ahh [08:13] i do slightly remember hpn from ages back [08:13] when ssh had window size limitations [08:13] that made international transfer speeds always suck [08:13] back then it was always behind ssh by quite a few verisons [08:14] http://www.cl.cam.ac.uk/~rja14/book.html is a great free book for understanding the differences between cbc, ctr, etc as an aside [08:14] cool i'll bookmark it [08:17] hmm dd over ssh is faster than scp [08:19] *** ix33 has quit IRC (Read error: Operation timed out) [08:19] i do actualyl want to understand encrpytion sometime .. especially with regards to interactive ssh type applications [08:19] *** notion has quit IRC (Read error: Operation timed out) [08:19] (ie not much data.. data could be guessed by delays between keystrokes etc) [08:19] *** notion has joined #arpnetworks [08:19] *** ix33 has joined #arpnetworks [08:58] *** LT has quit IRC (Quit: Leaving) [09:52] *** hive-min1 has quit IRC (Ping timeout: 268 seconds) [09:52] *** hive-mind has joined #arpnetworks [10:05] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [10:05] aes-256-cbc 279385.84k 277993.37k 301771.51k 318107.50k 319316.99k [10:06] mercutio: ^^ [10:06] AMD 6216 [10:09] mercutio: the kvm nodes are dual E5430's [10:12] these are numbers on the E5430's (no acceleration) [10:12] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes [10:12] aes-256-cbc 95563.29k 106319.22k 110646.64k 112421.96k 106064.11k [10:13] *** fink has joined #arpnetworks [10:14] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [10:15] jeez [10:15] Intel Xeon E5-2660 Sandy Bridge-EP 2.2GHz [10:16] *** irons|xchat has joined #arpnetworks [10:16] $1329 [10:16] all i can is [10:16] Fuck That(tm) [10:16] *say is [10:17] *** hive-mind has quit IRC (Ping timeout: 272 seconds) [10:21] *** hive-mind has joined #arpnetworks [10:26] *** hive-mind has quit IRC (Ping timeout: 240 seconds) [10:26] *** hive-mind has joined #arpnetworks [10:32] *** fink has quit IRC (Quit: fink) [10:33] *** hive-mind has quit IRC (Ping timeout: 268 seconds) [10:36] *** HighJinx has joined #arpnetworks [10:38] *** atmark has joined #arpnetworks [10:42] *** fink has joined #arpnetworks [10:46] *** hive-mind has joined #arpnetworks [10:50] *** hive-min1 has joined #arpnetworks [10:50] *** hive-mind has quit IRC (Ping timeout: 245 seconds) [10:54] *** fink has quit IRC (Quit: fink) [10:58] *** fink has joined #arpnetworks [11:02] *** gcw|mini1 has quit IRC (Remote host closed the connection) [11:02] *** fink has quit IRC (Client Quit) [11:07] *** gcw|mbpro has joined #arpnetworks [11:45] *** Webhostbudd has joined #arpnetworks [11:45] *** fink has joined #arpnetworks [13:27] *** mtve has quit IRC (Ping timeout: 244 seconds) [13:28] 3:28PM up 391 days, 17:36, 4 users, load averages: 0.05, 0.06, 0.01 [13:28] *** gcw|mbpro has quit IRC (Ping timeout: 272 seconds) [13:28] ^My ARPNetworks FreeBSD VPS...I think I'm going to be starting it from scratch soon :( [13:30] $ uptime [13:30] 13:49:07 up 958 days, 13:37, 3 users, load average: 4.09, 4.76, 4.38 [13:31] kvr04 went up to 983 days, my longest box ever [13:31] good lord [13:31] maybe this one will surpass it [13:31] am I on that box, by chance? [13:31] that's kvr05 [13:31] check your vnc host, says what box you're on [13:31] I honestly don't even know what I'm on [13:31] Roger that, one second [13:33] bah [13:33] I don't know my VNC host :\ [13:33] I thought it would be in the dashboard somewhere [13:34] oh wait, it is [13:34] I'm on kvr06 [13:34] ah [13:34] * phlux is kevinthompson [13:35] that's a long running host too [13:35] $ uptime [13:35] 13:07:43 up 934 days, 10:01, 2 users, load average: 3.10, 3.23, 3.31 [13:35] nice [13:35] Hopefully it keeps it up :P [13:35] :) [13:35] all that time with no kernel security patches :D [13:35] My ARPNetworks VPS is the hub of my entire network because of its stability [13:36] I've got VPSes from elsewhere, and they don't really compare imo [13:36] I've considered moving my entire network to ARPNetworks, but I don't know how much sense that would make for me. [13:36] phlux: :) [13:36] phlux: i say "do it" [13:36] haha, I bet! [13:37] If I could ensure that my servers were all on different hosts, I will be convinced to swap over everything. [13:37] twobitha1ker: i knew someone would say that... [13:37] Someone says that to me about my VPS, too [13:37] I tell them to go ahead and exploit it for me right quick [13:37] that's what you always hear when u try to tout uptime [13:38] phlux: LOL hahaha [13:38] They always answer "Sure give me a shell." It doesn't work that way. If I did that, I'd be giving you a head start. [13:38] phlux: well, we *do* put VMs of the same customer on different hosts, by default. [13:38] No kidding? [13:39] So if I picked up 3 more at the same time, all 3 would be on separate hosts? [13:39] this one dude got like 15 VMs, in one day, and that was the only time it was hard to make sure they all got spread out [13:39] phlux: sure of course [13:39] If so, I am going to make that change on Sep 1 (which also happens to be my birthday, yay me!) [13:39] Awesome [13:39] It's going to be so much easier paying one company :P [13:39] phlux: i understand the concern about not having all eggs in one basket, i practice that myself, so why not do it for the customers? [13:40] phlux: see if you can negotiate for an arpnetworks tshirt [13:40] * fink has tried yet failed :( [13:40] up_the_irons: I'm glad to hear that you do it that way. [13:40] lol fink [13:40] YEAH [13:40] 3 servers for 1 T-shirt [13:40] whaddya say?! [13:40] phlux: i wish i knew that was your only concern, i would have addressed it earlier :) [13:41] up_the_irons: No worries. I originally signed up a long time ago with the intention of "testing the waters," and I ended up using that VPS for *everything* [13:41] phlux: haha cool [13:42] Speaking of which, I'm teaching a guy some things, and he's most likely going to pick up a VPS from ARP in the coming days. [13:44] Hoping his introduction to programming goes smoothly..he wants to be an IT Commisioned Officer in the USCG. I'm waiting for him so we can try to go to OCS together. We're both already enlisted, so we wouldn't really be competing with eachother. [13:45] I got invited to OCS, then saw the age cutoff was 29. I officially felt old (I'm 33) [13:46] i hunger, cd $food [13:47] Dang I didn't know that the cutoff was 29 [13:47] I'm only 23 (as stated earlier, 24 soon) so I haven't had to worry about age limits for anything, yet [13:48] up_the_irons: child :D [13:49] I was considering re-careering here as a direct entry officer, but the Canadian Forces dropped signing bonuses and I couldn't afford the pay cut without one [13:50] Man, if I'd have joined a year earlier, I'd have got a signing bonus with the CG. [13:50] I became an MST (Marine Science Technician) [13:50] I deal with oil spills, HAZMAT releases, waterfront facility regulations, foreign and domestic vessel inspections, and container inspections. [13:50] That's a mouthfull. [13:50] also I suggested this possibility to my wife and her reaction was nearly as violent as I could expect in Kandahar :\ [13:50] o.O [13:53] ? [13:55] *** hive-min1 has quit IRC (Ping timeout: 240 seconds) [13:57] up_the_irons: Given that kvr05 has 934 days uptime, how is its health? [14:02] *** hive-mind has joined #arpnetworks [14:25] kraigu: lol [14:27] arenlor: health looks good; there are a couple drives with reallocated sectors, but i did a raid verify (twice) on it, and everything checked out; so, i'm just watching it [14:27] phlux: that sounds interesting, actually [14:27] up_the_irons: Alright, given that my important eggs are on it, don't care to have it go down too suddenly ^_^ [14:27] phlux: you will have to worry about age limit for American Idol soon (26, i think ;) [14:28] arenlor: i hear ya. i don't want a repeat of kvr04, where i spent all day and night at the data center nursing it back to health [14:54] *** Webhostbudd has quit IRC (Quit: Leaving) [15:21] up_the_irons: well they do say natural breastfeeding is better than the bottle, so good job [15:21] lol [15:35] *** mtve has joined #arpnetworks [15:36] *** fink has quit IRC (Quit: fink) [15:57] *** dj_goku has joined #arpnetworks [16:02] *** fink has joined #arpnetworks [16:04] *** atmark has quit IRC (Ping timeout: 252 seconds) [16:27] *** fink has quit IRC (Quit: fink) [16:29] *** Webhostbudd has joined #arpnetworks [16:35] *** hive-min1 has joined #arpnetworks [16:37] *** hive-mind has quit IRC (Ping timeout: 244 seconds) [16:40] up_the_irons: e5-2620 is a lot cheaper than e5-2660 [16:41] and your e5430 results seem a little low [16:41] ie i got higher results than that from e5420 [16:42] it may be openssl version, or it may be load / context switching overhead [17:20] *** DataCable has joined #arpnetworks [17:22] *** dj_goku has quit IRC (Ping timeout: 244 seconds) [17:22] *** DataCable has quit IRC (Client Quit) [17:31] *** CaZe has quit IRC () [17:57] *** dj_goku has joined #arpnetworks [17:57] *** dj_goku has quit IRC (Changing host) [17:57] *** dj_goku has joined #arpnetworks [18:06] *** dj_goku has quit IRC (Ping timeout: 244 seconds) [18:52] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [19:28] *** Webhostbudd_ has joined #arpnetworks [19:30] *** Webhostbudd has quit IRC (Ping timeout: 250 seconds) [19:59] mercutio: well, that was on a production server, hardly idle [20:32] yeh load could create that [20:32] it could be related to openssl version too [20:33] OpenSSL 1.0.1c 10 May 2012 [20:33] is what i was using [20:33] err actually it was 1.01 [20:33] 1.0.1 [20:33] i think openssl changed a bit recently [21:04] *** fink has joined #arpnetworks [21:12] *** hive-mind has joined #arpnetworks [21:13] *** hive-min1 has quit IRC (Ping timeout: 260 seconds) [21:19] *** hive-mind has quit IRC (Ping timeout: 240 seconds) [21:20] *** hive-mind has joined #arpnetworks [21:26] *** hive-mind has quit IRC (Ping timeout: 245 seconds) [21:28] *** hive-mind has joined #arpnetworks [22:35] mercutio: i was using 0.9.8something [22:36] up_the_irons: less talking.. more testing centos images or spending time with your family. [22:36] ;) [22:36] * jpalmer ducks and runs [22:36] i'm researching ways of exporting a block device from one host to another (say an lvm volume from one host to some /dev/foo on another). i've used AoE before, but things these days seem to be leaning toward iSCSI. Anyone have any thoughts on the matter? [22:36] jpalmer: lol [22:36] jpalmer: the kids are asleep:) [22:36] same with the wife [22:37] iscsi is the new hotness. do it! [22:37] brb [22:39] I think I'ma head to bed. [22:39] night all [22:43] 'nite [22:59] up_the_irons: think newer versions have improved by a bit [23:00] up_the_irons: with iscsi you want to have seperate network for it and use large mtus [23:01] balancing can be annoying, you c an use either multiple gigabit or expensive 10 gigabit [23:01] but with gigabit you limit top speed to 110mb/sec or something [23:01] fibre channel is the other option that is affordable [23:02] but most of the affordable stuff ise second hadn [23:02] and 10 gigabit ethernet is coming down in cost [23:02] that said 100mb/sec is racing, if access times are good [23:03] mercutio: i c [23:04] mercutio: separate network is no problem, large mtus no problem [23:04] pretty easy to bond 2 gige's, but fc would be better [23:06] mercutio: have you used any iscsi targets that you would deem reliable? [23:09] only opensolaris [23:09] interesting [23:09] and that's in state of "uhh what's happening" [23:09] wut?:) [23:09] well when oracle bought sun [23:09] everyone left [23:09] err a lot of the higher up people left [23:09] there was a fork to illumos [23:10] ah [23:10] the illumos camp is hopping [23:10] openindiana is going between prereleases... [23:10] it's the only place to be [23:10] oh, would you look at that... who has illumosvps.com (me) [23:10] openindiana seems stable with ok hardware [23:10] stable as in reliable [23:10] they have a lot of sun people working there so we should see some good stuff [23:10] but not stable as in "one version for years" [23:11] yeh [23:11] well, no [23:11] smartos sounds interesting too [23:11] smartos is a great concept [23:11] dang, i have openindianavps.com too [23:11] md3000i is around for iscsi support but is slow [23:11] i musta been looking toward the future... ;) [23:11] there are higher cost options too [23:11] hmm [23:11] well joyent ported kvm to illumos [23:12] it runs very well [23:12] holy shit, they did? [23:12] yes [23:12] yeh [23:12] wow [23:12] runs good? [23:12] that's what i have heard [23:12] the base tools haven't had the work they need [23:12] but the raw support is stable [23:12] yes [23:12] exactly [23:12] once they port libvirt [23:12] even though they ported it quickly [23:12] it is going to be very attractive [23:12] showing that they have good engineers [23:13] they have a lot of the old sun guys [23:13] because of the mass exodus from oracle [23:13] by good poeple leaving oracle [23:13] people like the guy who made java left [23:13] mhmm [23:13] smartos _does_ sound interesting [23:13] all of the zfs, dtrace and other solaris kernel specialists left [23:13] and said how he was unhappy with the direction oracle were taking sun [23:14] and you'd think someone like that isn't likely to be someone who would motuh off randomly [23:14] they aren't [23:14] they LEFT [23:14] http://www.eweek.com/c/a/Application-Development/Java-Creator-James-Gosling-Why-I-Quit-Oracle-813517/ [23:14] yeh but i mean it's not like a straight business man leaving or something [23:14] and saying about his new venture [23:15] no, they just don't want to be a part of the lawnmower [23:16] up_the_irons: i could totally see you running smartos one day [23:16] up_the_irons: assuming it becomes stable [23:16] Webhostbudd_: i'm checking it out right now [23:16] what's funny is that their port of KVM requires the use of zones [23:16] so each kvm instance is wrapped in a zone [23:16] oddly enough it prevents a lot of kvm exploits [23:17] because the attacker can't break the zone [23:17] i think that was a sensible move [23:17] yes it was [23:17] i mean, why not [23:17] it gives the administrator even more control over the virtual instance [23:17] and with zfs you can clone file systems [23:17] and do copy on write [23:17] zfs is amazing [23:17] so it's not as high overhead having heaps of zones [23:18] smartos is a killer combination of technologies [23:18] i would love to see it get bigger [23:18] webhost: marketing on the other hand... [23:18] have you seen their videos? [23:18] no? [23:18] they seem tacky [23:18] it's pretty hard to market it at this point though [23:18] let's be honest, they don't have a product to ship [23:19] i think they do? [23:19] joyent are doing private clouds already [23:19] so does smartos run illumos underneath? [23:19] http://joyent.com/solutions/privatecloud/ [23:19] no one who is concerned with how they market a product is going to call that a product [23:19] up_the_irons: yeh [23:19] up_the_irons: yes [23:19] and is one of the major contributors [23:19] and illumos is an opensolaris fork? [23:19] illumos is the kernel if i am not mistaken [23:19] or do they do userland work? [23:19] illumus is like the base system [23:20] like netbsd etc i think [23:20] yea, that was always my impression [23:20] yeah i think i get it [23:20] except they don't actually assemble any of it [23:20] openindiana is more like opensolaris [23:20] i wanna say it would be like GNU finishing a kernel [23:20] there's also nexenta [23:20] or something [23:20] which uses apt-get [23:20] the way i see it, GNU = illumos and OI / nexenta are distros [23:21] IF GNU had a kernel [23:21] so, with zones, i've always thought of them to be the solaris equivalent of freebsd jails. and since they are just processes that share the same base OS kernel, is it true the only thing you can put in a zone is another illumos instance? [23:21] up_the_irons: mostly true [23:21] up_the_irons: i think it's like freebsd jails, but a bit more brokenout [23:21] (and that instance could run kvm, yeah, but in the end, it's still illumos) [23:21] yes [23:21] roger [23:21] but there is probably work to emulate linux / bsd systemcalls [23:22] i know freebsd jails can run centos [23:22] with linux emulation [23:22] web: i think that work is still behind [23:22] maybe [23:22] smartos is getting a new package manager i think [23:22] i don't use zones so i wouldn't know [23:22] and packages can be old at present [23:22] well, all of the illumos stuff seems to be using pkgsrc [23:22] so illumos is only the kernel, and openindiana is kinda like kernel + userland (e.g. GNU) [23:22] but i think in general it's under quite a lot of active work [23:22] freebsd jails can run cent? LOL [23:23] up_the_irons: yea, i think that is probably more correct [23:23] up_the_irons: bottom line, you don't run illumos [23:23] Webhostbudd_: yeah makes sense, at least roughly [23:23] openindiana has both sun and gnu userland [23:23] directly [23:23] yea [23:23] ls you have /usr/gnu/bin/dd [23:23] and /usr/bin/dd [23:23] and the normal dd doesn't support things like conv=fdatasync [23:23] there is a really cool fork out there [23:23] which im really digging [23:23] stormos [23:24] debian userland + illumos kernel [23:24] webhost: what have they done? [23:24] similar to debian kfreebsd [23:24] oh? [23:24] i think i'm gonna load this up on one of my microcloud blades [23:24] give it a shot [23:24] smartos is doiugn things new and fancy [23:24] like they want you to network boot [23:24] even more reason to finish that box and haul it to the d/c [23:24] mercutio: which is great [23:24] and have all the storage on a machine running under zfs [23:24] imagine how easy it is to deploy nodes [23:25] which isn't a new concept [23:25] nope [23:25] don't the big guys do it? [23:25] people have been doing such with esxi etc for a while [23:25] vmware [23:25] yea [23:25] but like they're working towards "well thought out" ways of doing things [23:25] which i like [23:25] but also allowing a steeper learning curve [23:25] and doing things diffrently [23:25] like they're not trying to just support a whole lot of legacy ways of thinking [23:25] nope [23:26] they're trying to streamline things etc [23:26] i really appreciate the effort for a solid, opensource hypervisor [23:26] linux really doesn't fit the bill [23:26] well, the distros of today don't [23:26] illumos is a very solid kernel though [23:27] hardware support is probably shaky though [23:27] outside of your common server hardware [23:28] it's better than esxi for hardware support [23:28] i would only want to run common server hardware ;) [23:28] which is outstandingly sad [23:28] the uncommon stuff is expensive... [23:28] up_the_irons: one of the older hp's was broken a while back [23:28] hp's make me cringe [23:28] cpqarwy o rwhatever scsi controllers [23:28] cpqary3 [23:29] if it'll run on an Ivy Bridge 3.4GHz + plain ol' SATA + Intel GB, then that's all i need :) [23:29] http://www.greenviolet.net/articles/2011/09/21/openindiana-151a-and-hp-smart-array-controllers.gv [23:29] anyone here in the market for a sas expander? [23:29] up_the_irons: yeh it'll do that [23:29] mercutio: yeah i didn't figure that basic of hardware would be a challenge [23:29] up_the_irons: you need nehalem or whatever or newer cpus for kvm under illumos [23:30] mercutio: well sure, u need that for kvm in general [23:30] yes [23:30] well the hp thing would effect quite a lot of older hardware [23:30] up_the_irons: nah [23:30] ehhhh [23:30] nah [23:30] wut [23:30] up_the_irons: e5430 won't run kvm on illumos [23:30] i run kvm on adm phenoms [23:30] mercutio: oh? why? [23:30] because they're relying on some newer intel feature [23:30] ah [23:30] yes [23:30] uhh it hikn it's EPT [23:30] interesting [23:30] i can't remember what it was [23:30] that sounds correct [23:30] * up_the_irons googles [23:31] they don't support amd at all do they? [23:31] oh, extended page tables? [23:31] web: that was the case last i knew [23:31] no amd support?! [23:31] nope [23:31] up_the_irons: that's what it stands for but i don't know if that' the case [23:31] or if it was anothe rfeature [23:31] k [23:31] up_the_irons: someone may fix the amd stuff sometime [23:31] but smartos developers focused on intel [23:31] i'm loving my AMD 6212 system... [23:31] Currently KVM on OpenIndiana only supports recent Intel VT chipsets. [23:31] Webhostbudd_: ah gotcha [23:32] bulldozer opterons huh? [23:32] yup [23:32] do you get 16+ cores on those? [23:32] the 6212's have 8 [23:32] oh [23:32] but two sockets on my board, so 16 altogether [23:32] Finally, there is no support currently for AMD SVM. This is not a value judgement of AMD's technology, but rather a reflection of limited engineering and testing resources. (In the spirit of full disclosure, it should be said that the sponsor of illumos-kvm, Joyent, is an Intel-funded company -- but the lack of AMD support reflects only engineering prioritization and lack of testing infrastructure; AMD SVM support would be most welcome should someone in the [23:33] it sucks that those 8 cores get beaten so badly by 4 intel cores [23:34] Webhostbudd_: my cpus: http://i.imgur.com/Ed6nw.png [23:34] Webhostbudd_: in benchmarks or real world operation? [23:34] actually more in real world [23:34] cuz i'm finding them to be quite awesome [23:35] but a lot of server stuff is multithreaded and integer intensive so bulldozer should be a good fit [23:35] yeah [23:35] you've also got context switches to worry about [23:35] and having more cores can cut down in that when virtualising [23:35] exactly [23:36] context switching is super high in virt [23:36] i've never seen any good benchmarks for high load virtualisation [23:36] of multiple diff applications [23:36] no, and that is a problem [23:36] i find that benchmarks are like job interview questions; they look good on paper but do not reflect how the thing will behave in real life situations [23:37] exactly [23:37] up_the_irons: well it depends if you find the right benchmarks.. [23:37] you can also find the right interview questions [23:37] like you cna easily find game benchmarks to know if a video card will be a good fit for you [23:37] mercutio: maybe i'm looking at the wrong stuff then [23:37] but finding cpu benchmarks for virtualisation ... yeh.. [23:37] mercutio: that's pretty hard to say though [23:37] mercutio: yeah, games are specialized, cpus are generalized [23:38] mm [23:38] that's actually the problem with game benchmarks though [23:38] i'd look at kernel compile time benchmarks probably [23:38] unless you always play the same games... [23:38] but they're still not going to be accurate [23:38] webhost: you're comparing video cards to see what would be "good enoguh" for you :) [23:38] mercutio: kernel compile time might be a good overall heuristic, it uses disk + cpu [23:38] compile benchmarks have a lot of floating point though right? [23:38] webhost: nope [23:38] i would imagine [23:38] no? [23:39] why would compilers be floating point? [23:39] video encoding etc would be [23:39] but compiling is gnerally memory/integer heavy [23:39] see, i would assume that [23:39] if you add 2.5 + 3.5 on a compiler using float point numbers [23:39] the compiler only has to generate the assembler [23:40] that doesn't require it actually doing the maths. [23:40] oh im not talking about that [23:40] mercutio: perhaps at the optimize phase there is fp (but not lexer, parser, etc...) [23:40] *optimization [23:40] yes [23:40] this is what i always thought [23:40] well, if you multiply by 1.5 [23:41] it probably does a shift [23:41] and adds it to the number [23:41] rather than actually doing it in floatin gpoint [23:41] im not talking about arthimetic in code at all [23:41] hmm [23:41] there's not that much optimisation work these days. [23:41] there's some, but it's not really as fancy as people often seem to believe. [23:41] obviously [23:41] fancy stuff breaks [23:41] heh [23:42] people like to believe a lot of cool stuff is at work [23:42] it's mostly stuff like cache line optimisation that is easier for compiler to do than by hand [23:42] mhmm [23:42] and reordering to prevent stalls. [23:42] yep [23:43] i'm still surprised by how big the linux kernel is [23:43] freaking massive [23:43] i'd like a kernel < 1 megabyte compressed really [23:44] i have one with lots of stuff disabled and it's still 3.4mb compressed [23:44] back with linux 2.1 it wasl ike 500 or 600k compressed [23:44] lol freebsd kernel so small [23:44] how big is freebsd kernel? [23:44] that's not real [23:44] bullshit [23:44] 630k [23:44] really [23:44] openbsd is 5.1 mb [23:44] did freebsd go to modules? [23:44] i do have a lot of stuff disabled in my kernel [23:44] freebsd does have modules [23:45] but i also removed a ton of built in device support [23:45] openbsd isn't compressed [23:45] nor modular [23:45] well [23:45] my freebsd kernel doesn't even have ufs support [23:45] oh [23:45] i mean, i compiled everything out [23:45] it can't be zfs with that size [23:45] what fs are you using? [23:45] zfs doesn't build directly into the kernel [23:45] and zfs is only 120k [23:45] oh [23:46] it's not huge [23:46] that's good [23:46] nice [23:46] sec [23:46] i've got this thing against bloat :) [23:46] alright, i was massively mistaken [23:46] =p [23:46] 2mb for zfs.ko [23:47] lol [23:47] heh [23:47] i thought zfs was big :) [23:47] it'll have support code etc [23:47] well, i knew it was big, i thought most people just overestimate [23:47] heh [23:48] zfs is a bit of a memory hog too [23:48] it's nice ram got cheaper :) [23:48] oh god yea [23:48] zfs is quite a memory hog [23:48] zfs is fast with lots of ram though [23:48] blazing [23:48] i love that arc cache [23:49] weird this page says kvm just needs vmx [23:49] which kvm? [23:49] illumos [23:49] linux kvm probably [23:49] oh [23:49] maybe they added support recently? [23:49] ARC Size: Current Size: 3598 MB (arcsize) Target Size (Adaptive): 3598 MB (c) Min Size (Hard Limit): 638 MB (zfs_arc_min) Max Size (Hard Limit): 5111 MB (zfs_arc_max) [23:49] and maybe that OI wiki is out of date [23:49] "memory hog" is another word for "aggressive caching" ;) [23:49] https://github.com/joyent/illumos-kvm/ [23:50] *** fink has quit IRC (Quit: fink) [23:50] it goes real slow with 2gb of ram [23:50] so wait.... that thing works on amd! [23:50] oh [23:50] what? [23:50] derp [23:50] svm is amd [23:50] yea [23:51] that page makes installing kvm really hard [23:51] it's actually simple on openindiana [23:51] just use smartos =p [23:51] EPT is supported on E5430 [23:52] maybe it does work on earlier cpus? [23:53] interesting [23:54] what's this omnios [23:55] people love illumos [23:55] jeese [23:58] anyone know of a good iscsi target for linux? i see iscsitarget and open-iscsi (and i actually don't know of open-iscsi can be a target...) [23:59] no idea [23:59] god, i can't believe illumos is built with gcc 3.4.3 [23:59] that just feels super old now