A lot of the panels out there advertise support for a specific platform for example OpenVZ or Xen. We’re taking a different approach where in theory our system could handle any platform assuming there is a driver built for it on our system and all the relevant data in the database. This would mean the variables available to that platform are within the database and an actual entry for that platform exists so a machine can be set to that platform. So here’s how it all breaks down:
- You have your virtualization platform itself for example OpenVZ, Xen ect.
- You have fields that are available to that platform so kmemsize or whatever. Each field is dynamically generated from the database and has the capability to do validation, filtering and obviously provide a pretty name and description
- For the communication to the platform you have your driver which will handle all the communication to the machine and it’ll also extend the main platform which will handle all database backend
Here’s a bit of a more detailed explanation of the platform system:
Every single platform will use this as it’s base to develop further. It’ll handle all database portions and communications back to the panel. You can in theory build any platform you want as long as it has the basics. So the basics would be the facility to start, stop, reboot ect. So with this you could develop something like say Vezoz_Vm_Platform_Openvz or Vezoz_Vm_Platform_Xen. You could also take another approach and rather than using the platform itself you could do Vezoz_Vm_Platform_Hypervm if you wanted to use the HyperVM API and it provided everything necessary to you. With a bit of work I’m sure you could also be crazy and do something like say Vezoz_Vm_Platform_Softlayer. Softlayer has an API so you could potentially fool the system into thinking it’s dealing with a virtual machine when maybe it’s dealing with physical machines via the softlayer API.
The plan to start anyways is to just have an OpenVZ version available but we will expand it out for various platforms or even various ways to communicate (maybe two versions of OpenVZ communication).
Right now we have started working on handling of actual virtual machines as we have every thing now in place for creation of them in the database end. Hopefully before the end of the week we have a working system that will have all the necessary features for a first release. Then the week after the plan will be to clean it up and have the Hawk Host user base using the first release. Once that happens we’ll work on refining and adding features along with licensing capability for a release in the very near future.