PVM: Pouyesh Dadeh Novin Virtual Machine Management System
What is PVM?
PVM (PDNSoft Co. Virtual Machine Management System) is a hypersior based on KVM (Kernel Virtual Machine).
PVM provides new application stack to manage KVM virtual machines instead of using Libvirt with it's own considerations.
Cluster and user awareness is specific features in PVM design, so managing of HA and other features is done by PVM application stack that is placed directly on KVM.
Some special features of PVM are:
- No need to manage the node, and also cluster is self management
- No need to lock mechanism for any cluster
- Online Mirror
- HA without shared storage
- Offline backup without any need to third party softwares.
- Remote site to manage two sites as replication.
PVM is lightweight code that just manages KVM machines.
Design of PVM has been done by prospective about cloud computing needs and developed new perspective in this area that is based on Objects instead of Vms.
Fig.1 : PVM Structure
In Fig 2., you could see PVM Architecture:
Fig. 2: PVM Architecture
What is SballTalk?
SballTalk is a Distributed (X)Object Repository based on corosync. It is one part of PVM Hypervisor (PDNSoft Co. Virtual Machines Management System) based on KVM.
It is written in C++ using object-oriented design which made it modularized.
On each node, SballTalk has an XObject Repository which is a collection of XObjects. The XObject can be anything such as nodes, users, tasks, services, resources and so on.
Additionally, SballTalk has modules that can be added to it dynamically. Each module performs special task such as monitoring, virtual machines management, virtual switches management and so on.
Lightweight core of SballTalk is a cluster aware which manages objects and
responsible for synchronizing XObject Repositories. All data relating to each object is saved locally on each node of the cluster so there is no need to use a shared storage space.
The Key features of SballTalk:
All data relating to each object is saved locally on each node of the cluster so there is no need to use a shared storage space.
Because of designed and implemented algorithms in SballTalk, there is no need to use DLM (Distributed Lock Manager) unlike RGManager.
Fully modularized and flexible SballTalk design, lets developers to easily customize SballTalk for any desired purposes.
By developing and completing this product, so that it could be a good replacement for RGManager and Pacemaker because whatever these projects provide for users, will be provided by only one or more modules of SballTalk.
SballTalk forms a new development framework for cluster application developers.
PVM Technical innovations:
Nowadays, most applications retrieve, save, send and recieve their data in XML format. Therefore, Our developers started to write [ XParam] to provide a library that eases manipulating XMLs in C++ programming language.
By XParam, developers can define a class and then print out the class in XML format or save it into a file or load an XML from string or file to that class.
In addition, XParam introduces a novel method for designing object-oriented
programs that is called [ XObject].
XObject defines a real world as a set of objects and their connections. This method reduces design complexity and increases flexibility and stability of a system.
Xobject forms base of SballObject, that is base of any object in Sball framework (i.e. PVM).
It is an special linked list, after delete of a list element, it would remain in memory as long as there was some activities on that.
At deletion process any new list traverse could not see deleted element but any activities on that element could traverse list back or forward.
Activities on list elements simulate by iterator
Element would be deleted from memory when there was not any activity on.
It is possible to have multiple read (traverse) and only one write (add/delete) concurrently. This list could be imagined like RCU lists in kernel.
Xframework is a framework to design and develop modular programs. Code name of this project is putil.
The thinking behind of this framework is to implement flexible and efficient environment for developers of modular programs to expand their modules quickly and independently.
Fig. 3: PVM XFramework
Action repository is warehouse of modules actions that would be used as ABIs of each module. User sends it's commands to fireloop as action in XML format and receives response in XML format.
Each module could register his actions in Action Repository at load time.
The simplest way to implement PVM on one server. User could use offline backup to hold backups from vm images.
Fig. 4: PVM One
PVM MR (Mirror)
In this version, PVM should be installed on two servers as virtualization platform, one of this servers would be active and other passive.
All virtual machines would be run on active server, while passive server keeps online back of virtual machine data, imagine as mirror of active server.
So when active server corrupted as a result of hardware failure, virtual machines could be run on mirror without any data lost.
Fig. 5: PVM MR
PVM TNC (PVM Tow Nodes Cluster)
It's like of PVM MR, the difference is two servers are active. So processing load could be divided on two servers.
In this version PVM has HA (High Availability). PVM provides HA in this version without shared storage. So when each of the servers failed, virtual machines would restarted on other server.
Fig. 6: PVM TNC
PVM FC (PVM Full Cluster)
This version of PVM uses shared storage like of SAN. Data of virtual machines located on shared storage and servers used as processing pool.
Servers are cluster, so when each of them failed, virtual machines would restarted on other servers.
Fig. 7: PVM FC