All Posts

While we're on the subject of educating customers, I'd like to make two observations. 1. The VMWorld materials often present focused topics, such as performance best practices and the handling of virtual/physical/machine memory, much better than the classroom materials do (at least the two classes I have taken). The class materials, in my experience, are little more than barely-glossed powerpoints, sometimes badly edited, and of little value months after the class. It would be great to see some of this existing expertise recycled to enhance the training materials. And, oddly, the classroom VMware classes I took were each individually more expensive than VMWorld's cost. 2. It's true that VMwre is becoming a mainstream technology, and this means different customers and different expectations will be applied to it. Learn from the best practice of other mainstream technologies, such as Microsoft. They have white papers, excellent student course manuals, walkthroughs, entire books at several levels of depth, webcasts, podcasts, etc. This undisputably accelerates mainstream adoption of their technologies. It's worth emulating. The IT world teems with the bones of companies that thought they could compete with Microsoft because they had a better product. All of us here want VMware to succeed and thrive.

We use Webex. You log into the Webex server and see our slides there. You have to call in on a phone line to our teleconference, so you need to have a phone that can be tied up all day with a headset or a speakerphone. Do not try to use a battery powered phone. You see the slide and hear/ interact with the instructor over the phone. Many people find it a comfortable way to take a class. You do need a quiet place to work.

From all that I can gather, Install and Configure is all that's covered by the test; although I need to know all the products. The VCP exam asks you to understand the differences among VMware products, and then drills down into operational, hands-on detail on ESX and VirtualCenter. The best way to know exactly what's covered is to consult the VCP exam blueprint. Does Install and configure practically cover what the certification covers? As a practical matter, you'll find that VCP exam blueprint quite reminiscent of the contents of Install and Configure. However, there's no substitute for hands-on experience and studying. For the topics in the blueprint that call for comparing VMware products, you'll find the VMware Web site helpful. We already use ESX Server 3.5 and VirtualCenter 2.5 in production. I have sufficient hardware available; will I have the software available to me to create a test environment for practice? I cannot tinker with production. Unless I am mistaken, the installers for ESX 3.5 and VC 2.5 are essentially bundled with a 60-day (90-day?) evaluation. So if you have spare hardware and the binaries your company used to build the production instances, you should be ready to go. Can I assume some kit comes before the class? I need 1 month to play. Regrettably, no, you will not receive your student materials before class starts. But you can certainly use your time profitably before class. I would suggest trying to perform the tasks outlined in the exam blueprint, using the documentation. You can also get ideas over in the certification forum. Good luck! Message was edited by: brianriceca because I accidentally omitted one of the questions

There are some command references at : http://pubs.vmware.com/vi35/server_config/wwhelp/wwhimpl/common/html/wwhelp.htm?context=server_config&file=sc_appa.20.1.html I'm not sure that I've ever seen one book that has the command line stuff in one location I will say the the VMware DSA class has quite a bit of the command line as part of the automation portion of the class.

I can't really think of other reasons to use the shell. Other than simplicity/speed. Sometimes it is considerably faster to complete a one time complex operation in the shell than through multiple GUI clicks. This varies with the task however. Stop making powershell sound so attractive, I can't give up my protective blanket of Unix being able to solve every IT problem ever created!

I suppose I will have a go at Powershell if another Unix user can recommend it. I still don't want to give up bash! Here is the brilliant thing about Powershell. You know how, in Unix shells since the dawn of time, the key concept has been the text pipeline. So you type ls -ls | sort -nr | head -10 and the like. Powershell is built around pipelines too, but they're object pipelines rather than text pipelines. So all the semantics of each object ride all the way down the pipeline. So, in the VI Powershell Toolkit, doing a VMotion from the command line starts with something like get-vm | move-vm. That's grossly oversimplified; you have to say which VM you want and where to move it to, and you do that with command-line switches. But you get the idea. Thanks for answering my little poll about command-line use. Can you think of any other reasons (beyond my 3) to need the command line?

Thanks for the excellent responses. The "mystery course" certanly had me stumped. I suppose I will have a go at Powershell if another Unix user can recommend it. I still don't want to give up bash! :smileysilly: And, to answer your question brian: 1 They just prefer the command line over GUIs. I certanly fall into this category. In general I am much faster in a Unix environment with the shell than with a GUI. Having said that, I will use whichever tool is best for the job. For example, in Linux for Active Directory integration I now prefer to use the X tool provided by Red Hat than manually editing conf files as the X tool is faster for my needs. 2 They're building automation. This is a thing I always like to have up my sleeve. If I get a request that is outside the bounds of normal behaviour, I like the option to script and automate the process so I can do less work! (I am lazy like that.) 3 Their objective is to troubleshoot, so they want to be able to reach beneath the GUI. I fall into this one as well. Partially for troubleshooting, but also for pure understanding. That is, if I can learn each part of the system from a process/command line level, then I will always know what is happening at the higher levels when using the GUI or the VI Client. I don't like being of the mindframe where I only know how to do something via rote, and which buttons to click on which window. I really want to understand what a given system is doing, and why. If I can know that to a reasonable degree I am more comfortable and more effective in using a system.

Hi, Mr. Flibble. I would like to add to my co-worker John ("cpqarray")'s comments above. Also, even if I bore you with too much detail, I have a question for you at the bottom of this message. There are several ways to script in a VMware Infrastructure environment. The oldest way is with Service Commands. Our VMware Infrastructure 3: Deploy, Secure and Analyze training course covers, among other things, how to do many important VI tasks at the Service Console command line. A newer way is to use our Web Services API with a programming language such as Perl or Java. For some time now, VMware has made the VI Perl Toolkit available; this package makes programming using the Web Services API a lot easier by wrapping up API calls in nice pre-packaged Perl object methods. Although we don't have any training on the VI Perl Toolkit right now, the documentation contains tons of working examples. An even newer way to script (new as of 3.5 and 3i) is to use the Remote CLI. This is, in effect, a reimplementation of familiar Service Console commands using the Web Services API. We don't have any standalone training on the Remote CLI either, but you can get a flavor of it from the demonstration of Storage VMotion, a CLI-only feature, in our self-paced online course on what's new in 3.5. Finally: what John referred to in his post above is the VI Powershell Toolkit. Do you know about Powershell? It is the new Windows CLI, and easily the coolest idea to come out of Microsoft in a long time. (I am a longtime Unix geek, so I hope that compliment has some weight coming from me.) Right now VMware is running a public beta of the VI Powershell Toolkit, which is built on top of Powershell. It is excellent because it lets you do a lot of VI actions from the command line that would take a ton of code in the Perl Toolkit and would be impossible from the Service Console command line. We will be offering self-paced online training on the VI Powershell Toolkit in a few months, and Powershell will be coming to our instructor-led curriculum later. OK, Mr. Flibble, now I have an opinion question for you (and any other VMware user reading this who cares to weigh in). In my experience, people who want to script VI, or learn more about command-line ESX and VirtualCenter management, do so for one of three reasons: 1 They just prefer the command line over GUIs. 2 They're building automation. 3 Their objective is to troubleshoot, so they want to be able to reach beneath the GUI. Do you fall into one of these three categories? If so, which? If not, what have I missed? Thanks! -- Brian Rice Education Services Product Manager Professional Services Organization, VMware, Inc. Message was edited by: brianriceca to clarify that Powershell comes from Microsoft and the VI Powershell Toolkit comes from VMware

After all VMware products are far from being "normal" software. Unfortunately, now many VMware customers expect its products to be normal software. Consider VMware Fusion. It's aimed explicitly at my dad: a consumer user, not an IT professional, who just wants his applications to work. In the evenings and weekends, I spend time answering questions on the Fusion VMTN forum; it is a very compelling intellectual challenge. Explaining VMware concepts to people who are not computer experts is endlessly humbling. most of the enterprise users either have educated / trained employees or have easy access to them. Even this is no longer true. I speak from personal experience: In the early days of VMware's customer education program, basically all customers who showed up for training on our enterprise products already had prior experience with virtual machines, and the vast majority had command-line skills. Today, most new attendees of our entry-level ESX/VirtualCenter training class have never used any virtualization product. And, although they are system administrators, few have significant experience at the command line (Linux or Windows). Few have scripting skills. Most expect the GUI to be their sole work environment. VMware's products are increasingly mainstream. That means people have mainstream expectations for them. This is why I do not think that documenting .vmx files and the like will decrease VMTN gurus' workload. More and more VMware customers, if they found such a document, would think, "Hmmm, this document simply does not apply to me, because it makes assumptions about my prior experience that are not valid." This is not a criticism of those customers; on the contrary, it's a challenge for VMware. For one thing, our documentation has to evolve to meet the challenge, and even ESX guys like me try to pitch in: But our software has to evolve to meet the challenge too. Hence the Compare to... proposal I'm working on. There is a third way: supporting our gurus better. I think that the best way to do that would be for us to do a better job with documenting the top N issues for each product. That way, fewer uninteresting problems would make it through to gurus. I am formulating some ideas about how to do this; your suggestions are most encouraged.

We have a production cluster of ESX nodes, but I'm fairly sure it would be a bad thing to experiment on it. Very wise! If it were up to me, you'd pass. But it's not. So, moving right along... Does VMWare have any downloadable or remote accessible lab environments that students hoping to take the exam can practice on? Someday we will be able to let people rent a block time on a lab environment much like what they had in class. But we're not there yet, and it will take us a while. Alternatives? Well, it depends on how much money you want to spend. One way that's cheap or free: more and more people are running ESX inside Workstation virtual machines. This is totally unsupported, and the performance is not so hot at all, but it does work. I've even done it myself, using instructions that you can find out on the intarwub. If you have a computer with Intel's Vanderpool or SVT (its AMD equivalent), you can even run VMs inside your VM. Set up a VirtualCenter server on another computer (or even in another VM), and you have yourself an environment. (Caution: if you want to use Fusion 1.x or 1.1.x on a Mac to do this, use ESX 3.0.x, not 3.5 or 3i.) A slightly less cheesy way to approach the problem, but more expensive: buy one or two cheap old used servers and set up a home lab. I myself have an old Proliant DL360 G3 in my closet; I bought it on eBay for a few hundred bucks, and ESX 3.5 runs fine on it. If I had another, I could even do VMotion, DRS, etc. Of course, the server noise would completely traumatize my cats. Here's another strategy some of our customers use. Many companies buy a server every month or so. If your company buys servers at a predictable rate, you might be able to sneak in a few weeks with some servers before they go into production. Call it "burn-in." ESX is a really good memory-tester, as a matter of fact. If you have flaky RAM, ESX will find it. OK, I am out of ideas. Good luck with the exam!