Yellow Bricks

by Duncan Epping

tips

Converting Open Virtualization Format (OVF) -Virtual Machines to VMware Fusion

· ·

I needed to run an appliance inside VMware Fusion on my Mac, the appliance was in OVF format. VMware Fusion currently does not support this format and requires you to convert the image with a tool called ovftool which can be downloaded at the following location: http://communities.vmware.com/community/vmtn/vsphere/automationtools/ovf

Conversion is as simple as:

./ovftool "source.ovf" "target"

Optionally you could use parameters that are described in full detail when running ovftool –help. What remains is importing the created .vmx into Fusion, that’s it.

-ray

5 Tips for preparing your VCDX Defense

· ·

After the VCDX defenses Boston I had a chat with Craig Risinger, also known as 006 ;-). We discussed some of the things we’d seen on the panels and came to the conclusion that it wouldn’t hurt to reiterate some of the tips we’ve given in the past.

  1. It’s OK to change your actual project documents. See the following points for examples. This isn’t really about what you actually happened to do on a particular project with its own unique set of circumstances. It’s about showing what you can do.This is your portfolio to convince potential customers you can do their design, whatever they might need. It’s about proving you could work with a customer to establish requirements and design an architecture that meets them.
  2. Include everything the Application says is mandatory. Don’t be surprised if you have to write some new documents or sections. For example, maybe a Disaster Recovery plan wasn’t important in your project, but it will be to another customer or in another project, so you should show you know how to create one.
  3. Explain any bad or debatable decisions. Did your customer insist on doing something that’s against best practices? Did you explain what was wrong with it? Say how you would have preferred to do things and why. Even if you just made a mistake back then, that’s OK if you can show that you’ve learned and understand the error you made. If you are using VMware’s best practices make sure you know why it is a best practice and why it met your customer’s requirements.
  4. Show you can design for large scale. It’s OK if your actual project was for a small environment, but show that you can think big too. What would you have done for a bigger customer, or for a customer who wanted to start small but be able to scale up easily? What would you need to do to add more VMs, more hosts, more storage, more networking, more vCenter servers, more roles and division of duties, a stronger BC/DR plan in the future? How would that change your design, if at all?
  5. Architect = Knowledge + Reasoning. The VCDX certification isn’t just about knowing technical facts; it’s about being able to apply that knowledge to meet goals. In the defense session itself, be prepared to discuss hypothetical scenarios and alternative approaches, to decide on a design, and to explain the reasons for your choices. Show you know how to consider the pros and cons of different approaches.

There are also many other useful collections of advice for pursuing a VCDX certification, we highly recommend reading them as they will give you an idea of the process. Here’s just a sample:

Craig Risinger (VCDX006) & Duncan Epping (VCDX007)

Network loss after HA initiated failover

· ·

I had a discussion with one of my readers last week and just read this post on the VMTN community which triggered this article.

When you create a highly available environment take into account that you will need to have enough vSwitch ports available when a failover needs to occur. By default a vSwitch will be created with 56 ports and in general this is sufficient for most environments. However when two of your hosts fail in a 10 host cluster you might end up with 60 or more VMs running on a single host. If this would happen several VMs would not have a vSwitch port assigned.

The most commonly used command when creating an automated build procedure probably is:

esxcfg-vswitch -a vSwitch1

This would result in a vSwitch named “vSwitch1” with the default amount of 56 ports. Now it is just as easy to set it up with 128 ports for instance:

esxcfg-vswitch -a vSwitch1:128

Always design for a worst case scenario. Also be aware of the overhead, some ports are reserved for internal usage. You might want to factor in some additional ports for this reason as for instance in the example above you will have 120 ports available for your VMs and not the 128 you specified.

Changing the directory of your vSphere vCenter log files

· ·

Something that a lot of people haven’t looked in to or just don’t think about is relocating the log files of vCenter, I wrote a short article 2 years ago and thought it was time to reiterate it. By default (Windows 2003) log files are stored in “C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs”, and for Windows 2008 log files are stored in “C:\ProgramData\VMware\VMware VirtualCenter\Logs”.

As you can imagine the C:\ partition is not the ideal place for storing log files. I would personally recommend to use a separate drive for logfiles so avoid it from flooding any OS or Program related drives. You could pick a small size based on the expected log size and if needed increase the amount of logs that are stored and the size of the log file.

Changing this is pretty simple. Open “vpxd.cfg” and add the following line in between <log> and </log>

<directory>D:\VMware\Logs</directory>

Changing the amount of log files stored and the size is also pretty basic, in this example vCenter will store 10 logfiles which are max 10MB each:

<maxFileSize>10485760</maxFileSize>
<maxFileNum>10</maxFileNum>

Keep in mind that you will need to restart the vCenter Service after these changes before they take effect!

Best Practices: running vCenter virtual (vSphere)

· ·

Yesterday we had a discussion on running vCenter virtual on one of the internal mailinglists. One of the gaps identified was the lack of a best practices document. Although there are multiple for VI3 and there are some KB articles these do need seem to be easy to find or complete. This is one of the reasons I wrote this article. Keep in mind that these are my recommendations and they do not necessarily align with VMware’s recommendations or requirements.

Sizing

Sizing is one of the most difficult parts in my opinion. As of vSphere the minimum requirements of vCenter have changed but it goes against my personal opinion on this subject. My recommendation would be to always start with 1 vCPU for environments with less than 10 hosts for instance. Here’s my suggestion:

  • < 10 ESX Hosts
    • 1 x vCPU
    • 3GB of memory
    • Windows 64Bit OS(preferred) or Windows 32Bit OS
  • > 10 ESX Hosts but < 50 ESX Hosts
    • 2 x vCPU
    • 4GB of memory
    • Windows 64Bit OS(preferred) or Windows 32Bit OS
  • > 50 ESX hosts but < 200 ESX Hosts
    • 4 x vCPU
    • 4GB of memory
    • Windows 64Bit OS(preferred) or Windows 32Bit OS
  • > 200 ESX Hosts
    • 4 x vCPU
    • 8GB of memory
    • Windows 64Bit OS(requirement)

My recommendation differ from VMware’s recommendation. The reason for this is that in small environments(<10 Hosts) there’s usually more flexibility for increasing resources in terms of scheduling down time. Although 2 vCPUs are a requirement I’ve seen multiple installations where a single vCPU was more than sufficient. Another argument for starting with a single vCPU would be “Practice What You Preach”. (How many times have you convinced an application owner to downscale after a P2V?!) I do however personally prefer to always use a 64Bit OS to enable upgrades to configs with more than 4GB of memory when needed.

vCenter Server in a HA/DRS Cluster

  1. Disable DRS(Change Automation Level!) for your vCenter Server and make sure to document where the vCenter Server is located (My suggestion would be the first ESX host on the cluster).
  2. Make sure HA is enabled for your vCenter Server, and set the startup priority to high. (Default is medium for every VM.)
  3. Make sure the vCenter Server VM gets enough resources by setting the shares for both Memory and CPU to “high”.
  4. Make sure other services and servers on which vCenter depends are also starting automatically, with a high priority and in the correct order like:
    1. Active Directory.
    2. DNS.
    3. SQL.
  5. Write a procedure to boot the vCenter / AD / DNS / SQL manually in case of a complete power outage occurs.

Most of these recommendations are pretty obvious but you would be surprised how many environments I’ve seen where for instance MS SQL had a medium startup priority and vCenter a high priority. Or where after a complete power outage no one knows how to boot the vCenter Server. Documenting standard procedures is key here; especially know that with vSphere vCenter is more important than ever before.

Source:
http://kb.vmware.com/kb/1009080
http://kb.vmware.com/kb/1009039
ESX and vCenter Server Installation Guide
Upgrade Guide