Tony

All our servers should already be running 11.24. You can check what version the server you're running on has by logging into cPanel and finding the cPanel version portion.

Nope You can do that just make sure you're pointing it at the right IP. The right IP will be in your cPanel not the one we send in the account information email that says main server IP. As it says right in the email it's just the main server ip and not your IP.

Maybe It's a pain to keep matching skins for some software. It's a big reason our support system is no longer with a matching skin. vbulletin is one of the few that it's not as big of a pain to keep matching. It would probably just be the colors matching and not actually look like our site.

This has been completed.

Everyone has been migrated. If you experience any issues please open a ticket.

At this moment in time no one should have any routing issues with their IP's. If you're experiencing any issues we recommend you restart your VPS. As always you can do this through https://vps.hawkhost.com:8887/

We have found the cause to the routing issue it is related to this bug report here: http://bugzilla.openvz.org/show_bug.cgi?id=771 Basically the VPS node is not sending out the arp requests to make so the IP's are routed to it. We've disabled the feature causing this to not happen. We're going to manually arp everyones ip's again. You may experience up to a minute down time on each ip.

We are currently dealing with some routing issues with the IP's on the new node. We're working to resolve this. We have not ETA on this being fixed for the time being we've manually routed them properly but it is not an ideal solution.

We've migrated everyone except for those who are affected by file system problems. If you are affected by this you have been notified with a plan to resolve it.

Around 45% completed at this point in time. Things are moving along nicely after we resolved some issues we were having yesterday.

Rescheduled again for 12/19/2008 at the same time. We have numerous other high priority maintenance or windows going on today making this window be delayed.

Just to update this is not going as fast as we'd like we ran into some technical difficulties along the way. We're only about 33% done entering close to business hours today. We're going to push today in hopes of having everything transferred before the end of the day. You can find out if you're on the new VPS node by doing a trace route and having the second last hop contain vswitch2.wdc.arandomserver.com

We've started migrating VPS's. The only issues you may encounter is your VPS rebooting and maybe 5 minutes of down time while we re-route your IP's to the new machine. I can not stress enough that this is required. The raid array is bad and we're playing with fire the longer we sit on it. So we're dealing with a few minutes of down time in order to make sure no one loses data or it's an even longer extended period of down time.

This morning we experienced drive failure on the Gizmo server and also raid failure. After rebooting the machine we were able to bring it back online eventually. We were alerted to failed stripes on the raid array of Gizmo. This is not fixable and requires a complete rebuild of the raid array. Rather than rebuilding the array and restoring from backups we're going to migrate everyone to another node. We will be starting this as soon as possible and we'll update everyone as we move forward. You will not have any change of IP addresses or logins. We hope to have everyone migrated before anything serious happens. But we have made another set of backups just in case the server is to fall offline before we migrate all VPS's off of it. Date: 12/17/2008 Start time (EST): 2:45pm End time (EST): Unknown Estimated Down Time: Unknown Duration: Unknown

This has been rescheduled for tomorrow at this time.

This was completed some time ago there was just not an update on it.

This has been completed. Unfortunately this machine as well went into a limbo state while rebuilding apache. We're not sure why it killed off apache while compiling but it did. So unfortunately the machine did not have a working web server for about 10 minutes. We're sorry about any inconvenience this may have caused.

This has already been completed. It was done by mistake before another machine.

This has been completed.

This has been completed. We crashed apache by mistake during the rebuild which resulted in it being down for about 7 minutes. We're very sorry about any inconvenience that may have caused.

Well I got the back story of that whole thing as I asked litespeed themselves about this. One big issue was the person who had understanding of the web server at eleven2 left the company. The other issues described to even me seemed very strange. For one it does not affect cPanel in anyway. PHP5 runs fine and our site right now is being served via it. We make heavy use of mod_rewrite and all sorts of advanced features via htaccess and php which work fine. Our site receives more traffic than almost any of our customers do. So it is a good test case for what happens under high traffic for one specific site. The PHP problems they experienced could have happened in a mod_php environment to. I believe they were running caching (eaccelerator, xcache ect.) These caching programs have issues with mod_php in shared hosting. If you do not know the causes or how to deal with them you're going to have problems. It is highly unlikely we'll be running such caching programs as soon as we're migrated. This would be something heavily researched and tested. So to summarize the eleven2 issues I believe their problems with downtime lies with them. It has nothing to do with their web server at all. They continue to have problems and had problems before litespeed as well. Also there are popular and expensive application hosts who have been using litespeed for a significant amount of time. They strive themselves on near 100% uptime in a cpanel environment. I'd take their thoughts on the product over someone like eleven2. 1) We are testing it on our system already. Our site is running fine with it on and we see no reason why it would not run fine on others. We also will deploy it slowely on production servers as test cases. We have no reason to believe there will be any problems. 2) There is no reason that someone would want to be back on Apache. The idea is this is a drop in replacement and nothing should change. If this wasn't the case we would not be considering it. We could not afford to support multiple configurations and will not once we have everything migrated over. So to summarize we're not a one server company we have quite a few machines. So we can easily work out issues via on our own server or simply one machine with limited set of customers. But like I've been saying it's a drop in replacement where we could deploy it without anyone noticing. I imagine the majority of our users even with the notification would still believe we're hosting them on apache.

You could run it, but I doubt it would run very well as the VPS. We can limit CPU usage and with ram as soon as you hit the limit the OS starts throwing a slew of errors.

Simple Litespeed supports everything that Apache does including reading the httpd.conf from apache. This means we can drop install litespeed then click one button and switch over to it as our web server. A wrapper to apache is dropped in and cPanel plays nice with it modifying the conf file then restarting the web server without causing an issues. That's a tad bit old as version 3 has been out for a while and they're already several beta's into 4. But that data did help but the big one was other hosts giving praise saying how it improved their web server performance dramatically.

The raid controller on Neptune has alerted us to a bad block on one of the drives in the raid array. When we are alerted of bad blocks on a drive in our raid-10 arrays we replace the drive as a protective measure even when the raid array is not reporting the drive as bad. We will be doing this Monday December 15th between 2:00AM EST and 4:00AM EST. The server has hot-swap drives so there will be no down time during the swap. Once a new drive has been inserted into the array we will rebuild the array which may cause slightly higher load during this time. We do not expect this to cause any serious degradation in services. Date: 12/15/2008 Start time (EST): 2:00am EST End time (EST): 4:30am EST Estimated Down Time: None Duration: 2 hours