1. Please slow down a bit. Produce a quality bug-free product and not try to rush out new versions, features and functionality until they are ready. Stop with the experimental features and only put them in the finished product unless they are ready and you are going to fully support them. I know it’s almost impossible to produce 100% bug-free code, especially as your product code grows larger and larger in size, but please catch the major ones that can cause outages for your customers. If you can’t slow down, at least hire more QA personnel and do more public Betas so your customers can help you with this. You can’t afford another mishap like Microsoft is currently experiencing with their Zune music players.
2. On the release of VI4 (or vSphere as you now call it): This should be an exciting upgrade and further distance you from your competitors, but please don’t release it before it’s fully done, polished and tested. I can wait an extra month or two if necessary.
3. Please, no more product name changes. Enough is enough with the name changes! You’re just confusing your customers and complicating things. Instead, get your marketing department to do more to attract new customers, keep your current ones and fight all the HyperV vs. ESX misinformation that Microsoft releases. Also please leave ESX named ESX, I know your marketing department is probably itching to change it so something like vHypervisor but resist and leave it as ESX. (For those who don’t know ESX stands for Elastic Sky X which was the name used in the development of the original version.)
4. More competitive pricing. You have lots of competition now and the hypervisor is becoming commoditized. Giving away ESXi for free was a good start. Why not give ESX away for free also and sell all the advanced features as add-ons? You also have plenty of automation and management products that you can sell to complement it. Also, please reduce the price of Workstation. It’s too expensive for many. You’d probably sell a lot more if you reduced the price so it was close to the price of Fusion.
5. On VMworld presentations: Please go back to releasing these to non-attendees after the show ends as you did in previous years. Not everyone can afford to go to it and the information in the sessions would be valuable to both your current and potential customers. It’s to your benefit to educate your customers and provide as much information to them as possible. At the very least, allow people to purchase a subscription to the sessions so they can access them right away after the show ends.
6. Relax the VMware Certified Professional (VCP) certification requirements. I shouldn’t have to take a class to become a VCP, if I have the knowledge and experience to pass the VCP exam that should be enough. Many qualified people can’t afford to take a class just so they can take the test.
Well VMware, I hope 2009 is a very good year for you, I look forward to the release of vSphere and any other great things that you will deliver to us in the upcoming year.
A VMware aficionado
A common question that arises on the VMware Communities Forum is how to backup VMware ESX so that you can restore the backup if there is a problem, the theory being that this would be faster than reinstalling the server.
As stated within the VMware KB article 1000761 it is possible to restore ESX to identical hardware; however, you need to reinstall ESX first and restore the data you backed up while making changes to how the system boots, else the Universally Unique Identifier (UUID) written by the installation will not work anymore as you have overwritten the data from your backup.
This method will restore everything effectively to identical hardware, however if you want to use new hardware, perhaps with different PCI devices, then the restoration would fail to properly configure the new devices. It may even fail to properly configure NICs if there are any IRQ differences between the supposed identical hardware.
So in these cases you would have to at least verify the configuration and fix anything that was broken. This could lead to a set of unknowns from a security perspective. You are after all trusting the backup was restored properly and if it was not, then you could end up with security issues. So the verification step would have to be extremely well documented.
It is far easier to reinstall VMware ESX to the hardware and to use a either a installation document, kickstart, or other type of script to configure all the devices for you using either the Remote CLI or the VMware ESX CLI.
When restoring VMware ESX or VMware ESXi the best tool to have will be very good installation documentation that is easy to follow and has graphics and text for every step of the configuration. These documents could be reviewed for security concerns, and used to derive the scripts that could do the work for you.
In October of this year, I mentioned in a prior blog post that VMware updated their storage and compatibility guides to reflect a split of sorts between ESX 3.0.x and ESX 3.5 and ESXi. This is now available as a searchable by product name or hardware vendor for multiple solutions and provides a central resource for all supported configurations. This tool allows for the following search categories:
Systems - What products are supported for installations for ESX and ESXi platforms
Storage and SAN – Allows searches for partners and their products for ESX and ESXi-based storage devices.
I/O devices – Has brand information for supported HBAs, RAID controllers, and SCSI adapters.
VMware View – Lists supported connecting devices to the new virtual desktop product.
This new hardware compatibility guide search website also has direct links to all of the relevant other configuration information. This includes resources on CPU configuration for VMotion, supported guest operating systems, as well as my trusty PDF documents that are available as a traditional download.
More information on the new tool can be found in the online help section of the hardware compatibility guide website.
‘Tis the season for giving. I recently received an email from Veeam saying that got me a X-mas gift. Aww, Veeam, you shouldn’t have. Unfortunately I didn’t get you anything! So what do you get that VMware admin in your life for the holidays? Here are some stocking stuffer ideas that are sure to make any VMware admin happy.
Check out some of the great add-on products that were finalists and runner-ups at the Best of VMworld awards. These products are a great complement to any VMware environment and every VMware admin would be very appreciative to get some of them to help make their administration job easier.
What VMware admin wouldn’t like to have a few extra ESX or vCenter licenses laying around? Maybe get them a few so they have some extra hosts that they can play around with. Or consider upgrading those Starter or Standard license to Enterprise ones so they have some cool new features that they can use like VMotion and DRS.
Don’t have a lot of money to spend? Check out some of these free add-on products that are available for VMware environments. Download a free copy of ESXi and burn it to a CD, wrap it and present it to your VMware admin, he’ll know you didn’t buy it, but hey, it’s the thought that counts.
VMware admins love to show off their love for VMware, try going to the VMware store and get them a spiffy shirt or hat or maybe some golf balls or a cooler chair.
All administrators are some part geek, so if you don’t want to get strictly VMware-oriented presents, why not get them some items that will please their inner geek? Here are some great geeky items that they might appreciate:
o USB Rocket Launcher – a great way to keep away those pesky people that keep coming up to your desk wanting you to do something. Ring your desk with a few of these and they might think twice before bugging you. Want to head them off at the pass? Try the wireless version instead.
o Finger drums – what better way to pass the time waiting for a host to reboot or a snapshot to commit then banging on some drums.
o Stealth R/C Helicopter – have some fun flying a little helicopter around your data center between the server racks.
o Mana energy potion – have a long sleepless night ahead of you upgrading your hosts to the latest version, or consolidating some systems? Try one of these to help you stay awake and get the job done.
Well that’s just a few suggestions for some great gifts for your VMware admins. If nothing else you might consider expressing your appreciation for their hard work and dedication which is something administrators often do not hear enough.
Happy holidays too all!
Everyone has a holiday wish list. Some include the latest toys, gadgets, games, and other useful devices. But what do you get the virtualization administrator for the holidays? This rare individual has a need for gifts as well! Here are some useful suggestions:
- Any book or reference from the Virtualization bookshelf
- A subscription to any number of magazines or ezines references on the Virtualization bookshelf
- VMware Workstation or Fusion licenses (if they do not already have one) for virtualizing at home
- VMware merchandise (gift cards, apparel , golf balls, mugs, mouse pads, etc) from The VMware Store
For those who want to purchase hardware for their virtualization administrator:
- Any system on the VMware ESX Systems HCL
- Memory upgrades for servers, workstation, or laptop
- Fully loaded HP 8730w laptop (Great for running ESX within VMware Workstation)
- LiveScribe Smartpen — never miss a note/conversation again
- The iPhone, for oh-so-many reasons
Enjoy the holidays and I hope this helps you shop for your virtualization administrator!
Recently, myself and other bloggers as well as the editorial staff at TechTarget were invited to a briefing on Hyper-V. Microsoft is, on all fronts, trying to get Hyper-V and the Microsoft System Center technologies into the hands of administrators, and to some extent it is working.
During this briefing there was some discussion about the memory overcommit technology of VMware’s ESX, not available in Hyper-V. This feature pretty much answers my question on where I put my virtualization environment. Microsoft said IT managers and administrators won’t make their platform decisions based on one specific technology feature such as memory overcommit. I could not make sense of that answer, so I chewed on it a little and came up with this.
Managers and administrators do make their platform decisions on factors like the consolidation ratio, which is the number of guest virtual machines that are running on one physical host. In the case of VMware versus Hyper-V, there is no question which is going to perform better in achieving a higher density of guests per host. This ratio is made almost entirely possible by the memory overcommit technology that ESX has. To that end, how important is a consolidation ratio? Granted there are many factors that go into the workload and various planning tools that can be used to map out the virtual landscape, but for me, I can’t think of a more important measurable in architecting a virtual environment.
In the course of performing many physical-to-virtual (P2V) conversions, I still come across situations where a small configuration can make or break the task. Recently, I performed a P2V conversion of a system that was successful in all measurable elements from the VMware Converter and ESX-based virtual machine standpoint, yet the application was not functioning as expected. One important part of this conversion is that the virtual machine changed networks during the conversion. Everything checked out locally on the virtual machine, including DNS configuration, subnet mask and the IP default gateway. Yet the application still had issues working correctly.
Later on, I had discovered that there was a DNS record for the same IP address of the converted system. In this scenario, the workload had a separate DNS name that was in use by the application and not exclusively using the host name. Further, I believe that the record was a previous computer name of the converted system, and the application had some calls that still used the old name. Before I noticed this entry in DNS, I had checked the local host file on the Windows virtual machine to ensure that there were no entries pointing to an IP address other than 127.0.0.1 for any local references.
So what can be done to make sure that this bizarre information does not happen again? In the pre-conversion steps, take a look through the DNS zones and see if the IP address or the hostname are pointing to anything that references a specific IP address. While applications may have configuration beyond the scope of a P2V conversion, identifying any DNS or host file configuration before the conversion can save some frustrating and possibly unexplained application failures.
We all know that the VMware Infrastructure Client (VI Client) connects to either a VMware vCenter Server, VMware ESX host, or a VMware ESXi host. There is confusion on which users or users is used to run all commands issued by the VI Client either directly or indirectly through vCenter.
For example, when you join a VMware ESX host to vCenter you must enter the root username and password. Any username and password can be used as long as that username is a member of the administrator role that exists on every VMware ESX host by default. With a standard install, the root user is the only member of the administrator role.
The roles and permissions within the VI Client do not necessarily map to users and groups within the service console or management appliance. Roles and permissions are quite a bit different actually and do not always map one to one.
When you directly connect the VI Client to a VMware ESX or VMware ESXi host you will use a local username and password to log in. But after that, all actions depend on your roles and permissions within the VI Client. The VI Client does not run any command as the user to which you logged in. Instead it runs those commands you are entitled to run as the root user. Since the root user is also the super user, it can run any command available to the system. This translation happens automatically as the vmware-hostd daemon runs as the root user.
The same happens when you log in using the VI Client to VMware vCenter Server. VMware vCenter Server uses the vpxuser to contact the vmware-hostd daemon which in turn runs all the necessary commands as the root user.
For a direct connection, a user must exist on the VMware ESX or VMware ESXi host, but for an indirect connection, no user must exist on the hosts. This implies that when you use vCenter there is no real need to manage multiple user account systems. Unfortunately, in reality you often have to have users on your VMware ESX and VMware ESXi hosts to perform support actions.
The use of the root user also implies several other things. The current permissions granularity that you set up for files and directories within the VMware ESX and VMware ESXi hosts is ignored. Roles and permissions are not that granular yet. In other words, if you want to restrict a user from accessing a specific ISO. While I can set that up for specific users within the host, I can not set this up for specific users once the VI Client is employed. I lose some granularity when using the VI Client.
Keeping track of Security issues associated with virtualization requires a serious investment in time. To aid in that I have put together the top virtualization security links that will continue to grow over time.
The following links are just a sample of what is at the aforementioned site and should be read in order for those interested in securing your VMware Virtual Infrastructure and unfamiliar with VMware ESX, at the same time these are great references for the experienced administrator.
- VMware Virtual Networking Concepts
- VMware ESX Server 3: 802.1Q VLAN Solutions
- Security Design of the VMware 3 Architecture
- DMZ Virtualization with VMware Infrastructure
- VMware Infrastructure 3 Hardening
- CISecurity VMware ESX Security Benchmark followed by the CISecurity Linux Benchmark
- DISA STIG (ESX STIG depends on the UNIX STIG)
- Proven Practice: VI3 Security Risk Assessment – Xtravirt.com
- Remote Authentication – Full/Partial AD Integration, Secure LDAP, NIS, …
It is recommended to read as each guide or benchmark as each covers things from a slightly different but useful perspective.
On a recent VMTN roundtable podcast the subject of how large a single snapshot can become came up, and whether or not the snapshot can exceed the size of the original virtual machine disk file. I’ve always stated that a single snapshot can never grow larger then the original disk file but others had thought they had seen instances where this had happened. After the discussion, a bunch of us did some testing to reconfirm this, and our results all showed that the snapshot never grew larger then the original disk file despite the amount of data that was changed after the snapshot was taken.
Why is this? When a snapshot is created, the original disk becomes read-only, and a separate delta file is created that contains all the disk changes that are made thereafter. The delta file does not contain an ongoing history or transaction log of all the changes to data on the disk, it simply updates disk blocks as they are changed. If a particular block is changed it is written to the delta file, but if that same block is changed again later on the existing block is simply updated with the new data and a new block is not written to the delta file.
For example, if you took a snapshot of a VM with a 10 GB virtual disk, that snapshot could never grow larger than 10 GB, although it might grow slightly larger if every single disk block was changed because of the extra overhead space included in the snapshot disk file. The initial snapshot starts out small (16 MB) and grows in 16 MB increments up to the maximum size of the original virtual disk as changes are made to it.
In most cases the snapshot will not grow as large as the original disk, because typically operating system and application files are not changed once they are installed and therefore those disk blocks are not changed. If you performed a disk defragment inside the operating system, however, this could quickly and easily grow the size of the snapshot as files are being moved around on the disk which results in them being rewritten in a new location and, subsequently, the disk blocks are updated accordingly.
Now this only applies to a single snapshot. It is possible for the combined disk space total of multiple snapshots to exceed the size of the original disk file. The reason for this is that previous snapshots become read-only when new ones are created. If a particular disk block was updated from a previous snapshot, it would be written as a new block in later snapshots. That same disk block could then exist in multiple snapshots, which could make the combined total of the snapshots greater then the original disk file.
Even though copies of a single disk block can exist in multiple snapshots when it comes time to delete the snapshots, only the latest disk block is written back to the original disk and all of the others are discarded. Likewise, if you revert to a particular snapshot, then the existing disk block is discarded if it has been updated since the snapshot that you are reverting to, and the disk block from that snapshot is used instead.
This may all sound a bit confusing but the moral of this story is that a single snapshot can never exceed the size of the original disk file. For more information on snapshots be sure and check out the three-part series that I wrote about them: