Friday, February 24, 2012

Migrate Virtuozzo containers to VMware ESXi virtual machine

Since Virtuozzo uses VZFS, which shares its common files with the host operating system, it's not possible to convert a container to a virtual machine, as you would do a physical to virtual, or virtual to virtual migration.
So the VMware converter cannot be used, you'll get an error indicating that the source server details cannot be retrieved, both on Windows and Linux.

As a workaround, you can migrate the containers to Parallels virtual machines. For this you need the PSBM (Parallels Server Bare Metal) product. Install this hypervisor on a physical machine, it supports installation inside virtual machines, but there are limitations, read about them here.

Once you have the PSBM, you are ready to migrate the containers to virtual machines. The "pmigrate" CLI tool can be used to do this, as such:

Linux:       pmigrate ct vm localhost/vmname
Windows: pmigrate ct vm localhost/vmname

A prerequisite for this migration, is that you have the Parallels transporter agent installed, on the Virtuozzo source hardware node. Installers for both Linux and Windows can be found under /usr/share/pmigrate/tools/ on the PSBM.

It's a live migration, the container stays online, during and after migration is finished.
Depending on the guest operating system of the container, the Parallels tools (equivalent to VMware tools) will be automatically installed inside the virtual machine during the migration process.

There are limitations on which guest OS can be migrated, I have tried these with success:
Debian 5 x86/x64
Debian 6 x86/x64
Windows 2003 x64
Windows 2008R2 x64

For a complete list of supported guest operating systems, browse to page 31 on this document.

Once the virtual machine is running on PSBM, you can use the VMware converter for migration to an ESXi server. You can use the converter on 2 different ways.

  • If the virtual machine is online and accessible from the ESXi and converter, you can do a migration as you would do a powered-on physical machine
  • Another way is to use the "Backup image or third-party virtual machine" converter option. You'll need the Parallels VM configuration and harddisk files, these can be found under /var/parallels/ on the PSBM.

A couple remarks:

  • The cpu/memory/disk resources from the original containers will have to be reapplied after migration, since these are not preserved
  • Because of the hardware changes, Windows (2008R2) will have to be re-activated after migration
  • Remove the Parallels tools on Windows guests, before converting them from PSBM to VMware. I wasn't able to uninstall this software anymore once the VM was running on VMware.

Monday, November 7, 2011

Paralells Virtuozzo Linux 4.7 kernel panic

After upgrading from PVCfL 4.0 / 4.6 to version 4.7, kernel panics started to occur randomly on almost all hardware nodes.
I configured kdump on the nodes to collect a kernel dump upon the next kernel panic, and contacted Parallels support team.
When the kernel panic occured and the dump was created, they analyzed it.

The feedback we got was the following:
The latest saved dump points to general protection fault caught by `mysqld`. This looks like just recently found issue - PCLIN-30321. I will pass it to the maintenance team.
As for the type of installation - there is no difference if this is a clean installation or an upgrade from the previous version of Virtuozzo.
The issue is quite complex (General Protection Fault from a process in a container is quite difficult to investigate), and it would take some time for maintenance / development team to check the case.
Though, the investigation might take significant amount of time and therefore the results will be provided through the separate ticket once they are ready.
You can also check the release notes for Virtuozzo kernel updates (CU-2.6.32-042stabXXX), and monitor the status of the request PCLIN-30321 which was assigned for this crash issue.

It's not always caused by 'mysqld', I've seen a kernel panic caused by another process as well, but most were indeed due to mysqld.
We don't know how long it will take for this to be fixed, so we decided to migrate the containers which cause the kernel panics to a 4.0 or 4.6 node.

Finding out which container caused the kernel panic can be done by using the crash tool.
An example:

[root@virtuozzo]# crash /root/vmlinux-2.6.32-042stab037.1 vmcore
crash 4.1.2-8.el5.centos

      KERNEL: /root/vmlinux-2.6.32-042stab037.1
    DUMPFILE: vmcore
        CPUS: 8
        DATE: Sat Nov  5 10:00:13 2011
      UPTIME: 10 days, 10:12:02
LOAD AVERAGE: 19.68, 15.35, 14.01
       TASKS: 2239
    NODENAME: virtuozzo
     RELEASE: 2.6.32-042stab037.1
     VERSION: #1 SMP Fri Sep 16 22:18:06 MSD 2011
     MACHINE: x86_64  (1995 Mhz)
      MEMORY: 32 GB
       PANIC: ""
         PID: 62872
     COMMAND: "mysqld"
        TASK: ffff88024d6892c0  [THREAD_INFO: ffff8802d65e4000]
         CPU: 5

crash> dmesg
[900722.171220] Process mysqld (pid: 62872, veid=7420232, threadinfo ffff8802d65e4000, task ffff88024d6892c0)

Update 15/11/2011
On 14/11/2011, Parallels has released a kernel update which contains a fix for this problem. More information on

Tuesday, March 29, 2011

Plesk 10: display os/browser/robots in awstats statistics

I'm using Plesk 10.1 on a Debian 5.0 VPS, and noticed that the statistics (Awstats) for my domains did not contain all the information I want, such as statistics for operating systems, browsers, robots/spiders.

I checked several configuration files, and found that the "plesklog" format, that Plesk uses to define the Apache LogFormat value, does store this information in the logfiles.
However, the Awstats model configuration file is not properly configured to retrieve this information from the logs.

By default, the value of the LogFormat parameter in /etc/awstats/awstats.model.conf will be "LogFormat=4", which is the Apache native common log format, not the combined, or plesklog format.
By changing this value to "LogFormat=1", these features (browsers, os, robots,...) will be shown in the statistics of your domain(s).

After modifying the awstats.model.conf file, you'll need to modify the awstats configuration files for your existing domains.
You can use this perl script to do so:
perl -e "s/LogFormat=4/LogFormat=1/g;" -pi $(find /opt/psa/etc/awstats/ -type f)

This will go through all the files inside the /opt/psa/etc/awstats/ directory, look for "LogFormat=4", and replace it by "LogFormat=1". Be sure to create a backup of all your files, in case something goes wrong.

The new statistics features will only be visible after the next calculation.

Monday, March 28, 2011

Parallels Virtuozzo Linux vzbackup error

Last week, I installed a new PVC Linux 4.6 node, and added it as a slave to an existing PVA (Parallels Virtual Automation) group.
I use the vzbackup cronjob to backup all the containers on the hardware nodes.
The node that initiates the backup cronjob, had PVC Linux 4.0 installed, all the other slave nodes have version 4.0 installed as well.

The backup of the new 4.6 node failed with this error message:

vzbackup(2861): Starting backup. Nodes - virtuozzo10
vzbackup(2861): Starting node virtuozzo10 backup...
vzbackup(2861): Checking backup version on virtuozzo10 ... use vzbackup 4.6.0-9
vzbackup(2861): Starting node virtuozzo10 backup...
vzbackup(2861): Starting backup CT 1(virtuozzo10)...
bash: /usr/share/vzbackup-4.6.0-9.swsoft/vzbackup1: No such file or directory
vzbackup(2861): Can not read layout version for CT 1(virtuozzo10)
vzbackup(2861): No containers intended for backup found on virtuozzo10

The cause of this error message is that vzbackup 4.0 cannot create backups of containers on a 4.6 node.

Luckily, the other way around does work. After upgrading the node that initiates backups from 4.0 to 4.6, backups of the new node succeeded.
Backups of the other 4.0 nodes also remained successfully.

Using vzbackup on a PVC 4.6 node to backup 4.0 nodes is a supported method by Parallels.

Friday, January 9, 2009

Disable UAC in Windows Server 2008

You can disable the UAC feature in Windows Server 2008 by following these steps:

  • Start -> Run -> msconfig

  • Click Tools and scroll down to "Disable UAC"

  • Click the Launch button and reboot the server.

Friday, November 14, 2008

Install .NET 3.5 framework on virtuozzo container

When installing the .NET 3.5 framework on a Windows 2003 SP2 x64 VPS I got these errors, using the web or full installer:

XPSEPSC x64 Installer: [2] Error code 1603 for this component means "Fatal error during installation.
XPSEPSC x64 Installer: [2] Setup Failed on component XPSEPSC x64 Installer
WapUI: [2] DepCheck indicates XPSEPSC x64 Installer is not installed.

To install .NET 3.5 framework on a windows virtuozzo container, perform these steps for a successfull installation:

  • Restart the VPS

  • Rename the C:\windows\system32\catroot2\ folder (not catroot itself but catroot2)

  • Start the print spooler service

  • Run the .NET 3.5 SP1 installer

  • Reboot if necessary

Thursday, March 13, 2008

Backup SQL databases to network share

To be able to backup databases to a network share, the MSSQLSERVER service needs access to the location on the network.
For this you need to change the SQL services service account.
Before doing this you'll need to give that user extra permissions, to accomplish this you can add the user to all the SQLServer2005* or SQLServer2008* groups.

To change the logon user go to "SQL Server Configuration Manager". Under Services, click on properties for the MSSQLSERVER.
Here you can change the logon account to the one you'll need. Specify this to a domain user, or a local user that also exists on the machine where you will store the databases, and that has the full access share and NTFS permissions.
After modifying the logon name, you'll have to restart the service. Do the same for the SQL Server Agent.

Now you'll be able to backup databases to a network share and specify the path like this then: \\servername\share.