When it comes to a virtual machine’s clock my experience with other virtualization solutions has been that it’s automatically synchronized with the host machine. I didn’t notice until recently that this is not the case with Citrix Xenserver – at least when it comes to PVHVM machines.
I tried installing openntpd on each of my VMs and setting it to my internal NTP server (which in turn synchronizes with the web.) After a few days I was frustrated to see that the servers were still not in sync – some were minutes behind while others were inexplicably minutes ahead. Some of this might have to do with my experiments on live migrating these VMs a while back.
At any rate, it was clear that openntpd failed to do the job. Some research revealed that there is a bug where it reports adjusting the clock when the real status was an error. That little bug cost me an hour or two of digging and troubleshooting. Very frustrating.
I switched to plain old ntp instead and the problem was resolved within moments.
Moral of the story: Make sure you have a proper NTP setup for each of your VMs if you’re going to use Citrix Xenserver.
When you run a query in Splunk it returns the most recent result at the top of the screen by default.
For far too long now I have been running queries in Splunk and then manually clicking back to the last page of results so that I can see the first time something happened.
It turns out there is a better way. Simply append ” | reverse” (without quotes) to the end of your search result. This will cause the earliest search result to be at the top, rather than the most recent. Handy.
After installing a fresh installation of WordPress on LAMP (Linux, Apache, MySQL, and PHP) I decided to change the new site’s permalink structure. The default structure on WordPress is so boring and uninformative – sitename/?p=(number). I prefer the blogger method – sitename/year/month/postname.
Changing the structure should be pretty straightforward; However, when I clicked that option and clicked save, every post greeted me with a wonderful 404 error page.
If you are running apache it turns out there are a few extra things you need to do that aren’t mentioned in WordPress’s 5 minute install guide. Detailed instructions are found here.
Enable the mod-rewrite apache plugin
Ensure the directory of your wordpress installation has a Directory entry and that AllowOverride All is enabled
After this, everything worked. The reason behind needing this change is WordPress modifies the .htaccess file for its installation folder with a simple rule:
All it does is transparently prepend index.php to any web request it receives. Index.php is smart enough to direct pages wherever it needs to after that. If you don’t want to mess with enabling mod_rewrite, you can simply change your site structure to have /index.php/ before everything else. It will accomplish the same thing, only now index.php will show up in all your site URLs.
Since Citrix recently released the entire Xenserver product to the world as free, open source software I thought I might give it a try. I have been pleased with the results and wanted to migrate my desktop VM over to it.
I’ve had a devil of a time getting my Windows 8.1 Professional virtual machine to migrate from plain Xen to Citrix Xenserver 6.2. My first mistake was not doing research before migrating hypervisor environments. While it is true that Citrix uses Xen as the underlying hypervisor, it turns out that there are still plenty of differences between the two environments.
I thought I would take the easy route by installing Citrix Xenconvert and converting my Xen Win8.1 VM to a format Xenserver likes. Although Xenconvert was designed for Physical to Virtual migration, I’ve found in the past that it works just as well for virtual to virtual migration.
After migrating to Xenserver I was greeted with the following friendly message:
As far as I can tell it was the Xen GPLPV drivers that were the culprit. This leads me to my second mistake: not having a proper backup of the VM. I didn’t keep a backup of this VM in the Xen-friendly format after I migrated it to xenserver. This was mainly due to laziness – a classic example of “one ounce of laziness now produces one ton of hard work later.”
Instead of simply just booting the VM and removing the GPLPV drivers I had to attempt to do it via the Windows PE on the Windows 8.1 disc. I first tried running the GPLPV uninstall script from here, modifying it to point to the c:\ drive for both files and registry settings. Alas, that didn’t appear to do anything.
I then tried to go through the registry via the Windows PE and remove any references to Xen-anything. Success! Or so I thought. It turns out that blindly plowing through the Windows registry without an idea of exactly what you were doing has consequences. The VM would boot but I could not for the life of me get network drivers to work. As far as I can tell I corrupted something in the registry and despite my best efforts I couldn’t fix it.
At this point I had learned to back things up so I kept restoring from backups and messing with removing various registry keys. I continued this trial and error process for some time. After much weeping, wailing, and gnashing of teeth, I finally found the right combination of keys you must remove in order to boot again.
I took what I learned and updated the script from above to make it work with the WinPE environment . Download it here.
Boot into your PE environment of choice and run the script. When it’s finished, your VM will now be able to boot successfully.
The last step is to go into device manager and delete all xen-related drivers, then re-install them. After all that is said and done, your migration from xen to xenserver is complete. Repeat the exact same process to migrate from xenserver back to xen.