Media Temple (dv) 4.0 Migration & Optimization

About a month ago, I received an email letting me know that my host, Media Temple, is discontinuing their (dv) Dedicated Virtual 3.0-3.5 servers. Everyone hosted on the old servers must migrate to the new (dv) 4.0 servers. The friendly (mt) email says:

The migration is a fairly simple process and you’ll have until early summer to complete it.

Having now performed the migration, I can assure you that solid preparation is required to make it a smooth and “fairly simple process”. Based on experience, I suggest getting started on this asap rather than waiting “until early summer” to make your move..

There are a lot of pieces to the puzzle, and the goal of this article is to help bring them together into a supplementary guide — refer to the (mt) KnowledgeBase for official information about the (dv)-4.0 server-migration. There you’ll find definitive guides for each aspect of the process, but researching and bringing it all together takes some time. Hopefully this informal guide will help fill in the gaps and save some time. Here is the menu:

• Disclaimer
• Auto migration vs. Manual migration
• Pre-migration Questions & Answers
• Changes in Plesk
• Previewing your sites on the new server
• Optimize before switching DNS
  • Apache tuning
  • Google’s mod_pagespeed
  • Turn off the “named” service
  • Enable/disable mailman
  • Further optimization tips
• Checking everything
  • Check PHP Safe Mode
  • WordPress Database Manager
  • Remove unused added empty directories
  • Memory warning in the Account Center
  • Monitoring server resources
• Final steps
  • Change DNS Settings
  • Change Primary domain
  • Change Reverse-DNS Records
  • Remove tempoary domain from Plesk
  • Close your 3.x (dv) service
  • Update your affiliate links
• Wrap up
• Useful Resources

Disclaimer

Note that this article is meant only for informational purposes. Please refer to the official (mt) documentation for authoritative information. Always remember to make good backups and take precautionary steps before making any changes on your server. I provide this information freely and without guarantee; by using any of the information or code presented in this article, you fully agree to accept all liability. </disclaimer>

Auto migration vs. Manual migration

There are basically two ways to go about migrating from (dv) 3.x to 4.0: manually or by using the Plesk Migration manager. Comparing these two methods against the relative scope and complexity of my server setup, I opted for the “auto” migration. There are pros and cons to each method, so examine each method carefully and choose the one works for you. This article pertains primarily to the auto-migration method, but may also prove helpful for a manual move.

Notes about the Plesk Migration Manager:

• Requires “shared IP” on both 3.x server and new 4.0 (dv) server
• Transfers most everything, but not any custom “high-level server settings”
• Transfers client data such as domains, subdomains, mailboxes, databases, etc.
• “You must have a new IP address on your new server” (not the same one as your old server)
• The auto-migration docs mention several important “gotchas” or snags known for certain setups

If you go the auto-migration route, take the time to grab (and backup) any custom firewalls, PHP settings (php.ini), Apache settings (httpd.conf), and so forth. Once the Plesk auto-migration is complete, use these backups to restore your high-level server settings. Also note that “contacts and spam filter settings for email users using the Horde Webmail client are not copied over”, so you’ll have to manually transfer those as well.

Pre-migration Questions & Answers

Going the Plesk auto-migration route, I had initial some questions:

Do I have to switch to an exclusive IP?

Yes, on both old and new servers. The documentation specifies that a shared IP (as opposed to exclusive) is required on both 3.x and 4.0 servers for the auto-migration. But after the migraation “you can set the IP’s from shared to exclusive and visa versa whenever you want,” so it’s all good.

What happens to my account if I do nothing before the deadline?

“If the server is not migrated prior to the deadline, we will make an attempt to migrate your content automatically using the Plesk migration manager. Once the migration is complete, we’ll need to close the old service. The problem with this is that if there are any complications during the auto-migration, there’s not much time to work on them before the old server goes down.”

Do I have to revert a PHP upgrade?

In the documentation, it explains that, “If you upgraded your (dv) 3.0 to PHP5, you will need to revert this. Your site will break. Please see: Reverting PHP5 for (dv) 3.0 after a migration (404 link removed 2016/11/28).” I wasn’t sure about this, so submitted a ticket for clarification: “..because your server is a (dv) Dedicated-Virtual Server 3.5, not a 3.0, your server was already running PHP 5. You do not need to take the actions explained in this article.” So basically PHP-reversion may only apply to (dv)-3.0 servers.

Questions about lowering TTL (time-to-live)

The (mt) KnowledgeBase article recommends lowering the TTL before beginning with the migration process. This sounds simple, but there are some additional useful things to know beforehand: 1) a good lower TTL value is 5 minutes, 2) it takes 12 hours for the lowered TTL to kick in, 3) the lower TTL remains in effect for 3 days, then automatically increases to the default value.

After resolving these initial questions, grabbing copies of my high-level server configuration files, and making a complete pre-migration backup, it was time to jump in and get it done. For this, I followed as closely as possible the (mt) guide to using the Plesk Migration manager. Other than a couple of hiccups, the auto-migration went amazingly well. The first bit of confusion happened during the pre-migration configuration steps, where the screenshot in the (mt) docs didn’t coincide with the new settings for the Migration Manager:

Click for full-size view

As seen here, the current version of Plesk changes some default settings and provides some additional options. Basically I just went with the default settings (rolled the dice!) and the migration went flawlessly, aside from the following two (minor) errors:

Error: client "username"
The password was generated for user 'Domain Administrator (example.com)'. New password is '*******'

Error: client "username"
The password was generated for user 'Domain Administrator (domain.tld)'. New password is '*******'

The (mt) docs include many different troubleshooting tips for things that could go wrong, so I was prepared for the worst. I was unable to find any information regarding these specific errors, but they were the only ones, so I just said “whatever” and moved along with business at hand. Warm buttermilk biscuit to anyone who knows more about these mysterious “password-generated” errors.

Changes in Plesk

After completing the migration and resolving any reported errors, the first thing you’ll notice is the brand-spankin’ new Plesk control panel interface. Basically everything is different now, requiring no doubt a massive amount of time cumulatively spent for everyone to figure out where everything is located. And they bury some stuff deep, so be prepared to guess well, or search quickly. Most of the interface changes are sort of intuitive once you get the gist of how things are organized.

The main thing that threw me off was Plesk’s new “Power User Mode”, which organizes and displays your settings in some sort of special way that I have yet to understand fully. Until then, I can share some useful snippets and tidbits that helped me find my way around the new Plesk interface.

Pay attention during pre-migration setup

During the pre-configuration of the Migration Manager, it asks about “Power User Mode”, which sounded great at the time, but caused confusion after the migration because none of my domains were listed (as they usually are) under the “Domains” tab.

Getting domains to appear after migration

To get the domains to appear, I had to disable power-mode, which has various restrictions and limitations that affect which customers can view which subscriptions can include which domains, or whatever. Frankly it’s confusing, and I don’t have the luxury of spending another chunk of precious hours studying the Plesk documentation.

Disabling and enabling “Power User Mode” via command line

To disable power-mode: “/usr/local/psa/bin/poweruser --on” and to enable power-mode: “/usr/local/psa/bin/poweruser --off” (no quotes!)

Change Power Mode settings

This may only work during setup, but you can change the default Plesk control-panel view by accessing the user-interface switcher directly at “https://123.456.789.123:8443/server/uiswitcher.php#” (no quotes) — replace the IP address with that of your new (dv) 4.0 server.

Switch user mode directly via URL

Not sure if this works in every case, but I was able to switch back and forth between power-user and normal-user mode by changing the port appended to the URL:

• https://123.456.789.123:8443/ — Regular User Mode
• https://123.456.789.123:4643/ — Power User Mode

Once you’ve got your way around the new Plesk (currently at version 10.4.4), take the time to preview your sites, resources, and settings to make sure everything is functioning properly.

Previewing your sites on the new server

To check your sites on the new server before switching the DNS, you have several options, including fiddling with name servers in Plesk, finding where Plesk hides the “site-preview” links, or handling it locally via your computer’s hosts file.

I went the hosts file route because it’s completely noninvasive, efficient and effective. Using Terminal, here is how to edit the hosts file on a Mac (OS X):

1. Open Terminal: Applications -> Utilities -> Terminal
2. Open the hosts file (from Terminal): sudo nano /private/etc/hosts
3. Edit the hosts file: move the cursor to the bottom of the file and add your new IP/domain mappings, which look like this: “123.456.789.123 example.com” (no quotes) for each of your domains (one per line).
4. Save the hosts file: after editing, press control-o to save the file, and press enter when prompted.
5. Exit the text editor: press control-x to exit the editor and return to the command prompt.
6. Flush the DNS cache: at the command prompt, enter “dscacheutil -flushcache” (no quotes) to flush the cache immediately.

Once you’ve checked your sites, databases, settings and so forth, it may behoove you to optimize your server before switching the DNS..

Optimize before switching over to new server

Before your new server goes live, you may want to further optimize some things to improve performance. Here are some recommended techniques for making your (dv) 4.0 even better.

In addition to these improvements, I used this guide to enable compression of web pages via Apache’s mod_deflate. As may be verified using this online mod_deflate test, mod_deflate reduces page size by over 70%. Well worth it.

Apache tuning

Just a note about this: the RAM-optimization technique given in the first part of the Apache-tuning article result in the following changes made to your httpd.conf file:

Before

<IfModule prefork.c>
StartServers 1
MinSpareServers 1
MaxSpareServers 3
ServerLimit 50
MaxClients 50
MaxRequestsPerChild  2304
</IfModule>

Before

<IfModule prefork.c>
StartServers 1
MinSpareServers 1
MaxSpareServers 3
ServerLimit 50
MaxClients 50
MaxRequestsPerChild  4000
</IfModule>

Also, for the “removing-modules” optimization method, remember to check the list of disabled modules before going live. For example, mod_speling is commonly used in .htaccess files, but is included among the disabled modules for this technique. If your .htaccess file calls for any of the disabled modules, loading any page on your domain(s) will trigger the dreadful 500 Error – Internal Server Error. So to fix, just re-enable the module by removing the pound-sign (#) appearing before its name in your main configuration file.

Google’s mod_pagespeed

Another potentially useful optimization method is to install and configure Google’s mod_pagespeed, described as:

mod_pagespeed is an open-source Apache module that automatically optimizes web pages and resources they use. Optimization is done by rewriting the resources using filters that implement web performance best practices. Webmasters and web developers can use mod_pagespeed to improve the performance of their web pages when serving content with the Apache HTTP Server.

Deciding to give it a go, I successfully installed the pagespeed module (404 link removed 2016/11/28) via SSH. It required a significant amount of time to configure and get everything working. After experimenting with the different settings and running plenty of tests, it’s clear that, in this case, mod_pagespeed really isn’t necessary. The resources required to run pagespeed outweigh the minor performance improvements. Here are some before/after screenshots showing Firebug “Net” results of loading the Perishable Press home page (click either thumbnail for full-size view):

Loading of home page without mod_pagespeed (click for full view)

Loading of home page with mod_pagespeed (click for full view)

Turn off the “named” service

Another potentially useful tip is to disable the resource-hungry “named” service. Named is used to run private nameservers, and should be disabled if you’re not using them. As explained in the (mt) docs:

The 64-bit version of named is quite the resource hog, and Plesk automatically turns on the service when you add your first domain.

Screenshot showing disabled “named” service in Plesk (click for full view)

Enable/disable mailman

The mailman program is used for organizing mass-email campaigns and gobbles up significant memory doing so. If you don’t use mailman, I suggest removing it if possible (it isn’t). If that turns out to be impossible, another effective option is to disable it. Here’s how to do it via SSH:

• Disable mailman: /etc/init.d/mailman stop
• To prevent mailman from restarting: chkconfig -—del mailman
• To enable mailman to be restarted: chkconfig —-add mailman
• Enable mailman: /etc/init.d/mailman start

If you would rather remove it completely, you may try following the current (mt) guide for (dv) 3.5 (404 link removed 2016/11/28), but it doesn’t seem to work for the new (dv)-4.0 servers. If you try it, you should see the following error:

error: Failed dependencies:
mailman >= 2.1 is needed by (installed) psa-mailman-configurator-10.13.4-cos5.build1013120126.11.x86_64

After finding zero info about this online, I contacted (mt) support to learn that this dependency is required by Plesk and should not be removed.

After fiddling, you may need to restart Apache. Either of these commands will work:

• /usr/sbin/apachectl -t
• /usr/sbin/apachectl graceful

In the end, disabling mailman seems the way to go (if you’re not using it).

Further optimization tips

After inquiring with (mt) support about further ways to improve/enhance performance, the following KnowledgeBase tutorials were provided:

• Using MySQL Report on a (dv) Dedicated-Virtual Server (404 link removed 2016/11/28)
• Using MySQLTuner
• Basic MySQL performance tuning (MySQLd)
• (dv) Increasing Max MySQL Connections

Additionally, you may want to install an application for monitoring your server. Here’s a short-list of recommendations:

• M/Monit (404 link removed 2016/11/28)
• LoadAVG (404 link removed 2013/08/02)
• Memory Utilization Scripts (404 link removed 2017/02/08)

Other suggestions? Shout ‘em out in the comments :)

Checking everything

There may be a million things to check, but there’s no point in trying to second-guess what you might be looking at, so just take your time and be as thorough as possible before making the final switch to your new server. There are a few interesting little things that didn’t go as expected, however, and they’re worth mentioning them here.

Check PHP Safe Mode

While checking my sites before the switch, I noticed that several PHP-related scripts stopped working. After some sluething, I discovered that, during the auto-migration, Plesk seemed to have “missed” my old PHP settings for “Safe Mode”, which I had disabled on several WordPress-powered sites. Here are screenshots to help visualize:

Safe-mode settings after migration

Safe-mode settings set to ‘Default’

As seen here, the imported safe-mode settings looked like they were correct, but in fact were not being applied for PHP script processing. It’s as if the setting was actually set to “On” somehow behind the scenes.. but rather than dwell on the issue, I decided that a quick “toggle” to the ‘Default’ setting was worth a shot. And you know what, it worked — after setting the safe-mode to default, PHP once again worked properly for each site. Btw, in the new Plesk, the ‘Default’ setting is the same as disabling Safe Mode.

WordPress Database Manager

One PHP script that was affected by the safe-mode issue is the backup plugin, WP DBmanager. On Media Temple servers, the following paths are used by this plugin:

• Path To mysqldump: /usr/bin/mysqldump
• Path To mysql: /usr/bin/mysql

Yet even with these paths defined, WP DBmanager could not create a backup on the new (dv)-4.0 server. After trying all of the usual tricks to get backups working again, I finally flipped that “Safe Mode” setting to ‘Default’ and suddenly backups started working again.

While on the subject of WordPress, I also noticed that plugin and core updates were not working after the migration. After trying many things, adding the following line to each site’s wp-config.php file did the trick:

define('WP_TEMP_DIR', '/var/www/vhosts/example.com/httpdocs/wordpress/wp-content/uploads');

Of course, if you use this, remember to edit the path with that of your own.

Remove unused added empty directories

After migration, check each of your sites for two newly added empty directories, picture_library and plesk-stat:

Plesk takes some liberties by adding two empty directories to every migrated site

These may be deleted if not used, and don’t seem to get re-created once gone.

Memory warning in the Account Center

Tired yet? Another thing that I found interesting (and slightly disturbing) is the new “Server Status” alert in the Account Center:

The server-status alert in the (mt) Account Center

The dot/icon changes from green to yellow to red, depending on the status of your server. Clicking that status icon pops open more info:

Click the server-status alert for more info

I kept seeing yellow status indicators while working on the migration, and would sort of panic.. eventually learned that the memory status shown in the Account Center reflect only the “guaranteed maximum memory” purchased for the account. There is generally more than this amount of “burstable” memory available, however it is “not guaranteed”. Also keep in mind that (dv)-4.0 is 64bit and requires more resources than the old 32bit (dv)-3.x servers.

Monitoring server resources

For a sweet way to monitor all of your system resources in real-time, connect via SSH and enter the “top” command. It shows all running processes, displays real-time memory usage and much more. Very useful for tracking down processes that are consuming too much memory. Here are some helpful commands:

• Run top: enter top in Terminal (or whatever)
• View by memory used: press shift-m on your keyboard
• Quit top: type q on your keyboard

It’s one of those programs that’s just simple and awesome.

Final steps

Once everything is looking good on the new server, it’s time to complete the process and “flip the switch,” as it were. I’ve broken this down into five essential steps..

Change DNS Settings

To point your domains to your new server, follow the steps in this article if you host your DNS with Media Temple; otherwise, “if you host DNS elsewhere, update your DNS records to use your new IP address(es).”

So for example, at my domain-name registrar — which is not (mt) — I use the following Nameservers for sites hosted at Media Temple:

NS1.MEDIATEMPLE.NET
NS2.MEDIATEMPLE.NET

When looking at these Nameserver entries, you may notice that neither of the associated IP addresses are the same as those of your server. This is normal, so everything is good if your Nameservers are correct (as shown above).

So with proper Nameservers in place, it’s time to change the DNS settings, which are in my case hosted at Media Temple. It is actually trivial to make this change by simply logging in to the Account Center and using the “Point to another server” tool. Here is the official (mt) guide.

This is technically all that’s required to get traffic flowing to your new server. And you have granular control in doing so, as the “Point to another server” tool must be used for each site hosted on your new server. I took advantage of this by first switching over all of my low-level-traffic sites, monitoring and watching the server load, and then when everything proved stable, switched over the heavier-traffic sites. They call it “OCD” ;)

Change Primary domain

Once traffic is flowing and everything is flowing smoothly, you may also want to change your primary domain. During the migration process, I used an arbitrary temporary name for the primary domain. After the migration is complete, the temporary domain name continues to be used until you change it. To do so, follow these instructions.

Note that after you change your primary domain, your server’s hostname will also be changed (automatically). This will cause problems with services like email unless you immediately change your server’s Reverse DNS to match the new hostname..

Change Reverse-DNS Records

As soon as possible after making changes to your primary domain, you should update your server’s Reverse DNS (PTR Records) to match. Here is the offical guide. Once that is complete, reboot your server to “make it so”:

/usr/sbin/apachectl graceful

At this point, all of your domains, DNS, hostnames, and so forth should all match up swimmingly, as reflected in both Plesk and the Account Center. To verify that the new DNS settings are working, enter the following command via Terminal or your favorite app:

host xxx.xxx.xxx.xxx

Replacing the x’s with your IP address, you should see results similar to this:

123.456.789.abc-def.whatever domain name pointer current.example.com

For more info on this, check out this mind-blowing knowledgeBase article (404 link removed 2016/11/28).

Remove tempoary domain from Plesk

After everything was complete and the dust had settled, I logged in to Plesk to find that the temporary domain used for the migration (the one we changed in a previous step) was still listed among my other domains. After completing the server transfer, this remnant domain is no longer necessary, but apparently can’t be removed without causing problems for other actual domains. After a call to (mt) support, a technician looked into this situation and confirmed that there is no way to remove the temporary domain:

I was unable to remove the primary domain on my (dv) Dedicated-Virtual 4.0 Server without causing any issues to my domains underneath the subscriptions.

Oh well, if that’s the worst side-effect of transferring to a better server, well.. I can live with that. It would be nice to remove it though, seems sloppy to have to leave it there just for Plesk to work (imho).

Close your 3.x (dv) service

Finally. Once everything is complete and running tuff, don’t forget to close your old (dv) account. Depending on how things went, you may also want to take a long vacation somewhere, or maybe a nice nap.

Update your affiliate links

Lastly, don’t forget to update any affiliate links with your new primary domain. The system may redirect your affiliate links automatically (update: it won’t!), but keeping them current is probably the best way to go (update: avoiding Media Temple’s affiliate program is the best way to go!).

Update: Over the past several years since writing this article, I’ve come to realize that Media Temple’s affiliate program is an absolute joke. They keep changing everything — affiliate IDs, URLs, accounts — making it impossible to keep track of anything or figure out what’s going on. They even changed the entire affiliate platform to a 3rd-party service, requiring affiliates to re-register at a new service with all new links and a million “agree to terms” requirements. So the previous affiliate links stopped working and who knows what else was lost or broken in the process. So NO THANKS, Media Temple.. if you can’t manage to be clear and consistent with your affiliate program, I want nothing to do with it. Just not enough time in the day to chase around your arbitrary changes just to keep up and hopefully get paid. Just not worth it, bruh.</update>

Wrap up

I hate this article! But it feels good to bring it all together for the record, plus provide some closure to the process further justified as a learning experience. Migrating to the new (dv) server is a lot of (unexpected/uplanned) work, but it’s worth it, in my opinion. So far I couldn’t be happier with the new (dv)-4.0 server.

Thank you Huge thanks to the super-awesome (mt) support staff. They are one of the main reasons why I continue to recommend Media Temple to customers and visitors. If you’ve found this article helpful and plan on hosting with (mt), please send a donation so I can help provide for my family. Thank you!

Useful Resources

Here are some additional resources that proved useful during the migration process.

• Plesk 10 Administrator’s Guide
• Default System Paths for (dv) 4.0
• Connecting via SSH to your server
• Tips on migrating to a (dv) 4.0 from a (dv) 3.x (404 link removed 2016/11/28)
• Using MySQL Report on a (dv) Dedicated-Virtual Server (404 link removed 2016/11/28)
• Using MySQLTuner
• Basic MySQL performance tuning (MySQLd)
• (dv) Increasing Max MySQL Connections
• How do I enable or disable Power User mode for my (dv) 4.0?

One more tip! You can see a complete list of all default system paths on your server. Just log in to the Account Center and click on the “System Guide” icon thing:

The System Guide in the Account Center lists many useful bits of information

About the Author

Jeff Starr = Web Developer. Book Author. Secretly Important.