Placement Profile – Best Fit Cluster using Tags

CloudFORMS has workflows for many different tasks including approval, quotas and placement to name just a few. This blog entry is going to add to the placement category of workflows. A previous post of mine showed how you could place new workloads NOT_NEAR “Workload Placement by Type (Not Near That)”¬†other workloads which I still think is really cool. This placement workflow is quite simple, it matches template tags against cluster tags. Example;

Continue reading “Placement Profile – Best Fit Cluster using Tags”

Workload Placement by Type (Not Near That)

Use Case – I want that when I provision a virtual machine I can specify certain workload types that I wish to avoid being placed with.

Example 1 – I will be requesting a virtual machine that will be very intensive on CPU or Disk I/O, therefore I want to ensure that I do not place it with any Database Servers, as I may impact their operation or they could equally stave me of resources. But I don’t know where the Database servers are located nor do I care, also real time the database servers are DRS managed therefore they may not be where they were first provisioned!

Continue reading “Workload Placement by Type (Not Near That)”

Clone from Template (RHEV)

Enable CloudFORMS to clone a template, and retaining the disk layout. So CloudFORMS currently deploys new virtual machines in RHEV either by PXE or ISO. It does this by cloning a BLANK template and attaching new disks, where a PXE or ISO process will install an operating system. Those from the VMware world and those in Windows land will want to deploy directly from a template a clone, without having to install an operating system, because the template already has it installed in its disk. Reasonable request…. this is how…

Continue reading “Clone from Template (RHEV)”

Cobbler Provisioning via CloudFORMS 2.0

Hooking Cobbler and CloudFORMS 2.0 together is actually quite simple. Lets first understand the use case.

We want to deploy virtual machines using PXE boot from Cobbler.

Cobbler stores each vm’s boot information as a “System Record”, there is a nice API that you can launch that will create these system records, you just need to pass the right parameters. The data required to drive Cobbler to create a system record are;

Continue reading “Cobbler Provisioning via CloudFORMS 2.0”

  • Page 2 of 2
  • <
  • 1
  • 2