You are viewing openvz

Jul. 3rd, 2015

Parallels and Docker: Not Just Competition


One of the questions that people ask us is how Parallels competes with Docker and why we do nothing while Docker is busy conquering the market? Firstly, since we created containers a decade ago, we have been perfecting container virtualization and pushing it to upstream. Secondly, Parallels and Docker operate on different levels: Docker packages and runs applications while Parallels provide virtualization, a low-level technology that Docker uses. This allows us to partner in a number of projects. Moreover, all existing container-related projects in the market do more than just compete with each other. We also try to cooperate in developing shared components.


One good example is the libcontainer project that unifies two versions of a library that manages kernel components used in container creation. We are currently trying to standardize how our own OpenVZ as well as Docker and other projects interact with the Linux kernel. We also want to bind libcontainer to primary programming languages to provide more scenarios of container use in the market. Besides, we plan to integrate containers with OpenStack via libcontainer.

The libcontainer project has interesting history, by the way. Docker was initially meant to be a container template management project that used vzctl to run containers. Then its developers moved to LXC and then came up with their own libcontainer library. At the same time we decided to "standardize" containers' kernel-related part and create a low-level library. In all, there were as many as three such systems at that time: ours, LXC, and libcontainer. We reworked our version and presented it to the public. And it happened so that our announcement was very close to the initial release of Docker's library. Since the projects pursued the same goal, we decided to join forces. Libcontainer has several points of interest for us. Firstly, one willing to use containers has to choose between several projects. This is inconvenient for users and costly for developers (as they have to support multiple versions of essentially the same technology). However, the entire stack will be standardized sooner or later and we'd like to participate to be able to control both the development and results. Secondly, we'll be able to achieve the dream of many users to run Docker containers on our stable kernel.

Recently, we announced jointly with Docker that Virtuozzo (the successor of OpenVZ and Parallels Cloud Server) supports Docker containers and allows creating "containers within containers", i.e. use Docker inside Virtuozzo.

Another good example of cooperation is live migration of Docker (and LXC) containers made possible by our CRIU project (Checkpoint/Restore In Userspace [mostly]). This technology enables you to save the state of a Linux process and restore it in a different location or at a different time (or "freeze" it). Moreover, this is the first ever implementation of an application snapshot technology that works on unmodified Linux (kernel + system libraries) and supports any process state. It's available, for example, in Fedora 19 and newer. There were similar projects before, but they had drawback, e.g., required specific kernels and customized system libraries or supported only some process states.

The live migration itself is performed by the P.Haul subproject that uses CRIU to correctly migrate containers between computers. CRIU allows performing two key actions: 1) save process states to files and 2) restore processes from saved data. There are nuances, for example, CRIU can work without stopping processes and save only changes to process states if need be.

Migration is more difficult and implies at least three actions: 1) saving process state, 2) transferring it to a different computer, and 3) restoring the saved state. In actuality, it can also include transferring the file system, stopping the processes on the source computer and destroying them in the end as well as reducing freeze time by performing a series of memory transfers and saving changes in state, additional copying of memory after migration.

Migration can also include such actions as transferring container's IP address, reregistering it with the management system (e.g., docker-daemon in Docker), handling container's external links. For example, LXC often links files inside containers with files outside it. You can have CRIU relink such files on the destination computer. Development of all these features and nuances was organised into a dedicated project.

Today CRIU is a standard for implementing checkpoint/restore functionality in Linux (even though VMware claimed one should use vMotion for container migration). In this project we also cooperate with developers from Google, Canonical, and RedHat. They not only send patches but also actively discuss cgroup support in CRIU and successfully use CRIU with Docker and LXC tools.

The CRIU technology has lots of uses aside from live migration: speeding up start of large applications, rebootless kernel updates, load balancing, state backup for failure recovery. Usage scenarios include network load balancing, analysis of application behaviour on different computers, process duplication, and such.

via

Analyzing OpenVZ Components with PVS-Studio

Author: Svyatoslav Razmyslov

In order to demonstrate our analyzer's diagnostic capabilities, we analyze open-source projects and write articles to discuss any interesting bugs we happen to find. We always encourage our users to suggest interesting open-source projects for analysis, and note down all the suggestions we receive via e-mail. Sometimes they come from people closely related to the project we are asked to check. In this article, we will tell you about a check of the components of the OpenVZ project we have been asked to analyze by the project manager Sergey Bronnikov.

About PVS-Studio and OpenVZ

PVS-Studio is a static analyzer designed to detect errors in source code of C/C++ applications. It can be downloaded from the official website but is available for operating systems of the Windows family only. Therefore, to be able to analyze OpenVZ components in Linux, we had to use a PVS-Studio beta-version we once used to check the Linux Kernel.

OpenVZ is an operating system-level virtualization technology based on the Linux kernel and operating system. OpenVZ allows a physical server to run multiple isolated operating system instances, called containers, virtual private servers (VPSs), or virtual environments (VEs).

Analysis results

OpenVZ components are small-sized projects, so there were relatively few warnings yet they were very characteristic of software written in C++.

Troubles with pointers

V595 The 'plog' pointer was utilized before it was verified against nullptr. Check lines: 530, 531. CPackedProblemReport.cpp 530

void

CPackedProblemReport::appendSystemLog( CRepSystemLog * plog )

{

QString strPathInTemp = m_strTempDirPath + QString("/") +

QFileInfo( plog->getName() ).fileName();

if( !plog )

{

QFile::remove( strPathInTemp );

return;

}

....

}

It's a genuine pointer handling bug. The 'plog' pointer is dereferenced right after entering the function and only then is checked for being valid.

V595 The 'd' pointer was utilized before it was verified against nullptr. Check lines: 1039, 1041. disk.c 1039

int vzctl2_add_disk(....)

{

....

if (created)

destroydir(d->path);

if (d)

free_disk(d);

return ret;

}

In this case, when the 'created' flag is set, the 'd' variable will be dereferenced, though the next code line suggests that the pointer may be null. This code fragment can be rewritten in the following way:

int vzctl2_add_disk(....)

{

....

if (d)

{

if (created)

  destroydir(d->path);

free_disk(d);

}

return ret;

}

V595 The 'param' pointer was utilized before it was verified against nullptr. Check lines: 1874, 1876. env.c 1874

int

vzctl2_env_set_veth_param(....,

                      struct vzctl_veth_dev_param *param,

                      int size)

{

int ret;

struct vzctl_ip_param *ip = NULL;

struct vzctl_veth_dev_param tmp = {};

memcpy(&tmp, param, size);

if (param == NULL || tmp.dev_name_ve == NULL)

return VZCTL_E_INVAL;

....

}

The 'memcpy' function copies the contents of one memory area into another. The second function parameter is a pointer to the source address. The function contains a check of the 'param' pointer for null, but before that the pointer is used by the 'memcpy' function, which may cause a null-pointer dereferencing operation.

V595 The 'units' pointer was utilized before it was verified against nullptr. Check lines: 607, 610. wrap.c 607

int vzctl_set_cpu_param(....)

{

....

if (weight != NULL &&

  (ret = vzctl2_env_set_cpuunits(param, *units * 500000)))

goto err;

if (units != NULL &&

  (ret = vzctl2_env_set_cpuunits(param, *units)))

goto err;

....

}

The analyzer's warning about the 'units' pointer being checked for null before being used may hint at a typo in this code. In the first condition, the 'weight' pointer being checked is not used. It should have probably looked like this:

if (weight != NULL &&

(ret = vzctl2_env_set_cpuunits(param, *weight * 500000)))

goto err;

V668 There is no sense in testing the 'pRule' pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error. PrlHandleFirewallRule.cpp 59

PRL_RESULT PrlHandleFirewallRule::Create(PRL_HANDLE_PTR phRule)

{

PrlHandleFirewallRule* pRule = new PrlHandleFirewallRule;

if ( ! pRule )

return PRL_ERR_OUT_OF_MEMORY;

*phRule = pRule->GetHandle();

return PRL_ERR_SUCCESS;

}

The analyzer has detected an issue when a pointer value returned by the 'new' operator is compared to zero. If the 'new' operator fails to allocate a required amount of memory, the C++ standard forces the program to throw an std::bad_alloc() exception. Therefore, checking the pointer for null doesn't make sense. The developers need to check which kind of the 'new' operator is used in their code. If it is really set to throw an exception in case of memory shortage, then there are 40 more fragments where the program may crash.

Troubles with classes

V630 The 'malloc' function is used to allocate memory for an array of objects which are classes containing constructors and destructors. IOProtocol.cpp 527

/**

* Class describes IO package.

*/

class IOPackage {

public:

/** Common package type */

typedef quint32 Type;

....

};

IOPackage* IOPackage::allocatePackage ( quint32 buffNum )

{

return reinterpret_cast<IOPackage*>(

::malloc(IOPACKAGESIZE(buffNum))

);

}

The analyzer has detected a potential error related to dynamic memory allocation. Using malloc/calloc/realloc functions to allocate memory for C++ objects leads to a failure when calling the class constructor. The class fields are therefore left uninitialized, and probably some other important actions can't be accomplished as well. Accordingly, in some other place, the destructor can't be called when memory is freed through the free() function, which may cause resource leaks or other troubles.

V670 The uninitialized class member 'm_stat' is used to initialize the 'm_writeThread' member. Remember that members are initialized in the order of their declarations inside a class. SocketClient_p.cpp 145

class SocketClientPrivate:protected QThread,

                      protected SocketWriteListenerInterface

{

....

SocketWriteThread m_writeThread;  //<==line 204

....

IOSender::Statistics m_stat;      //<==line 246

....

}

SocketClientPrivate::SocketClientPrivate (....) :

....

m_writeThread(jobManager, senderType, ctx, m_stat, this),

....

{

....

}

The analyzer has detected a potential bug in the class constructor's initialization list. Under the C++ standard, class members are initialized in the constructor in the same order they were declared in the class. In this case, the m_writeThread variable will be the first to be initialized instead of m_stat.

So it may be unsafe to construct 'm_writeThread' using the 'm_stat' field as one of the arguments.

V690 The 'CSystemStatistics' class implements a copy constructor, but lacks the '=' operator. It is dangerous to use such a class. CSystemStatistics.h 632

class CSystemStatistics: public CPrlDataSerializer

{

public:

....

/** Copy constructor */

CSystemStatistics(const CSystemStatistics &_obj);

/** Initializing constructor */

CSystemStatistics(const QString &source_string);

....

}

There is a copy constructor for this class but its assignment operator has not been redefined.

The "Rule of three" (also known as the "Law of the Big Three" or "The Big Three") is violated here. This rule claims that if a class defines one (or more) of the following it should probably explicitly define all three:

destructor;

copy constructor;

copy assignment operator.

These three functions are special member functions automatically implemented by the compiler when they are not explicitly defined by the programmer. The Rule of Three claims that if one of these had to be defined by the programmer, it means that the compiler-generated version does not fit the needs of the class in one case and it will probably not fit in the other cases either and lead to runtime errors.

Other warnings

V672 There is probably no need in creating the new 'res' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 367, 393. IORoutingTable.cpp 393

bool IOJobManager::initActiveJob (

SmartPtr<JobPool>& jobPool,

const IOPackage::PODHeader& pkgHeader,

const SmartPtr<IOPackage>& package,

Job*& job,                               //<==

bool urgent )

{

....

while ( it != jobPool->jobList.end() ) {

    Job* job = *it;                      //<==

    if ( isJobFree(job) ) {

        ++freeJobsNum;

        // Save first job

        if ( freeJobsNum == 0 ) {

            freeJob = job;

            firstFreeJobIter = it;

        }

    }

    ++it;

}

....

}

It is strongly recommended not to declare variables bearing the same names as function arguments. You should generally avoid having identical names for local and global variables. Otherwise, it may cause a variety of errors due to careless use of such variables. Besides incorrect program execution logic, you may face an issue when, for instance, a global pointer points to a local object which will be destroyed in the future, and since it takes some time before a memory area is cleared, this error will take an irregular character.

Other issues of this kind:

V672 There is probably no need in creating the new 'job' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 337, 391. IOSendJob.cpp 391

V672 There is probably no need in creating the new 'res' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 367, 393. IORoutingTable.cpp 393

V610 Undefined behavior. Check the shift operator '<<'. The left operand '~0' is negative. util.c 1046

int parse_ip(const char *str, struct vzctl_ip_param **ip)

{

....

if (family == AF_INET)

    mask = htonl(~0 << (32 - mask));

....

}

The analyzer has detected a shift operation leading to undefined behavior. The reason behind it is that in the '~0' operation, the number will be inverted into signed int and therefore there will be a negative number shift, which, under the C++ standard, leads to undefined behavior. The unsigned type should be defined explicitly.

Correct code:

int parse_ip(const char *str, struct vzctl_ip_param **ip)

{

....

if (family == AF_INET)

    mask = htonl(~0u << (32 - mask));

....

}

Two more warnings of this kind:

V610 Undefined behavior. Check the shift operator '<<'. The left operand '~0' is negative. util.c 98

V610 Undefined behavior. Check the shift operator '<<'. The left operand '~0' is negative. vztactl.c 187

V547 Expression 'limit < 0' is always false. Unsigned type value is never < 0. io.c 80

int

vz_set_iolimit(struct vzctl_env_handle *h, unsigned int limit)

{

int ret;

struct iolimit_state io;

unsigned veid = eid2veid(h);

if (limit < 0)

return VZCTL_E_SET_IO;

....

}

The analyzer has detected an invalid conditional expression in this function. An unsigned variable can never be less than zero. This condition is probably just an excessive one, but it is also possible that identification of an incorrect state was meant to be implemented in some other way.

Another similar fragment:

V547 Expression 'limit < 0' is always false. Unsigned type value is never < 0. io.c 131

Conclusion

At first, the developers suggested checking an already existing beta-version to be released soon - the version ".... where we will at least rewrite all the planned product parts and fix the bugs found during the testing stage". But that would hugely contradict the static analysis ideology! Static analysis is most efficient and beneficial when used at the earlier development stages and on a regular basis. A single-time check of your project may help improve the code at some point but the overall quality will remain at the same low level. Delaying code analysis till the testing stage is the greatest mistake however you look at it - either as a manager or a developer. It is cheapest to fix a bug at the coding stage!

This idea is discussed in more detail by my colleague Andrey Karpov in the article "How Do Programs Run with All Those Bugs At All?" I especially recommend reading the sections "No need to use PVS-Studio then?" and "PVS-Studio is needed!" And may your code stay bugless!

OpenVZ / Virtuozzo 7 First Impressions

Odin and the OpenVZ Project announced the beta release of a new version of Virtuozzo today. This is also the next version of OpenVZ as the two are merging closer together.

There will eventually be two distinct versions... a free version and a commercial version. So far as I can tell they currently call it Virtuozzo 7 but in a comparison wiki page they use the column names Virtuozzo 7 OpenVZ (V7O) and Virtuozzo 7 Commercial (V7C). The original OpenVZ, which is still considered the stable OpenVZ release at this time based on the EL6-based OpenVZ kernel, appears to be called OpenVZ Legacy.

Odin had previously released the source code to a number of the Virtuozzo tools and followed that up with the release of spec-like source files used by Virtuozzo's vztt OS Template build system. The plan is to migrate away from the OpenVZ specific tools (like vzctl, vzlist, vzquota, and vzmigrate) to the Virtuozzo specific tools although there will probably be some overlap for a while.

The release includes source code, binary packages and a bare-metal distro installer DVD iso.

Bare Metal Installer

I got a chance to check out the bare-metal installer today inside of a KVM virtual machine. I must admit that I'm not very familiar with previous Virtuozzo releases but I am a semi-expert when it comes to OpenVZ. Getting used to the new system is taking some effort but will all be for the better.

I didn't make any screenshots yet of the installer... I may do that later... but it is very similar to that of RHEL7 (and clones) because it is built by and based on CloudLinux... which is based on EL7.

CloudLinux Confusion

What is CloudLinux? CloudLinux is a company that makes a commercial multi-tenant hosting product... that appears to provide container (or container-like) isolation as well as Apache and PHP enhancements specifically for multi-tenant hosting needs. CloudLinux also offers KernelCare-based reboot-less kernel updates. CloudLinux's is definitely independent from Odin and the CloudLinux products are in no way related to Virtuozzo. Odin and CloudLinux are partners however.

Why is the distro based on CloudLinux and does one need a CloudLinux subscription to use it? Well it turns out that Odin really didn't want to put forth all of the effort and time required to produce a completely new EL7-clone. CloudLinux is already an expert at that... so Odin partnered with CloudLinux to produce a EL7-based distro for Virtuozzo 7. While CloudLinux built it and (I think) there are a few underlying CloudLinux packages, everything included is FOSS (Free and Open Source Software). It DOES NOT and WILL NOT require a CloudLinux subscription to use... because it is not related to CloudLinux's product line nor does it contain any of the CloudLinux product features.

The confusion was increased when I did a yum update post-install and if failed with a yum repo error asking me to register with CloudLinux. Turns out that is a bug in this initial release and registration is NOT needed. There is a manual fix of editing a repo file in /etc/yum.repos.ed/) and replacing the incorrect base and updates URLs with a working ones. This and and other bugs that are sure to crop up will be addressed in future iso builds which are currently slated for weekly release... as well as daily package builds and updates available via yum.

More Questions, Some Answers

So this is the first effort to merge Virtuozzo and OpenVZ together... and again... me being very Virtuozzo ignorant... there is a lot to learn. How does the new system differ from OpenVZ? What are the new features coming from Virtuozzo? I don't know if I can answer every conceivable question but I was able to publicly chat with Odin's sergeyb in the #openvz IRC channel on the Freenode IRC network. I also emailed the CloudLinux folks and got a reply back. Here's what I've been able to figure out so far.

Why CloudLinux? - I mentioned that already above, but Odin didn't want to engineer their own EL7 clone so they got CloudLinux to do it for them and it was built specifically for Virtuozzo and not related to any of the CloudLinux products... and you do not need a subscription from Odin nor CloudLinux to use it.

What virtualization does it support? - Previous Virtuozzo products supported not only containers but a proprietary virtual machine hypervisor made by Odin/Parallels. In Virtuozzo 7 (both OpenVZ and Commercial so far as I can tell) the proprietary hypervisor has been replaced with the Linux kernel built-in one... KVM. See: https://openvz.org/QEMU

How about libvirt support? - Anyone familiar with EL7's default libvirtd setup for KVM will be happy to know that it is maintained. libvirtd is running by default and the network interfaces you'd expect to be there, are. virsh and virt-manager should work as expected for KVM.

Odin has been doing some libvirt development and supposedly both virsh and virt-manager should work with VZ7 containers. They are working with upstream. libvirt has supposedly supported OpenVZ for some time but there weren't any client applications that supported OpenVZ. That is changing. See: https://openvz.org/LibVirt

Command line tools? - OpenVZ's vzctl is there as is Virtuozzo's prlctl.

How about GUIs or web-based management tools? - That seems to be unclear at this time. I believe V7C will offer web-based management but I'm not sure about V7O. As mentioned in the previous question, virt-manager... which is a GUI management tool... should be usable for both containers and KVM VMs. virsh / virt-manager VZ7 container support remains to be seen but it is definitely on the roadmap.

Any other new features? - Supposedly VZ7 has a fourth-generation resource management system that I don't know much about yet. Other than the most obvious stuff (EL7-based kernel, KVM, libvirt support, Virtuozzo tools, etc), I haven't had time to absorb much yet so unfortunately I can't speak to many of the new features. I'm sure there are tons.

About OS Templates

I created a CentOS 6 container on the new system... and rather than downloading a pre-created OS Template that is a big .tar.gz file (as with OpenVZ Legacy) it downloaded individual rpm packages. It appears to build OS Templates on demand from current packages on-demand BUT it uses a caching system whereby it will hold on to previously downloaded packages in a cache directory somewhere under /vz/template/. If the desired OS Template doesn't exist already in /vz/template/cache/ the required packages are downloaded, a temporary ploop image made, the packages installed, and then the ploop disk image is compressed and added to /vz/template/cache as a pre-created OS Template. So the end result for my CentOS 6 container created /vz/template/cache/centos-6-x86_64.plain.ploopv2.tar.lz4. I manually downloaded an OpenVZ Legacy OS Template and placed it in /vz/template/cache but it was ignored so at this time, I do not think they are compatible / usable.

The only OS Template available at time of writing was CentOS 6 but I assume they'll eventually have all of the various Linux distros available as in the past... both rpm and deb based ones. We'll just have to wait and see.

As previously mentioned, Odin has already released the source code to vztt (Virtuozzo's OS Template build system) as well as some source files for CentOS, Debian and Ubuntu template creation. They have also admitted that coming from closed source, vztt is a bit over-complicated and not easy-to-use. They plan on changing that ASAP but help from the community would definitely be appreciated.

How about KVM VMs?

I'm currently on vacation and only have access to a laptop running Fedora 22... that I'm typing this from... and didn't want to nuke it... so I installed the bare-metal distro inside of a KVM virtual machine. I didn't really want to try nested KVM. That would definitely not have been a legitimate test of the new system... but I expect libvirtd, virsh, and virt-manager to work and behave as expected.

Conclusion

Despite the lack of perfection in this initial release Virtuozzo 7 shows a lot of promise. While it is a bit jarring coming from OpenVZ Legacy... with all of the changes... the new features... especially KVM... really show promise and I'll be watching all of the updates as they happen. There certainly is a lot of work left to do but this is definitely a good start.

I'd love to hear from other users to find out what experiences they have. If I've made any mistakes in my analysis, please correct me immediately.

Congrats Odin and OpenVZ! I only wish I had a glass of champagne and could offer up a respectable toast... and that there were others around me to clank glasses with. :)

Publishing of Virtuozzo builds



We are ready to announce publishing of binaries compiled from open components:


  • Virtuozzo installation ISO image

  • RPM packages (kernel and userspace)

  • Source RPM packages (kernel and userspace)

  • Debug RPM packages (kernel and userspace)

  • EZ templates (CentOS 7 x86_64, CentOS 6 x86_64 etc)

All installation paths described in OpenVZ wiki.

FAQ (Frequently Asked Questions)

Q: Can we use binaries or Virtuozzo distribution in production?
A: No. Virtuozzo 7 is in pre-Beta stage and we strongly recommend to avoid any production use. We continue to develop new features and Virtuozzo 7 may contain serious bugs.

Q: Would it be possible to upgrade from Beta 1 to Beta 2?
A: Upgrade will be supported only for OpenVZ installed on Cloud Linux (i.e. using Virtuozzo installation image of OpenVZ installed using yum on Cloud Linux).

Q: How often you will update Virtuozzo 7 files?
A: RPM package (and yum repository) - nightly, ISO image - weekly.

Q: I don't want to use your custom kernel or distribution. How to use OpenVZ on my own Linux distribution? A: We plan to make available OpenVZ for vanilla kernels and we are working on it. If you want it - please help us with testing and contribute patches [2]. Pay attention that using OpenVZ with vanilla kernel will have some limitations because some required kernel changes are not in upstream yet.

Building a Fedora 22 MATE Desktop Container

Fedora 22 was released today. Congrats Fedora Project!

I updated the Fedora 22 OS Template I contributed so it was current with the release today... and for the fun of it I recorded a screencast showing how to make a Fedora 22 MATE Desktop GUI container... and how to connect to it via X2GO.

Enjoy!

Tags:

CRIU on FLOSS Weekly

Here's another video... this one from FLOSS Weekly where they talk about CRIU (Checkpoint & Restore In Userspace) which is closely related to OpenVZ and will be used in the EL7-based OpenVZ kernel branch. Enjoy!



Must get moose and squirrel!

Tags:

Kir's presentation from LFNW 2015

OpenVZ Project Leader Kir Kolyshkin gave a presentation on Saturday, April 25th, 2015 at LinuxFest Northwest entitled, "OpenVZ, Virtuozzo, and Docker". I recorded it but I think my sdcard was having issues because there are a few bad spots in the recording... but it is totally watchable. Enjoy!

OpenVZ past and future

Looking forward to 2015, we have very exciting news to share on the future on OpenVZ. But first, let's take a quick look into OpenVZ history.

Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).

Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.

It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).

Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.

Better late than never; we are going to fix it now! We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base. The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.

As a first step, we will open the git repository of RHEL7-based Virtuozzo kernel early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.

Our kernel development mailing list will also be made public. The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list. This should allow the community to become full participants in development rather than mere bystanders as they were previously.

Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. For the new unified product, we are going to open up JIRA which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.

Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:

Virtuozzo Core


Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.

Merry Christmas and a Happy New Year!

On kernel branching

This is a topic I always wanted to write about but was afraid my explanation would end up very cumbersome. This is no longer the case as we now have a picture that worth a thousand words!

The picture describes how we develop kernel releases. It's bit more complicated than the linearity of version 1 -> version 2 -> version 3. The reason behind it is we are balancing between adding new features, fixing bugs, and rebasing to newer kernels, while trying to maintain stability for our users. This is our convoluted way of achieving all this:

kernel_tree-2.6.32-x

As you can see, we create a new branch when rebasing to a newer upstream (i.e. RHEL6) kernel, as regressions are quite common during a rebase. At the same time, we keep maintaining the older branch in which we add stability and security fixes. Sometimes we create a new branch to add some bold feature that takes a longer time to stabilize. Stability patches are then forward-ported to the new branch, which is either eventually becoming stable or obsoleted by yet another new one.

Of course there is a lot of work behind these curtains, including rigorous internal testing of new releases. In addition to that, we usually provide those kernels to our users (in rhel6-testing repo) so they could test new stuff before it hits production servers, and we can fix more bugs earlier (more on that here). If you are not taking part in this testing, well, it's never late to start!

Donation: a way to help or just say thanks

For many years, when people asked us how can they help the project, our typical answer was something like "just use it, file bugs, spread the word". Some people were asking specifically about how to donate money, and we had to say "currently we don't have a way to accept", so it was basically "no, we don't need your money". It was not a good answer. Even if our big sponsor is generously helping us with everything we need, that doesn't mean your money would be useless.

Today we have opened a PayPal account to accept donations. Here:

How are we going to spend your money? In general:

  • Hardware for development and testing
  • Travel budget for conferences, events etc.
  • Accolades for active contributors

In particular, right now we need:

  • About $200 to cover shipping expenses for donated hardware
  • About $300 for network equipment
  • About $2000 for hard drives

Donations page is created on our wiki to track donations and spending. We hope that it will see some good progress in the coming days, with a little help from you!

NOTE that if you feel like spending $500 or more, there is yet another way to spend it -- a support contract from Parallels, with access to their excellent support team and 10 free support tickets.

Latest Month

July 2015
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow