BlueVM KVM 512 MB (NY)

[wlanboy]

Provider: BlueVM
Plan: KVM 512mb VPS
Price: 24$ per year (birthday special)
Location: Buffalo, NY

Purchased: 05/2013

Hardware information:

• cat /proc/cpuinfo
  
  processor : 0
  vendor_id : GenuineIntel
  cpu family : 6
  model : 13
  model name : QEMU Virtual CPU version (cpu64-rhel6)
  stepping : 3
  microcode : 0x1
  cpu MHz : 1999.999
  cache size : 4096 KB
  physical id : 0
  siblings : 2
  core id : 0
  cpu cores : 2
  apicid : 0
  initial apicid : 0
  fdiv_bug : no
  hlt_bug : no
  f00f_bug : no
  coma_bug : no
  fpu : yes
  fpu_exception : yes
  cpuid level : 4
  wp : yes
  flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ht syscall nx lm pni cx16 hypervisor lahf_lm
  bogomips : 3999.99
  clflush size : 64
  cache_alignment : 64
  address sizes : 46 bits physical, 48 bits virtual
  power management:
  
  processor : 1
  vendor_id : GenuineIntel
  cpu family : 6
  model : 13
  model name : QEMU Virtual CPU version (cpu64-rhel6)
  stepping : 3
  microcode : 0x1
  cpu MHz : 1999.999
  cache size : 4096 KB
  physical id : 0
  siblings : 2
  core id : 1
  cpu cores : 2
  apicid : 1
  initial apicid : 1
  fdiv_bug : no
  hlt_bug : no
  f00f_bug : no
  coma_bug : no
  fpu : yes
  fpu_exception : yes
  cpuid level : 4
  wp : yes
  flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ht syscall nx lm pni cx16 hypervisor lahf_lm
  bogomips : 3999.99
  clflush size : 64
  cache_alignment : 64
  address sizes : 46 bits physical, 48 bits virtual
  power management:
  
  
• cat /proc/meminfo
  

  MemTotal:         508148 kB
  MemFree:           93808 kB
  Buffers:           68028 kB
  Cached:           104184 kB
  SwapCached:         2016 kB
  Active:            97368 kB
  Inactive:         254696 kB
  Active(anon):      16456 kB
  Inactive(anon):   165308 kB
  Active(file):      80912 kB
  Inactive(file):    89388 kB
  Unevictable:           0 kB
  Mlocked:               0 kB
  HighTotal:             0 kB
  HighFree:              0 kB
  LowTotal:         508148 kB
  LowFree:           93808 kB
  SwapTotal:        522236 kB
  SwapFree:         500040 kB
  Dirty:                32 kB
  Writeback:             0 kB
  AnonPages:        178104 kB
  Mapped:            21312 kB
  Shmem:              1912 kB
  Slab:              36208 kB
  SReclaimable:      23276 kB
  SUnreclaim:        12932 kB
  KernelStack:        3256 kB
  PageTables:         7288 kB
  NFS_Unstable:          0 kB
  Bounce:                0 kB
  WritebackTmp:          0 kB
  CommitLimit:      776308 kB
  Committed_AS:    1888336 kB
  VmallocTotal:     512004 kB
  VmallocUsed:        6768 kB
  VmallocChunk:     503128 kB
  HardwareCorrupted:     0 kB
  AnonHugePages:         0 kB
  HugePages_Total:       0
  HugePages_Free:        0
  HugePages_Rsvd:        0
  HugePages_Surp:        0
  Hugepagesize:       2048 kB
  DirectMap4k:       59380 kB
  DirectMap2M:      464896 kB

• dd
  

  dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
  16384+0 records in
  16384+0 records out
  1073741824 bytes (1.1 GB) copied, 42.5395 s, 25.2 MB/s

• updated dd
  

  dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
  16384+0 records in
  16384+0 records out
  1073741824 bytes (1.1 GB) copied, 19.2025 s, 55.9 MB/s

• wget
  

  wget cachefly.cachefly.net/100mb.test -O /dev/null
  
  --2013-05-20 07:14:33--  http://cachefly.cachefly.net/100mb.test
  Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
  Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 104857600 (100M) [application/octet-stream]
  Saving to: `/dev/null'
  
  100%[================================================================================================================================>] 104,857,600 3.36M/s   in 39s
  
  2013-05-20 07:15:12 (2.56 MB/s) - `/dev/null' saved [104857600/104857600]

• updated wget
  

  wget cachefly.cachefly.net/100mb.test -O /dev/null
  
  Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
  Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 104857600 (100M) [application/octet-stream]
  Saving to: `/dev/null'
  
  100%[================================================================================================================================>] 104,857,600 27.1M/s   in 4.4s
  
  2013-05-21 01:31:08 (23.0 MB/s) - `/dev/null' saved [104857600/104857600]

What services are running?

• 2x Xfce desktops
• 2x VNC servers
• Openvpn
• Ruby scripts
• Ruby debugger
• SVN server

Support:

I have opened 2 support tickets in two weeks. All get short answers within some hours. If I look to them:

• One ticket for asking about vnc connection information.
• One ticket to ask why my vps is offline.

Friendly support that is not fast and cannot tell any time schedule on hardware failures. Ok this was a really hard test because a hard disk failure on the node is something Level 1 support can just note. But there are two things that totally went wrong on support:

• I had to inform them. Due to time zones I have read the statuscake emails after 6 hours. So no information from BlueVM to me that the node is down even after 6 hours of downtime.
• I had to reask if the node is online again. Yes BlueVM did not send me any information that the node is working again. I had to open a ticket to get a response that I can restart my vps again.

Overall experience:

It was their birthday special. I could not resist. The package is working and is good - if the node is online. I use this machine to remote build and debug Ruby gems. Building native extensions is something that is using a lot of I/O and cpu power.

The Xfce desktops are working fine too. Even browsing with firefox is fast enough.

So I got a lot of hardware for the money. Network is ok, ping to europe is ok too.

Their SolusVM server is overloaded. Login lasts about 60 seconds. Confirmation of reboot about 10 seconds.

But if I look to the last downtime of the vps:

2013-05-19 07:13:41 2013-05-20 11:56:01 28h 42m

Yes nearly 29 hours of downtime due to a harddisk failure of the node.

Not a good start at all. But the support just ruined my opinion of BlueVM because they did not send me any notification. Not about the hardware failure and not about the fact that I can use my vps again.

PS:
I have updated the dd/wget lines. Things that changed:

• Activating virtio
• Let time pass .. benchmarking half an hour after a node is back alive is not fair.

Canceled due to bandwith/routing issues in Buffalo -> EU.

Read review about my move to CH ->

 

[elusus83]

This is pretty accurate. I've had the exact same experience.

 

[bizzard]

I am a BlueVM customer too, having 2 vps and a shared hosting account. Their hardware and network is fine and I am somewhat satisfied by it. There is a good community in IRC, the support staff are friendly, but not as fast as others. One thing they have to improve is the notification system. Even if they are making a change at their side, its not properly notified to the customer through mail. Last time, they migrated their shared hosting server and I came to know about it from the IRC, when my sites were not working. They said they have sent our mails, but I didn't receive any. Also, whenever a node goes down, notifying the customer about it will be great as atleast we would know that someone is working on it. Last day, their Server 5 at California was down and I had to wait for a long time in IRC to hear anything regarding it from a staff.

 

[VPN.SH]

I've had the same experience with SolusVM. Takes FOREVER to log in. Anybody from BlueVM able to clear up whether or not this is planned to be resolved?

 

[BlueVM]

@liamwithers - SolusVM is actually (and has been) under DDOS so it'll be slow until the attack is gone.

@wlanboy - We understand your frustration and the downtime is unacceptable. We are working to make these incidents smaller and notify users about them in the future. We will be releasing a status system in the next few weeks which will allow users to subscribe to email updates about servers they want information on.

 

[wlanboy]

@BlueVM

Thank you for the response. Looking forward to the notification system.

Any time schedule for your wiki?

 

[Ishaq]

Due to spam issues we had to take our wiki down regularly, we'll bring a new one online soon.

 

[Mun]

or.... ishaq could just bug me

 

[Ishaq]

/me bugs Mun

 

[Mun]

So where would you like it setup ishaq

 

[drmike]

Is BlueVM buying from ChicagoVPS and the IP info hasn't been changed as to disguise that fact?

 

[Mun]

Is BlueVM buying from ChicagoVPS and the IP info hasn't been changed as to disguise that fact?

First off no, second off no, third off would it even really matter? You are just upset anything CVPS. In this case bluevm purchased the block that was formerly used by cvps.

 

[BlueVM]

If I was trying to hide something I'd make sure to switch out the information BEFORE I gave away 16 /24s worth of IPs... Anyway there's another block we own which is listed under Hudson Valley Host and we haven't changed that yet either...

I threw in the org information for Arin today, shoulda done it a while back because now the running joke is gonna be that we host with CVPS when we don't... doesn't matter really anyway because frankly everyone seems on the warpath against colo crossing and frankly I'm tired of it.

Why we went with colo crossing: It's allowed us to support a large number of locations without having to contact each datacenter directly and pay for more space than we need. When we started out we were saving over $1,700 a month on colocation by going with colo crossing. Today we probably save $3000+ a month just based on the fact that we don't have to buy whole racks just to get a decent price. That money has allowed us to purchase more hardware and we're even looking into expanding to Germany next month.

 

[Tactical]

Bluevm is rock solid. I have 2 vps' with them one kvm and one openvz. Just rock solid service. Support was good enough for me the 2 times I had to use them. Just rock solid.

 

[drmike]

First off no, second off no, third off would it even really matter? You are just upset anything CVPS. In this case bluevm purchased the block that was formerly used by cvps.

I am not upset by anything CVPS/CC.  I am just curious.  

If folks didn't pay attention and weren't curious, some folks would be even more dishonest.

Formerly used block that CVPS had, yes.

That's probably better than getting a soiled IP space CC let spammers run wild on.

 

[jarland]

warpath against colo crossing and frankly I'm tired of it.

As one of the most accused of such and a strong advocate of BlueVM I'd have to disagree. A war against dishonesty? Perhaps. That's always been my nature and I'd like to think I'll be that way until I die.


Either way, I love BlueVM

 

[drmike]

I don't have issues with providers JUST BECAUSE they use CC/CVPS.

Let's look at the finer points of the review, shall we? The not so good points:

1. dd
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -rf test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 42.5395 s, 25.2 MB/s

======== SLOW.

2. wget
wget cachefly.cachefly.net/100mb.test -O /dev/null

--2013-05-20 07:14:33-- http://cachefly.cachefly.net/100mb.test
Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'

100%[================================================================================================================================>] 104,857,600 3.36M/s in 39s

============== SLOW

3. support that is not fast

============= SLOW

4. support that cannot tell any time schedule on hardware failures.

============= SLOW

5. BlueVM did not send me any information that the node is working again.

============= BAD CUSTOMER SUPPORT

6. Their SolusVM server is overloaded. Login lasts about 60 seconds. Confirmation of reboot about 10 seconds.

============= SLOW

7. 2013-05-19 07:13:41 2013-05-20 11:56:01 28h 42m - Yes nearly 29 hours of downtime

@wlanboy is being kind with his review.

I drop providers for far less issues.

Spend less time posting ads and worrying about how much HaterAde I've drank today and more time getting your operations in order.  You folks list a bunch of staff and aren't new to this business, so I expect better.

 

[wlanboy]

Time to update my review.

What services are running?

• 2x Xfce desktops
• 2x VNC servers
• Openvpn
• Ruby scripts
• Ruby debugger
• SVN server
• Munin master
• MongoDB cluster node

Support:

Not a single support ticket needed.

Overall experience:

I really enjoy this node. No hassles, no downtimes, no support needed and a fast network that sometimes has not-that-good routings to europe. Routings within the US are ok.

Performance is good - for the price I am paying - and stability is way beyond the price tag.

 

[shawn_ky]

I've had the same experience with BlueVM. Actually got a VPS when your review was posted. Great service... Really like Feathur also.. 

 

[Gallaeaho]

I too have services with BlueVM (Two KVM 512MB's in Buffalo) and I must say that for the price, their services are worth the money.

Sure, they've had a few hiccups, due to one issue or another, but their support has been helpful for me (I usually go to their IRC for unofficial support, and have only ever had to open one ticket since becoming a customer).

I've never had a network issue that was directly related to their networking.

My only complaint is that their SolusVM panel takes an incredibly long time to log you in. They will get their KVM clientbase migrated to Feathur at some point, which will hopefully be quite a bit faster.