Hi All,

Instead of a 'slot', can there be a notion of available resource for a
computer (where computer in this case is a hypervisor)? This will allow vcl
to 'pack' vm's onto a hypervisor based on the worst case resource parameters
for a vm image.

This also leads to the notion of a placement module outside the front end
web stuff to make the decision making algorithm for placement of vm's (or
bare-metal images) more extensible/configurable.

Any thoughts?

John Bass
(919) 515-0154

On Mon, Mar 30, 2009 at 7:50 AM, Brian Bouterse <bmbou...@ncsu.edu> wrote:

> I wanted to let folks know the ESX provisioning module should be finished,
> or at least in a beta form.  I have closed the JIRA ticket (VCL-29)
> corresponding to the creation of this module.  Here is a review of the new
> functionality:
> Manage multiple ESX or ESX 3i hypervisors
> Deploys virtual machines onto these hypervisors
> Supports virtual machine capture routing to allow for updating a VM image,
> and the creation of "new" derivative images
> One last improvement will include refactoring the way our module gathers
> the private IP address of the VM that is being provisioned.  The change
> include deprecating the "watching of the arp table" in favor of monitoring
> the dhcpd.leases file.
> While VCL now supports ESX/ESX 3i netboot based virtual machines, the VCL
> architecture presents a lot of real challenges for making this a scalable
> solution, and I'd like to identify and discuss a few points/concerns here.
> VCL requires an entry in the computers table for each VM, and this entry
> needs to be tied to a vmhost.  By hard selecting the virtual machine entries
> in the computer table (a VM "slot") up front, the decision about where to
> place the next virtual machine isn't handled effectively.  Each VM "slot"
> gets statically assigned physical characteristics at creation time.  This
> very quickly creates a situation where there is space in the datacenter for
> a particular VM on one hypervisor or another, but VCL can't figure it out
> because the large RAM slots got used first for other images, and now the
> image in question can't find a slot to meet it's meta-data requirements.
>  VCL will incorrectly report that there is not space in the infrastructure,
> when there really is.  This is bad.
> Also, it makes the setup much more difficult since an average, modern blade
> can run 20 - 30 VMs, and if you manage an entire blade center you're
> manually creating 350 computer table entries.  Each entry requires multiple,
> manual updates to the database.  This is not a tractable solution, and needs
> to be addressed.
> As a possible solution (or part of one), one major moving part is the
> placement decision for a particular reservation (tantamount to which
> hypervisor this VM will be reserved on).  Placement today in VCL is decided
> in the front-end without asking the hypervisors what their capabilities are
> of accepting the next VM (or cluster of VMs) in question.  One possible way
> around this is to create a ESX placement controller module which determines
> where to place things.  This module would be part of the VCL backend
> (although it could be called from the frontend).  The ESX provisioning
> module authors each VMX file on the fly based on meta-data from the
> database, so it is already dynamic enough.
> Best,
> Brian
> Brian Bouterse
> Secure Open Systems Initiative
> 919.698.8796

Reply via email to