Yellow Bricks

by Duncan Epping

Archives for 2009

VMware vCenter Data Recovery

· ·

During VMworld I quickly wrote down the steps that VMware vCenter Data Recovery takes when backing up VMs. I added one step which isn’t unimportant, changed block tracking(4):

  1. Create a snapshot of disk(s)
  2. Hot add disk(s) to Data Recovery appliance
  3. Create hashes of (hopefully variable) blocks
  4. Read data of changed blocks if previous backup exists
  5. Dedupe(using variable chunk sizes) and create SHA1 hash for index
  6. Store data (possibly encrypted)
  7. Remove hot add disk(s)
  8. Remove snapshot

Compared to the current VCB installable and current feature set VI 3.5 offers this is a huge enhancement. (VMware vCenter Data Recovery will be part of the vSphere products.) Creating deduplicated back ups of only the changed blocks based on variable chunk sizes will give every user the opportunity to have a decent backup scheme. VMware vCenter Data Recovery utilizes the new VMware Consolidated Backup API by the way. For those afraid that the dedupe datastore gets corrupted an automated short integrity check is performed once a day and a thorough integrity check once a week.

Keep in mind that not only VMware will be able to utilize these new features. Because VCB is changed to an API a much tighter integration with 3rd party backup tools can be expected in the near future!

I would love to get my hands on a beta version of the product as soon as it’s available to play around with it some more and tell you more about the rich feature set this product will have. Unfortunately it’s not available yet and you will all have to wait, but I will keep you posted.

VMware View Open Client

· ·

I’ve been using the VMware View Open Client for a while now. One of the things that the VMware View Open Client is still lacking is USB redirection. I just received a cool workaround for this “problem” from Attila Bognár.

In short: VMware View Open Client calls rdesktop, if you add a script with the name rdesktop to your path you can add several commandline options:

  1. Create a script called /usr/local/bin/rdesktop
  2. The script needs to contain the following:
    #!/bin/bash
    /usr/bin/rdesktop -r ‘disk:media=/media’ “$@”
  3. Add “/usr/local/bin/” to the PATH variable and make sure it’s inserted before the original location of the rdesktop(usually /usr/bin) binary.

The -r option adds USB redirection, but you could use any of the other rdesktop commandline options to achieve the desired functionality.

VMworld, the wrap-up

· ·

VMworld Europe 2009 came to an end on Thursday. I finally traveled back on Friday, after a 5 hour delay.

I’m sorry I haven’t been able to write any technical content but you can’t imagine how busy I’ve been. I’ve gathered all useful links and added them to this post. But just to give you an idea what I was up to during VMworld:

Arrived on Sunday at 15:00, dropped luggage at hotel and went to the Hands-on Labs. Started unpacking the thin-clients and helping with the lab environment till 20:00. Changed clothes and went to the Veeam party.

Monday, 08:30. Preparing the labs again. Testing lab manuals, setting up thin clients and solving SAN issues. Finished at 21:00 and went directly to the Dutch VMUG Meet and Greet.

Tuesday, 08:30. Back to the labs again and do some final testing. At 10:30 first people entered the labs and I had Community Booth duty the rest of the day till 19:30. Quickly changed clothes and back to the VMware Benelux party.

Wednesday, 08:30. Watched the keynotes and hurried off to the community booth again. Helped a couple of minutes at the labs but mainly booth duty. Went to the hotel at 18:30 to change clothes for the VMworld Party Cloud9.

Thursday, 08:30. Lab duty for the first couple op hours. Booth duty the rest of the day. Couldn’t feel my feet anymore after a couple of hours. When the solution exchange closed at 16:00 we needed to put everything in the original boxes again. All thin-clients / monitors / keyboards etc. 19:30, done, change clothes and went out for a decent meal… actually the first decent meal this week.

This, was just a quick write-up. But you can imagine that most VMware employees have been running around all day long, no time to eat / drink / sit down. Talking to people all day long, answering questions or just random chit-chat, there’s even no time to reflect and digest all the announcements. Keep in mind that even weeks before VMworld people are doing preparations. For instance the VI-Toolkit lab had been tested by at least 6 people two week before VMworld. When I visited VMworld as an “attendee” last year I honestly didn’t have a clue how much work an event like this really is.

For the Hands-on Labs: At least 1000 attendees visited each day. Yes a THOUSAND at least. I really loved the format of the labs, the open floor instead of the closed lab sections was also a great idea! I would have never expected that there would have been queues, but there were… Sometimes even over 20 people were waiting just to get in. Definitely a big compliment to all Hands-on Labs staff, they/we did a great job.

And let’s not forget the team that organized this event, great job! Thanks!!!

I hope I will be able to attend VMworld 2009 in San Francisco. Over 15.000 attendees are expected at the Moscone Center:

VMworld 2009 Europe Linkage

· ·

Because I haven’t been able to write as much as I would have liked I created this link list. I didn’t include all VMworld articles, just the ones I think are worth reading.

I want to highlight these 4 blogs cause they covered VMworld by far the best in my opinion and deserve some more exposure. Martijn, Simon and Jason wrote a couple of outstanding articles. And Eric Sloof video coverage was top notch again. Here are the links:

Keynote Day 1 and wrap-ups:

Keynote Day 2 and wrap-ups:

Announcements:

Hands-on Labs:

Sessions:

Various:

RE: max num vCPU’s Malaysia VMware Communities

· ·

I was just reading this article on the Malaysia VMware Communities website I’ve read a couple of article on their website that didn’t make sense but this this time I’m going to respond cause it might set people on the wrong foot. Anyone is of course entitled to their own opinion and views, but please reread your article and check the facts before you publish, especially when your blog is featured on planetv12n. A short outtake of the blog:

If we refer to the current version which is ESX 3.5 u3, the maximum number of Vcpu per ESX server is only 128 per ESX Servers. Personally, I think the number of Vcpu per ESX servers is too minimal. Imagine if we do run a servers with 4 or 8 physical CPU sockets and we consolidate 40 : 1 Physical server in our virtualization environment, we will hit to the bottleneck on maximum numbers of Vcpu per ESX servers but not due to the CPU consumption

Reading this short section one might think, why reply it makes sense? No, it doesn’t make sense at all:

  • The current limit isn’t 128, it’s 192 vCPU’s.
    So even with a 40:1 ratio and all VMs provisioned with 4 vCPU’s you wouldn’t hit this limit. Read the max config guide, it’s the bible for virtualization consultants.
  • But even more important: co-scheduling and over provisioning will impact performance. With most VM’s running 2 or even 4 vCPU’s scheduling will be almost impossible even with the relaxed co-scheduling techniques ESX is using these days. In other words, please don’t use multi vCPU VMs as a standard, you can read more on c0-scheduling here.

The author asked VMware to bump up the max number of vCPU’s. Now for a VDI environment this can and will be useful I think. Again if you are hitting the number with a 16 core machine, you might need to reconsider your provisioning strategy.

I expect the number to go up… especially after watching Stephen Herrod’s keynote at VMworld Europe 2009.