Virtuozzo Templates and Security Updates

[kccricket]

As I understand it, this is how Virtuozzo handles disk and memory usage in regard to templates: As long as a VPS sticks to the template and does not update packages outside of the template, then disk and memory usage will impacted very little. Once a user begins updating packages outside the template, they will see their disk and memory usage climb since the files can no longer be shared across VPSs.

I know that HSPComplete has an interface to Add/Remove/Update "Applications" on the VPS. When using this tool to modify installed packages, does it automatically update the Guest OS package manager's database to reflect the changes? On average, how quickly are security updates (e.g. from Debian or CentOS) available through HSPComplete? Does HSPComplete show updates for all packages or just the major packages?

Alternatively, if I'm totally off the mark, how does it work?

[Ray]

That is essentially correct with how Virtuozzo used to work. With the new system, this is supposed to be improved. There is now a much better implementation of application and os templates, allowing us to easier customize packages as we like.

As a note, the space usage savings really apply to the OS only. Additionally, they are designed to work with Plesk, but I'm not sure they work entirely correctly. If you use cPanel or Interworx as your control panel, these will be installed on the guest OS and will use up disk space.

In the past, with Virtuozzo's old OS template system, updates took a very long time to reach us. I believe we were running CentOS 3.3 or perhaps older templates. We would then update the packages via yum, but this then added to the disk space in use on the individual VPS. It seems that now, the OS templates are a list of packages installed from a centralized repository that gets updated much more frequently, though it is difficult to determine whether this is for sure the case, as we have just recently begun testing these packages.

[kccricket]

Thanks for your informative reply.

What about as far as memory usage is concerned? Can installing custom or updated versions of applications (e.g. apache-httpd, mysql, spamassassin) cause those applications to use up larger chunks of your memory quota as opposed to the templated versions?

(The following is posted with the risk of crossing over into a support question...)
I ask this because on my current VPS with Steadfast I replaced many of the core PSA packages, httpd, mysql, and spamassassin with updated versions from Atomic Rocket Turtle (http://www.atomicrocketturtle.com/). After I had done this, it seemed to me that I was using much more memory than usual. To this day, I have to periodically restart services to keep from hitting the mempages hard limit. I realize that my memory usage may not be directly related to deviating from the template. I have thought of several alternative possibilities: 1) it simply coincided with an increase in popularity of the sites I host, hence requiring more memory; 2) the ART packages leak memory or use more memory than their PSA counterparts; 3) my services are poorly configured.

Once all of your Virtuozzo upgrade and testing issues are out of the way, I'd be very interested in starting anew on a fresh Debian 3.1 VPS with no control panel.

[Ray]

Yes, using upgraded or non-standard versions of any software will most likely cause higher VPS memory usage than the ones packaged into the VPS. cPanel is most notable for this, as it compiles its own version of Apache and such, whereas Plesk and Interworx can use the RPM versions from the CentOS repository.

The cause of the higher memory usage is most likely due to using the ART versions of the software. I would like to note that with the upgraded Virtuozzo packages, memory handling is a lot less complex, and it may prove to be beneficial by not allowing such restarting of services and VPSes as often. I don't know for sure, as we haven't gotten to a point of being able to test this yet, but we've been impressed with a lot of the new features available.