WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

VMware Labs releases Proactive DRS Fling from last years Fling Contest

08.27.2013 by William Lam // 1 Comment

Last year, the VMware Labs team ran an Open Innovation contest where users could submit ideas for Flings that they would like to see get built. In addition to that, one lucky winner will be selected and their idea will actually be sponsored internally within VMware R&D and VMware Engineers would then implement that idea. The winner of that contest was Mike Preston on an idea called Proactive DRS:

“What I would like to see is some sort of appliance/script that can hook into both the vCenter Operations API’s as well as the vSphere APIs and merge these two technologies together. By interpreting vCenter Operations predictions for what is going to happen within your environment and then leveraging vMotion/DRS/DPM to prepare for this before it happens we could be left with a more proactive approach. (I.E. Historically VM1 will utilize 100% CPU at 4am in the morning, let’s be sure these resources are available on the host at 3:45 by migrating other VMs off, rather than waiting for DRS to kick in at 4:05 – At 6am everyday my workload normally increases to the point where DPM kicks in and turns on some hosts, let’s turn these on at based on the vCenter Operations stats rather than having to manually configure a setting to do so).”

Today at the VMware R&D Innovation booth at VMworld, the VMware Labs team has just announced that they will be releasing the Proactive DRS Fling (download coming very soon!). I think this is pretty awesome, I mean how cool is that, an idea that you came up with was implemented by a group of VMware Engineers? Congrats on the awesome idea Mike!

Here is a bit more details on how Proactive DRS works:  

It is a way for DRS to react to changes in the virtual cluster, and to act on predicted changes in resource demands before hosts become stressed. For example, if you have a VM that historically uses 100% CPU at 8am every morning, ProactiveDRS  makes  sure that the CPU resources will be available for that VM before 8am. These actions ensure that your cluster runs smoother and reduces the amount of reactive VM rebalances that occur.

Features

  • Given an advance forecast/prediction of each VM’s resource demands, e.g., CPU and Memory, ProactiveDRS seeks to reorganize the placement of VMs to best balance the current resource demands while taking early actions to accommodate the future/predicted resource demands.
  • Sample actions include, but are not limited to, proactive vMotions (migrations) and proactively powering on a new physical host to accept VMs whose resource demands are expected to spike beyond the available resources of their current physical host.

The VMware Labs folks did not stop there, they are also running a new 2013 Fling Contest and if you are at VMworld, you can drop by the VMware R&D Innovation booth which is behind the main VMware booth to submit your ideas. Another lucky winner will be selected and their idea will also be built by VMware Engineers which includes a free ticket to VMworld 2014. I recommend you either drop by the booth if you are at VMworld or go online to submit an idea and you could be the next person with their very own Fling!

Categories // Uncategorized Tags // drs, fling, innovation, vcops, vmware

Quick Tip - Minimum amount of memory to run the vCenter Server Appliance

08.19.2013 by William Lam // 18 Comments

I thought this might have been common knowledge, but after chatting with a VMware colleague who recently rebuilt his home lab, I realized it may not be the case. The vCenter Server Appliance (VCSA) is distributed as a virtual appliance and by default it is configured for 8GB of memory. However, this is definitely NOT the "minimum" amount of memory required to have a fully functional vCenter Server.

It looks like some people are just downloading the vCenter Server appliance and just sticking with the defaults of 8GB of memory which for a home lab is quite a large footprint, especially given you will probably want to install other virtual machines. The actual minimum for vCenter Server (Windows or Linux) is just 4GB and technically speaking, you can even get away with just 3GB for the vCenter Server Appliance (anything less, the system is extremely slow and unusable).

Here is a quick screenshot showing vCenter Server Appliance running with only 3GB of memory:

VMware also has a KB article detailing the minimum requirements for the vCenter Server Appliance based on the number of virtual machines and hosts you plan on running. For my home lab, I normally stick with the 4GB of memory and I have not had any issues. Hopefully this tip will help you save some memory for either your lab or even production environment for other workloads.

Categories // Home Lab, VCSA, vSphere Tags // memory, vcenter server appliance, VCSA, vcva

Flexible OVF deployments using Deployment Options (e.g. small, medium, large)

08.19.2013 by William Lam // 28 Comments

It is pretty common these days to see a vendor distribute their applications as a virtual appliance which pre-bundles both an operating system and their application instead of a stand alone installer and provides that as an OVF/OVA download. This makes it extremely easy for customers to deploy a vendors application with very minimal effort.

One potential challenge with providing a virtual appliance is that the virtual hardware configuration such as CPU and Memory is pre-configured during deployment and usually optimized for the lowest common denominator such as a small environment or even home lab for that matter. Of course, it is trivial to increase these resources after deployment but would it not be nice if the vendor could provide a "sizing recommendation" option during the deployment of their virtual appliance?

It turns out the OVF format actually supports such a functionality called Deployment Options and this is probably something that is not very well known. I personally have only seen this feature get used in one of VMware's virtual appliances which is vCenter Operations. When going through the deployment wizard of vCenter Operations appliance, you will notice one of the steps is to select your deployment configuration which in this case is based on the number of virtual machines you have in your vCenter Server environment.

The deployment option in this example translates to the number of vCPU and vMemory that the virtual appliances will be deployed with. Of course this information can also be used within the guestOS as part of the initial boot to configure the application based on the resources allocated to the virtual appliance. If you are interested in learning more about Deployment Options and its capabilities, you can find more details on the DMFT website for the OVF standards document starting on page 35.

I recently became interested in this as there was an internal thread asking how to leverage this feature and I initially thought this would be a capability provided by VMware Studio which is a product that helps you build virtual appliances. After deploying VMware Studio, I was unable to find a way to enable this feature as part of the build. Currently it looks like you would need to manually edit the OVF file which is XML based (not ideal) to add in this extra capability. You can also take an existing virtual machine and export using the vSphere Web/C# Client to an OVF/OVA and then add in the Deployment Option as a quick and dirty way of leveraging this feature within your organization.

I took a look at vCenter Operations OVA file to see how Deployment Options work and it actually looks pretty straight forward and requires the following three sections:

  1. Deployment Option Definitions
  2. Virtual Hardware Configurations
  3. Deployment Option Text

I have also provided a sample OVF called MyApp.ovf that you can download to see how these options work.

Deployment Option Definitions

The first section describes your Deployment Options, in the example below we use the words small, medium and large. You can change this text to be anything such as bronze, silver and gold. The only thing to note is the id and msgid which will need to be maped to section #2 and #3

<DeploymentOptionSection>   
 <Info>The list of deployment options</Info>   
  <Configuration ovf:id="small">     
      <Label ovf:msgid="config.small.label"/>     
      <Description ovf:msgid="config.small.description"/>   
  </Configuration>   
  <Configuration ovf:id="medium">     
      <Label ovf:msgid="config.medium.label"/>     
      <Description ovf:msgid="config.medium.description"/>   
  </Configuration>   
  <Configuration ovf:id="large">     
      <Label ovf:msgid="config.large.label"/>     
      <Description ovf:msgid="config.large.description"/>   
  </Configuration>  
</DeploymentOptionSection>

Virtual Hardware Configurations

The second section describes the virtual hardware configuration and uses a configuration parameter id that maps back to the original definition. In the example here, we are looking at the number of vCPU's the virtual appliance can be assigned with. For the initial default, you do not need to specify an entry, but for the others you will need to. Here I have a definition for medium and large and their respective vCPU configuration.

<Item>
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>1 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>1</rasd:VirtualQuantity>
</Item>
<Item ovf:configuration="medium">
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>2 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>2</rasd:VirtualQuantity>
</Item>
<Item ovf:configuration="large">
  <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits>
  <rasd:Description>Number of Virtual CPUs</rasd:Description>
  <rasd:ElementName>4 virtual CPU(s)</rasd:ElementName>
  <rasd:InstanceID>1</rasd:InstanceID>
  <rasd:ResourceType>3</rasd:ResourceType>
  <rasd:VirtualQuantity>4</rasd:VirtualQuantity>
</Item>

Deployment Option Text

The final section contains the actual text you wish to display for each of your Deployment Configurations. You will see the msgid maps back to your definitions, so if you choose to change the wording, make sure these match up.

<Strings>
 <Msg ovf:msgid="config.small.label">Small</Msg>  
 <Msg ovf:msgid="config.small.description">Use this configuration for small deployments. This deployment will need 1 vCPUs and 1024 Memory for the vApp.</Msg>  
 <Msg ovf:msgid="config.medium.label">Medium</Msg>  
 <Msg ovf:msgid="config.medium.description">Use this configuration for small deployments. This deployment will need 2 vCPUs and 2048 Memory for the vApp.</Msg>  
 <Msg ovf:msgid="config.large.label">Large</Msg>
 <Msg ovf:msgid="config.large.description">Use this configuration for small deployments. This deployment will need 4 vCPUs and 4096 Memory for the vApp.</Msg>
</Strings>

Though I have experienced Deployment Options while deploying vCenter Operations in the past, thinking about it more now, it is definitely something that can be useful for folks building virtual appliances. The really nice thing about this feature is it works when deploying to both a vCenter Server as well as a standalone ESXi host.  Hopefully we will see more virtual appliances leveraging this neat feature of the OVF standard.

Categories // Uncategorized Tags // deployment options, DeploymentOptionSection, ESXi, ovf, vSphere

  • « Previous Page
  • 1
  • …
  • 441
  • 442
  • 443
  • 444
  • 445
  • …
  • 560
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025