VM /ETC - Go Ugly Green! - Latest Comments

Re: Disable Debug Mode In VMware Player Or Workstation Betas

iMac — Sat, 01 Dec 2012 08:19:42 -0000

Disable Debug Mode in VMware Player - It's possible

It's simple, just Rename the file vmware-vmx-debug.exe to vmware-vmx-debug.exe.old then make a copy of vmware-vmx.exe and rename it to vmware-vmx-debug.exe don't forget to let the executable file vmware-vmx(just make a copy and rename it)

Regards.

Re: Is Citrix XenServer cheaper than VMware ESX Server?

cm — Tue, 27 Nov 2012 02:36:44 -0000

you are all right，everything havs two sides

Re: FTF Veeam v6 Replication – Veeam Architecture

rbrambley — Sat, 11 Aug 2012 07:39:37 -0000

cby,

Thanks!

I covered the scenario you ran into, admittedly very briefly, in the DNS and Permissions section. Or at least that was my intent. Maybe I should have titled that section DNS, Permissions, and Networking! Oh My! :) . The reality is that you have some complex NAT-ing that would have impacted any application architecture stretched across multiple sites and networks. Thanks for sharing the issue and your resolution here. It is a great example of some of the environmental factors that must be accounted for in a Veeam replication solution.

Re: FTF Veeam v6 Replication – Veeam Architecture

cby — Thu, 09 Aug 2012 04:22:59 -0000

Excellent article. I encountered all the points you mentioned and addressed them in the same fashion, proxies in particular.

One area you don't mention that caused me grief was the comms between the DR site proxy and the main Veeam backup server, and between the proxy and the ESXi host at the DR site.

For reasons outside of this discussion we have multiple IP addresses assigned to the backup server NIC connecting over a WAN link to the proxy. To complicate matters further we have several levels of NAT rules in place. By trawling through the Veeam logs after failed attempts to replicate I discovered that the Veeam backup server publishes all its IP addresses to the proxy when initiating the replication process. The proxy in turn attempts to connect to each IP until it establishes a connection to the Veeam server. None of the published Veeam server's local addresses were visible to the proxy because of NAt'ing. By assigning the NAT'd IP address to the Veeam server, as seen by the proxy, we were able to overcome this issue. The NAT'd IP now appears in the previously mentioned list of published IPs.

The workaround for the ESXi comms was to define the ESXi hostname with its (locally) associated IP address on both the Veeam server and the proxy. So now when the proxy resolves the host name it sees the local IP as opposed to the IP associated with the host on the Veeam server. It's not ideal but does the job well.

The multiple NAT'ing rules are what really threw it especially with the replication running over a secure .gov n/work.

Regards
cby

Re: Announcing the 2009 Q1 VM /ETC UGG & UGH Winners

gurjeet — Wed, 30 May 2012 02:40:22 -0000

we wouldn't have this ugly green blog to learn from.

Re: VCB in a Virtual Machine and other product enhancements

Rudragouda90 — Wed, 04 Apr 2012 02:18:09 -0000

wat is mwant by virtual machine based proxy

Re: KVM Key Stroke Combination for IBM BladeCenter

rbrambley — Thu, 22 Mar 2012 21:03:53 -0000

Glad to help!

Re: KVM Key Stroke Combination for IBM BladeCenter

Malcolm R Chalmers — Thu, 22 Mar 2012 20:52:43 -0000

thank you very much for this info.
it was driving me nuts not being able to switch blades.
thanks.

Re: Help Me Choose a Hypervisor

rbrambley — Tue, 13 Mar 2012 07:13:06 -0000

Rich Brambley
rbrambley@gmail.com
Twitter @rbrambley
http://vmetc.com

Re: Virtual Machine Sniffer on ESX Hosts

Protegus3 — Wed, 25 Jan 2012 08:41:51 -0000

this is what we did:

http://www.vmware.com/appli...

Re: Virtual Machine Sniffer on ESX Hosts

Frans — Wed, 25 Jan 2012 04:58:59 -0000

Actually wondering the same thing right now (that's why ended up here. Seen the V2P tap, not appear to be free no more). But did you ever get an anwer?

Re: Creating and Configuring Headless VMs in VirtualBox

Praveerai — Fri, 20 Jan 2012 02:50:32 -0000

Nice document and usefull one Thanks a lot .......

Re: A Virtual Tipping Point

Dracolith — Sat, 27 Aug 2011 01:22:56 -0000

I think VMware have managed to adjust the vRAM entitlements for Enterprise perpetual licenses slightly, but sufficiently enough to eliminate a lot of the immediate objections from existing VMware licensees.

There are likely to still be some casualties -- but I think the tipping point has been postponed
a little bit by VMware's vRAM revision.

Now the tipping point will be controlled by the capabilities of the competition, especially if VMware adjusts/revises vRAM upwards later as customer requirements change to accomadate new RAM-hungry OSes.

The problem will come when existing VMware customers need to upgrade their RAM, as new guest OSes require more memory. So people nervous about the future and not confident about VMware's future licensing direction are STILL likely to be looking at other hypervisors, if they don't immediately eliminate it due to missing key features that are still sometimes more valuable than the price changes.

I'm saying this as someone who was a XenServer admin before a VMware admin.
XenServer is (unfortunately) not nearly, I will say, 'refined' as VMware. It's true it's not as featured as well.

If your business benefits from using the VMware features other hypervisors don't have,
your organization needs to either learn to live without them, or find another product.

If you need something like storage vMotion type capability... you may actually find that VMware's option is cheaper than the third-party addon.

Good luck with non-Windows/non-Linux support (eg Solaris, FreeBSD);
yes there is HVM, no... HVM performance is not up to par at all without paravirt drivers,
not nearly what it is in VMware, in my experience.

Re: Things That Make You Go Hmmmm – Disgruntled vSphere Admin Remotely Deletes 88 VMs

Dracolith — Sat, 27 Aug 2011 00:35:26 -0000

I agree.. Veeam Backup is certainly the best VMware backup product from a technical standpoint IMO. SAN replication to a backup storage unit is cheap and will also do it,
but unless VMs are on NFS, I dislike the fact there's no way to tell a
SAN "hey, look inside this 1TB VMFS volume/extent, and give me a copy
of this one blahblah-flat.vmdk from last week's snapshot, and clone it to a new directory on the current active VMFS datastore".

If you've got an average ~8:1 consolidation ratio or better I would say Veeam is absolutely perfect and undefeated.
Unfortunately... from a cost standpoint, at the $2000 or so per CPU,
last I heard; pricing means it would be impossible to get management on
board in at least my planned proof of concept due to low VM-density, in order to host
customer VMs.. VMware offers per-VM monthly rental under VSPP; which is ideal.. Perhaps when the market for VM backup products is more mature, a similar option will be available by backup vendors.

Consolidation = risk. The company would also be in a bad situation
if a disgruntled storage admin had logged into the SAN from McDonalds
and removed all the volumes, then wiped out RAID groups, flashed the SAN's head nodes with an invalid / "hardware bricking"
firmware, and issued a reboot. That said... this is just a virtual equivalent of a disgruntled employee setting fire to the server room, or ramming a truck through the building.

That is... the ultimate consolidation is, your entire datacenter is usually consolidated within 1 building, hence being called a datacenter rather than a 'data neighborhood'. :)

Risk should be managed. Crime cannot be prevented if the would-be perpetrator is sufficiently determined. Security measures implemented should first _make sure_ that any perpetrator _HAS_ to be an insider, _and_ an insider will be identified, _and_ insiders know they will be identified (deterrent). Audit records should be stored at X separate care, so that they cannot be destroyed by the perpetrator with access to Y.

Then after isolation and auditing is established, worry about integrity.

""I also wondered “What if the attack was less obvious?” What if
only slight configuration changes were made to the virtual machines
instead of obvious deletions?""

I wonder how many recommendations from VMware's Security hardening guide, the company victimized ignored, or failed to implement?

Security is tough. First of all... for the problem of attacking VMs; the profile of potential types of attacks are numerous. Most serious attacks come from a rogue individual (whether they be an admin, disgruntled
non-admin employee, or outsider with accidental or intentional
assistance from an insider); but system failures, and admin errors are also possible (sometimes admins won't even admit they made a mistake, and you need audit logs to bust them).

Another type of attacker is a piece of malware. Usually these are less destructive. But there exists the possibility of a malicious DoS.

VMware environments can be attacked at several layers
o The storage itself.... whether shared or DAS, is a potential target.
Physical layer attacks:
- Someone intentionally (or accidentally) physically damages disks, such as by taking one out and dropping it, either in a manner that causes immediate failure or one that will cause failure in the future, such as shouting at the disks, or removing/disabling some fans in the chassis.
If someone physically causes an entire RAID array to be lost (e.g. by physically walking up to a SAN and pulling the ejector on each drive), then all services stored on it may experience extended outage.

Methods of mitigation: Physical security. Video cameras. Camera footage should be stored immediately on servers in an area separated from the one monitored.
Unfortunately, this isn't preventative -- but enables you to discover when a policy is violated.

It won't detect if someone takes a cold spare HDD elsewhere on premises outside the camera's viewing area, inflicts minor damage on the drive, and then returns it.

Logical layer attacks, examples:
- Someone attaches a rogue server to the SAN, which might or might not be an ESXi server, or co-opts an existing server (for example, a VCB proxy server),
   and intentionally corrupts data on a VMFS volume or writes random bytes to some
   place on the VMFS device itself.
    eg    dd if=/dev/random of=someimportantfile.vmdk bs=1024 count=100 skip=(somerandomoffset)Of course 'someone SSHs into an ESXI server' and mucks around with .vmx configurations are also possibilitiesSo you can group these...     (a)   Logical attacks directly at the storage      (b)   Logical attacks that involve accessing ESXi hosts and tampering with things but not using the official interfaces      (c)   Logical attacks that involve using the proper APIs/interfaces to change things via central managementTo mitigate (a) you need tight SAN/storage security, isolated storage networks, measures such as LUN masking to ensure only authorized servers have access, measures to ensure VCB/backup proxy servers are not available outside storage network; security of SAN management interfaces.To mitigate (b) you need (a) mitigated AND tight ESX/ESXi host security, isolation of ESXi hosts from direct access from off-net, SSH locked down, possibly vCenter lockdown mode enabled.To mitigate (c) you need back channels (a) and (b) already mitigated, and measures taken to secure, isolate, and audit vCenter itself.Noting that if (a) is not secured,    (b) and (c) security alone are incomplete.

Re: Disable Debug Mode In VMware Player Or Workstation Betas

Carlos Contreras — Thu, 25 Aug 2011 00:48:04 -0000

By the way on x64 bits platform you must also rename on vmware:

%PROGRAMFILES%\VMware\VMware Workstation\x64
the file vmware-vmx-debug.exe to vmware-vmx-debug.exe.old

Or in Windows 7 go to search into vmware folder and write "debug", in my case there are 3 files.

Re: A Virtual Tipping Point

rbrambley — Sat, 20 Aug 2011 07:27:10 -0000

Dale,

Thanks for your comments and scenario. I continue to hear the same from VMware admins weekly!

Re: A Virtual Tipping Point

dscriven — Fri, 19 Aug 2011 07:48:47 -0000

This announcement came as a bit of a shock to me as well seeing as I was in the middle of putting together a admitidly small scale virtual solution for my new company. before the annoucement I was vmware all the way not even looking at the competition. Now however I'm forced to look at the competition xenserver is by far just as capable solution for what I need without the upscaling limits for my predicted 4 host 2 prod and 2 at DR site. Now I've got to put both solutions before the ceo, I still am happiest with vmware but TBH xenserver fits my needs just as well without stunting future growth with upscaling costs.

Dale

Re: Tricks for getting a VM to boot from CD – bios.bootDelay

Anu Chandran — Wed, 17 Aug 2011 13:03:27 -0000

Thanks.. very helpful..!!

Re: Force Remove VMware Tools and Manual Clean Up

rbrambley — Wed, 10 Aug 2011 06:19:39 -0000

Ali,

Thanks for the tip!

Re: Force Remove VMware Tools and Manual Clean Up

Ali Fakoor — Wed, 10 Aug 2011 02:54:04 -0000

What if setup.exe is not available in your version [or it does not accept the /c parameter for forcefully cleaning]? Here is a solution:

Run these commands at an (elevated) command prompt:
sc delete vmmouse
sc delete VMMEMCTL
sc delete VMX_svga
sc delete VMTOOLS
sc delete "VMWare Physical Disk Helper Servive"

Now reboot the system and then remove the instllation entries using the windows installer cleanup utility (http://www.softpedia.com/pr... [NOTE: This tools was originally available from microsoft website, but was removed due to some issues, see:http://support.microsoft.co...]

Afterwards you can manually remove the installed program files of the VMWare Tools.

Hope that helps someone [in future]
Ali

Re: Virtually Backing Up A Physical SQL Database (vCenter, Veeam, etc.)

rbrambley — Fri, 05 Aug 2011 17:50:07 -0000

Lane,

First let me clarify, Veeam does not backup Workstation VMs, so the VM Tools of the "virtual physical" vCenter in my lab are never used. Nor is any snapshot created on the vCenter Workstation VM. Hence it's "virtually physical" - just like a physical vCenter running in a physical datacenter.
For Windows VMs running on vSphere , Veeam does use the MS VSS framework when backing up VMs. In the job config you provide local credentials on the VMs so Veeam can make the VSS calls for backup, and just as important, for placing the VM in a restore mode during the restart. It's an application consistent process and the logs are truncated. More details in this whitepaper http://www.vmworld.com/docs...

See you at VMWorld!

Re: Virtually Backing Up A Physical SQL Database (vCenter, Veeam, etc.)

Lane Leverett — Fri, 05 Aug 2011 17:06:33 -0000

Hey Rich! Great post and innovative idea. One thing I wanted to check on though. You mentioned that you performed the backup while vCenter was running and that BaR doesn't use agents in the guest to handle any quiescing of the application. My guess is that BaR call VSS to do any application level quiescing. Are you using Microsoft's VSS writer, or the ones in VMware Tools. If the latter this obviously would work in your lab scenario since the vCenter "physical" server is actually a VM running VMware Tools from VMware Workstation. Would love to know the details around application level quiescing using BaR. Thanks for the great post and will catch up with you at VMworld in a few weeks!

Re: Use the VI Client Datastore Browser to Upload Files to ESX Hosts

Santhoshvarghese2003 — Wed, 03 Aug 2011 21:40:11 -0000

Thank you.. It helped

Re: A Virtual Tipping Point

Fish — Mon, 01 Aug 2011 20:12:07 -0000

Kill the cloud please, I'm so sick of that label I could scream.

Re: A Virtual Tipping Point

Dracolith — Thu, 28 Jul 2011 03:01:19 -0000

Yes... I think it has been reached, and many organizations will be looking at Citrix or Microsoft solutions a lot harder for future deployments. As for VS5 being about cloud... frankly... the only "Cloud" of significance I see in VS5 for the Enterprise, is VMware having their head in the clouds. :)

If VS5 has been delayed to 2012, that's news to me. According to the announcement, VS5 release is expected August 2011. One of the mistakes VMware has made, I think, is they haven't really emphasized any major improvements in VS5 that all organizations will get, unless your organization has Enterprise+ licenses, there does not seem to be much in the way for us mere mortals to get excited about.

Their "Cloud" label is just hype, until there is specific documentation about what this feature point is exactly, and how it benefits the vSphere customers. "Cloud" has become such an abused buzzword that means so many different things, that it is actually a meaningless label.

VMware's customers are left bored... talking about things like licensing, which seems to be the largest "greatest" change in VS5. The VS5 vRAM restriction is
essentially a major price increase for customers that utilize large
amounts of RAM, or that choose to oversubscribe RAM, for one reason or another,
whatever that might be.

Personally I preferred the 256GB physical limit as the way to limit RAM. If I had to buy an extra CPU license to utilize 512GB, in the same way you needed extra CPU licenses if you had a CPU with more than 6 cores, I would be happy with that.

But the ramifications of vS5 VRAM are complicated, possibly differ for every environment, and do require math to analyze current and expected effects for each enterprise. The complexity/reduction of flexibility, increased risk, and high cost of expansion, alone raise concerns all of their own.

I can understand any customers being infuriated if they just bought 3 year SnS for investment protection to get included upgrades, only to find the "free upgrade" won't be "free" at all. And frankly, VMware's response as indicated on community forums/elsewhere, with suggestions like "Right-size your VM memory", is patronizing at best, and insulting at worst.

There is a moral/ethical question here also... then.. was VMware honest when they sold those SnS agreements in that case? I would rate VMware poorly on that subject, if they do not do something to make it right for those customers; if you sign and pay for a maintenance contract, it is not seemly for the contractor to invent new types of charges or new measures of utilization not mentioned previously.

VS5 has some ramifications for anyone using ESXi free standalone with its new 8GB RAM limit, or Essentials, with its fixed RAM limit per kit that cannot be expanded, without a $12k spend for Standard Acceleration Kit; even if there is not an immediate cost, the limit is going to eventually be reached.

The economics of the situation would seem to indicate.... competitive players; Citrix, Microsoft are coming to market with robust hypervisors, so there is an increase in capacity for production of hypervisor software in this market. Prices should go down within a few years, when organizations' switching new business to competitors, cause VMware to observe abysmal sales at current prices, unless VMware's goal here is to be a niche player rather than a market leader, they will have to actually compete, and only charge more
for the pieces of their solution where they can actually deliver value (within their customers' budget).

There is plenty of glossyware from VMware's marketing department, but little meat for VS5. As an Engineer, I would appreciate some better explanation from VMware of why VS5 will be better at release for all customers, and why the improvement will be worth the price increase and increase in licensing complexity (and therefore increase in assessment/compliance costs).

For many customers new features such as "Storage DRS" are not something we are going to be rushing to deploy; the technology needs to be proven first, and giving it such a high price doesn't encourage broad deployment.

So competing hypervisors' lack of "Storage DRS" is probably not much a competitive disadvantage for them.