william_faulk Tracker

Re: Avoiding mouse grab with text console

william_faulk — Wed, 27 May 2015 14:05:47 GMT

Has anyone looked at this or tried it out yet? Am I the only person irritated by the mouse grab?

Avoiding mouse grab with text console

william_faulk — Thu, 21 May 2015 20:32:22 GMT

Most of the systems I have running under VMware have text consoles with no mouse capabilities at all. When using the console via VMware, in order to type into the console, VMware grabs the mouse and requires you to Ctrl-Alt in order to regain control of the mouse. This is a real pain.

I wrote a program that runs on the guest that switches the console into absolute mouse mode, which means that VMware will relinquish the mouse without Ctrl-Alt, just by moving outside of the window, just like if you had VMware Tools installed on a GUI console.

I've tested this program so far with CentOS 7.1 and FreeBSD 10.1 guests and it seems to work perfectly with the Fusion console (with both local and remote guests) and the Windows vSphere client. I have other OSes that I'm planning to test with, but I'd appreciate some feedback from anyone else.

The source is available on GitHub. The v0.1 release page has 64-bit Linux, FreeBSD, and Solaris binares. The binaries probably won't work across 32- vs 64-bit architectures. I'll try to provide additional binaries when possible.

Re: PowerCLI Set-CDDrive cmdlet gives strange error

william_faulk — Fri, 24 Oct 2014 23:49:56 GMT

It turns out that the Web Client proxies everything through Flash AMF Objects and it was being a real pain to decode, so I gave up and looked at what the Windows "fat" client does. I found that the biggest difference is that PowerCLI sets the CD drive to "VirtualCdromRemotePassthroughBackingInfo" in "Exclusive" mode and the fat client sets the CD drive to "VirtualCdromRemoteAtapiBackingInfo" and does not specify exclusivity.

The other thing that I noticed is that the system that complains has a VM Version of 10, which means that the fat client won't edit its settings at all, whereas the other is on version 9, and snooping on that one was where I saw the different backing type, so the backing type difference may be a red herring.

Re: PowerCLI Set-CDDrive cmdlet gives strange error

william_faulk — Fri, 24 Oct 2014 21:54:59 GMT

Actually, I just found that I have others that have CDs on IDE1:0 that don't exhibit this problem. So I did a network snoop (via Wireshark and its SSL decrypter) to compare, and I found that the SOAP request being made to my vCenter server was identical other than the content of /soap:Envelope/soap:Body/ReconfigVM_Task/_this[@type='VirtualMachine'] (pseudo-XPath notation), which was vm-757 vs. vm-723. (I determined this by running each SOAP request through xmllint --format and running those results through diff. That one line was literally the only difference.)

The rest of the SOAP requests were incidental or requesting status on the task.

This would imply that there's something in vCenter and/or ESXi that is causing that error and that PowerCLI is just reporting the error. Of course, why it doesn't happen when the same task is requested via the Web Client is strange. Maybe I'll try and capture that data, too, and see what it's doing differently.

Re: SOAP error with VMware-vSphere-Perl-SDK-5.5.0

william_faulk — Thu, 23 Oct 2014 23:17:59 GMT

The problem is that the VMware-provided module is forcing you to use an antiquated Perl SSL module. You can fix the VMware stuff, which may or may not be easier to live with. A diff to VICommon.pm is attached.

Re: PowerCLI Set-CDDrive cmdlet gives strange error

william_faulk — Wed, 22 Oct 2014 21:09:22 GMT

I'm also having this problem. My command is as simple as:

Get-VM -Name vmname | Get-CDDrive | Set-CDDrive -NoMedia

The command performs the correct action — setting the drive to be disconnected and using the "Client Device", but produces the reported error.

Set-CDDrive : 10/22/2014 4:48:53 PM Set-CDDrive The operation for the entity VirtualMachine-vm-723 failed with the following message: "Device 'ide1:0' already exists."

At line:1 char:35

+ Get-VM | Get-CDDrive | Set-CDDrive <<<

+ CategoryInfo : NotSpecified: (:) [Set-CDDrive], GenericVmConfigFault

+ FullyQualifiedErrorId :

Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetCDDrive

It only does this on hosts where the CD drive is on IDE1:0. Most of my VMs are set up with the CD drive being on IDE0:0, but I have a few where they are on IDE1:0, probably due to an initial, but corrected, config error (I'm guessing a hard drive that was initially misconfigured to be IDE or maybe an accidental second CD drive) that got replicated through a template.

Point being, try creating a VM with a CD drive on IDE1:0 and nothing on IDE0:0 (or any other IDE bus) and see if you can reproduce.