December 04, 2007 | Comments: (0)
So this one had me pulling my hair out.
My main Windows XP box is a VM running under VMware Workstation 6. It began life running under VMware Workstation 5, and I never bothered to upgrade the VM to Workstation 6 compatibility until I needed USB2 support to handle a Zune that Microsoft so nicely sent me for Christmas. The Zune install was unfortunately problematic, involving a few bluescreens, but was eventually successful following a few reboots, uninstalling and reinstalling. All was well until I fired up the VMware Virtual Infrastructure Client 2.0 to run some tests in the lab. The app wouldn't display all objects nor any VM labels, and the layout was all over the place -- essentially unusable. Uninstalling and reinstalling resulted in no change, so I assumed that the Zune installation had borked the .NET installation that VIC relies on. Uninstalling and reinstalling .NET 1.1, 2.0, and 3.0 had no positive effect either. This was a major problem, since of course I didn't take a VM snapshot before installing the Zune software.
I had a slightly older version of that same VM on another system, so I moved that over to my workstation and tried again. Booting that VM had me back into a stable version of VIC, so I upgraded that system to VMware Workstation 6 compatibility and rebooted it... only to find that VIC was again broken. I reverted back to Workstation 5 compatibility and VIC started working properly again. After hours of frustration and ill thoughts towards the Zune, it seems that this was actually the problem(?! ... *&#^$*%&^!%@!).
This is completely reproducible, at least on these VMs, and really has me wondering... why would changing the hardware compatibility level for the VM break VIC 2.0? I don't know, but it certainly does.
Posted by Paul Venezia on December 4, 2007 10:07 AM
November 12, 2007 | Comments: (0)
I'll come right out and say this: I'm an AMD kinda guy. My main workstation runs Opteron 2220s, I prefer Opterons in my servers, and I've been looking forward to Barcelona for, well, far too long.
My attraction to the Opteron has been solely based on performance. In the past few years, the Opteron has consistently outperformed Intel's offerings, at least with my workloads. It seems that this may no longer be the case. My Stoakley reference system running two 45nm quad-core 3.0Ghz CPUs simply screams. I've had it running VMware ESX 3.0.2 for the past month, running a LAMP-based Web app load simulator I wrote in PHP. Even though on the face of it, Intel's design seems to be inferior and placing far too much emphasis on shared busses, the reality of the Stoakley platform is that it delivers.
Today's announcement from Intel regarding the new 45nm chips marks a reaffirmation of the next generation of processors. In reflecting on the fact that the new 45nm chips have transistor densities that place 30 million transistors on a space the size of a pinhead, I realize that the first Intel processors had around 2,300 transistors total. That was only thirty years ago, or so.
But enough reminiscing. Penryn is here, and it's going to make a splash if the performance of my reference system is any indication. The 6MB cache per die is definitely helping the numbers here, along with the 1.6Ghz FSB. If you want an exhaustive account of the ins-and-outs of the Stoakley platform and the new 45nm chips, check out Scott Wasson's Tech Report entry from September. I was at Intel in Oregon, standing a few feet from him when he took that beautiful photo of that wafer with a video camera of all things. I think I was laughing at the sight of three geeks desperately trying to photograph a largely reflective surface with digital cameras, and even took a photo of them trying to take photos.
On the outside of the box, I'm more concerned with what Stoakley can do for me. My Web app test hasn't changed much since I used it to test blade servers and VMware VI3 late last year. It's a relatively simple PHP script and a 500,000-record MySQL database. When a Web load generator is pointed at the script, it either serves up a static page, or makes a database call to generate a dynamic page. Tuning the parameters of the script can lean more towards Web server or SQL server performance, but normal operation has the predominate load shifting between the two as the test runs.
So I built a VMware ESX 3.0.2 server on the Stoakley box. The box itself had 16GB RAM, two 136GB U320 SCSI drives, and two Intel gigabit NICs. The onboard NICs weren't supported by VMware until just a week ago or so, and the SuperMicro case was low-profile, so I was limited to the dual-port LP Intel NIC I had. I dedicated one NIC to VM storage, and the other as the front end for all servers. I then built out six CentOS 5-based VMs: A two-CPU MySQL server, four single-CPU Apache servers, and a single-CPU load-balancer. Using LVS for load balancing, I nailed the box with HTTP requests for the Web test app installed on all four Apache servers. The load on all boxes grew substantially, delivering up to 4,000 requests per second, a number that's very dependent on the parameters of the test script, but certainly showed that the box was running on all eight cores, and running them hard. Over 200 million requests and nearly 15 hours later, the box showed no signs of distress, and each VM was still running like mad.
I kept the tests running over the next week, simulating a scenario that should never happen in real life, but occasionally does. After finally stopping the attack, I let the system quiesce, and then proceeded to load it up with more VMs for other tests I needed to do in the lab. I've wanted to run other benchmarks on the server, like compression and encoding tests, but that means that I have to power it down. I won't be able to realistically do that for another few days -- at this point, it's already indispensable.
So for now, I'm lacking raw numbers on standard tests, but I can tell you that my love affair with AMD is on shaky ground. I don't yet have a Barcelona system to run against Stoakley, and I really need to run those tests before I make any hasty moves. From what I've seen of Stoakley and Penryn this past month, my AMD honeymoon may be over.
Posted by Paul Venezia on November 12, 2007 07:12 PM
November 07, 2007 | Comments: (0)
So for all the virtual infrastructures that I've built in the lab and in the field, for every time I've PXE booted a new VMware ESX server into a production environment, I hadn't virtualized my own core systems... until yesterday.
It was a spur of the moment kinda thing, and I went with it. I started the day with five physical core servers of varying age, and ended the day with two, having collapsed the others onto a single Dell PowerEdge running VMware ESX 3.0.2. These were a few Windows boxes, three Linux boxes, and a FreeBSD system, all running on relatively ancient hardware.
It might be odd to think that just feet away from an Intel reference system running the new Stoakley platform and several 8- and 16-core servers from HP and Sun, a 6-year-old HP Kayak XU800 sat, a Fedora Core 3 system with a Pentium III-866 and two 40GB PATA drives in software RAID1, running Cyrus IMAPD for my 5GB mailbox, as well as primary DNS, DHCP, and NTP tasks for the entire lab on all VLANs. Around the corner from that were several other servers running various backup tasks, public Web apps, and so forth. I decided that everything had to go, and by 5pm, I'd rebuilt all the systems on the VMware box, including a somewhat annoying Berkeley DB 4.2->4.3 migration for Cyrus, since the new server was built on CentOS 5. Essentially, this was a 5-hour server consolidation project from conception to reality, and I don't seem to be the worse for it. In fact, I've lightened the power and heat loads in the lab, and am making far better use of the Dell PowerEdge 2800 that's holding down these new systems.
The PE2800 isn't the highest-spec box, especially for VM tasks. It has two HyperThreaded single-core 3.6 Ghz Xeons with 4GB RAM and a bunch of disk in a RAID 5, but it's now running 6 VMs like a champ, including my Asterisk PBX build. I plan on moving over a few more boxes today, but the bulk of the work is done.
One of the only issues that I have with the new environment is that all the VMware management tools are Windows-based. I really wish that VMware had continued their practice of producing Windows and Linux management tools, since my only Windows XP system is a VM running on my workstation and I now have a slightly disconcerting dependency there. Add to that the fact that the VirtualCenter server is running on a VM of its' own on another physical system under VMware Server, and I probably should build a standalone Windows server to handle those tasks. It would be ideal if VMware could bring simple VM management for ESX hosts into the VMware Server Console. I don't need all the bells and whistles there, but I do need to be able to powerup/powerdown servers and access their console. Since there's been consternation regarding the management split between VMware Server and ESX, this might actually happen, but I'm not holding my breath.
On the other side of the coin, migrating a VMware Server 1.0.3 VM to ESX 3.0.2 was very simple -- move the files into place on the ESX host, run vmkfstools on the vmdk, and import the VM via VirtualCenter. I found that it's best to delete the NIC from the VM and re-add it since there's some issue with variable syntax in the .vmx file between VMware Server and ESX, but all told, it was quick and easy, just the way it should be.
Posted by Paul Venezia on November 7, 2007 10:42 AM
September 27, 2007 | Comments: (0)
VMware Workstation VMM issues resolved in 2.6.22?
For those unaware, VMware Workstation 6 has been exhibiting some significant stability issues under some 2.6.19 and 2.6.20 kernels. VMware Workstation would run and behave normally for some period of time, then crash with a VMM (VM Monitor) error, and take down the X11 subsystem, requiring a reboot of the whole system. I saw clear evidence of this under Fedora Core 6 x86_64 on these kernels, but not on the 2.6.18 kernel. There were several threads dedicated to this problem on VMTN, and a few possible fixes offered, but none worked. I resigned myself to running the VMware Server Console on my workstation, and housing my VMs on a different VMware Server system, which definitely has some benefits over running them locally, but I was bothered by this mysterious issue. My main workstation is a Sun Ultra 40 M2 with two dual-core Opteron 2220s and 8GB of RAM, so using that to drive VMware Workstation for my Windows needs is really the best option from a performance and functionality standpoint.
Since then, a FC6 kernel update to 2.6.22 was released, and rather than step back to 2.6.18 on that system, I tried going up to 2.6.22. That was about a week ago, and the VMware Workstation instance on my main workstation has been stable since. I haven't found any direct reason for the problem, or its resolution, but there you have it. Also, for those curious on getting the VMware Workstation components to compile and run on Fedora or other distributions, you'll likely need the VMware any-to-any patches found here.
Posted by Paul Venezia on September 27, 2007 10:42 AM
February 07, 2007 | Comments: (0)
So I installed Vista Enterprise on a VMware Workstation instance over the weekend. After five days or so, I find that, well, it's certainly more attractive than Windows XP, and certainly more annoying with the constant barrage of confirmation dialogs, but I don't hate it. In fact, I liking lots of it so far.
A few brief notes, since I'm short on time:
1) It's very pretty. Still not as fluid as OS X or Beryl, to be sure, but much prettier than XP.
2) The things I really like (gadgets, searching, smooth look) are the same things I like about Mac OS X. Funny that.
3) There are going to be lots of people looking desperately for the Start and file menus. ("Oh, you can click on that circle thingy?")
4) It's huge. A default install with Office 2007 is 14GB for some reason.
5) The file system sure ain't WinFS, but it's also more fluid than XP. For instance, I originally installed it on a 16GB VMware disk, but quickly had only 500MB free. Running vmware-vdiskmanager -x 40Gb Vista.vmdk, then booting Vista, opening the Disk Manager and selecting Extend Partition did the trick on the fly, on the boot partition. Nice.
6) Some apps that work perfectly on XP bail on Vista, or refuse to install at all. It appears that they're having issues with the new security measures, but I can't be 100% sure. I can be 100% sure that it's a big pain, however.
7) I have managed to bluescreen one instance already, but that might have been due to VM issues.
8) Apple's new Get A Mac commercial is pretty much right on target. Allow. I wouldn't be surprised if in the home setting, most people disable the confirmation dialogs since they will be perceived as constant annoyances. That will mostly obviate this new security model.
9) I would definitely prefer Vista to XP for those times that I need a Windows system for work in the lab, but I'm currently running an XP instance and a Vista instance simultaneously, since I can't be guaranteed that all the apps I need will function. This will certainly hinder enterprise adoption, at least in the short term. Bummer.
10) It's very pretty.
Posted by Paul Venezia on February 7, 2007 07:16 AM
November 02, 2006 | Comments: (0)
So Novell and Microsoft are bosom buddies now. Unreal. While that's undoubtedly good for Novell, what's in it for Microsoft?
Forgive me for playing the cynic, but Microsoft has historically "innovated" by buying what they needed, enveloping companies for their products, IP, and brains. Exchange, Active Direcory, MS Virtual Server, etc... all purchased along the way. So what's up with this announcement? I bet Microsoft has finally figured out that this whole virtualization thing is harder than they figured. The competition has a huge head start, and Veridian is probably taking far too long in the dev cycle. By making this move, couching it in "interoperability" phrasing, offering the OpenDocument/OpenOffice and AD/eDirectory management bone, Microsoft may be hiding the fact that they need help with their virtualization strategy, and just might be borrowing off Xen and Novell's investment in it to get there.
No matter how you slice it, I bet there are more than a few snowballs flying past Lucifer's head right now.
Posted by Paul Venezia on November 2, 2006 06:11 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
- A Guide to Rich Internet Application (RIA) Security
