This is a quick note as a pointer to anyone running into type errors like error TS2582. You might be working with Jest, TypeScript, and a monorepo setup, using something like lerna. I was porting over some projects into a monorepo and had a tsconfig.json issue which was cause for this error. You might be seeing errors similar to: error TS2582: Cannot find name 'test'. Do you need to install type definitions for a test runner? Try npm i --save-dev @types/jest or npm i --save-dev @types/mocha.
As it turns out, my issue was that I had a tsconfig.json file with typeRoots configured to point to the package’s own node_modules directory. Like this:
As this was a monorepo, common types such as those from jest were installed in the repository root. Meaning a package tsconfig.json file under package/example-package, referencing the location of “./node_modules/@types” was incorrect.
The fix was to simply remove the typeRoots setting from the package, or change it to point a further level down to the root: “../../node_modules/@types“.
To quote the docs on typeRoots, if you explicitly set typeRoots, then you’re narrowing down the locations that these will be pulled in from (compared to the default of not setting them).
By default all visible ”@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.
Bit of a strange one this – I have not dug deeper to find the root cause, but here is a quick fix for anyone with the issue.
I found we could not open VM console sessions in a vCenter 5.5 environment today. Usually one’s first thought is that it is a DNS or port issue when you see the classic MKS console error in a VM, but in this case I knew that DNS and ports were not an issue, as RDPing direct to the vCenter Server itself, logging in with the C# client and opening VM consoles from there were giving the exact same message. This was the case for the web client as well as the C# client.
The issue was either with the host that VMs were running on, or with the VMs themselves – the simple fix:
vMotion the VM to another host. As soon as this was done, I could open the console session. The underlying issue is still out there, but I have not had the time to dig any deeper to find out the root cause. More discussion and info available from this VMware communities thread: https://communities.vmware.com/thread/450294
I have been working on setting up a small cluster of Hyper-V Hosts (running as VMs), nested under a bunch of physical VMware ESXi 5.0 hosts. Bear in mind I am quite new to Hyper-V, I have only ever really played with single host Hyper-V setups in the past. Having just finishing creating a Hyper-V failover cluster in this nested environment, and configuring CSV (Cluster Shared Volume) Storage for the Hyper-V hosts, I created a single VM to test the “live migrate” feature of Hyper-V. Upon telling the VM to live migrate from host “A” to host “B”, I got the following error message.
“There was an error checking for virtual machine compatibility on the target node”. The description reads “The virtual machine is using processor-specific features not supported on physical computer “DEVHYP02E”.
So my first thought was, perhaps there is a way to mask processor features, similar to the way VMware’s EVC for host physical CPU compatibility works? If you read the rest of the error message it does seem to indicate that there is a way of modifying the VM to limit processor features used.
So the solution in this case is to:
First of all power down your VM
Using Hyper-V Manager, right-click the VM and select “Settings”
Go to the “Processor” section and tick the option on for “Migrate to a physical computer with a different processor version” under “Processor compatibility”
Power up the VM again
So now if you try and live migrate to another compatible Hyper-V host, the migration should work.
Trying to apply a Host profile created from another Host in a cluster today I got an error message which resulted in only some of the host profile actually being applied.
A specifed parameter was not correct. changedValue.key
I thought that the error message looked familiar, but couldn’t quite remember at the time, so I left what I was doing to take a look at again later. On my way home this evening I had a bit of a brainwave – the ESX host I had taken the original profile from was a slightly different update level (2) as opposed to the update level of the newer host I was applying the profile to. I also remembered where I had seen the text “changedValue.key” in the error message before – changing Advanced Settings on a Host using PowerCLI! This gave me a good idea as to where to look for the issue I was having with this Host Profile – the Advanced Settings in the Host Profile.
I knew it was probably to do with a value that was different between hosts because of their differing update levels, but to gather more information I decided to hit the log files to find out more… Opening up /var/log/vmware/hostd.log on the Host and navigating down to the time I tried to apply the Host Profile I found this (interesting bit in the screenshot below, full log text in the section after that):
[2012-02-20 19:50:07.849 F66966D0 info 'TaskManager'] Task Created : haTask-ha-host-vim.option.OptionManager.updateValues-896
[2012-02-20 19:50:07.853 F66966D0 verbose 'VersionOptionProvider'] Attempt to set readonly option
[2012-02-20 19:50:07.853 F66966D0 info 'App'] AdapterServer caught exception: vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'TaskManager'] Task Completed : haTask-ha-host-vim.option.OptionManager.updateValues-896 Status error
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Activation [N5Vmomi10ActivationE:0x5cf27a98] : Invoke done [updateValues] on [vim.option.OptionManager:ha-adv-options]
[2012-02-20 19:50:07.853 F66966D0 verbose 'Vmomi'] Arg changedValue:
dynamicType = <unset>,
key = "Misc.HostAgentUpdateLevel",
value = "2",
dynamicType = <unset>,
key = "Misc.HostAgentUpdateLevel",
value = "2",
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Throw vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Result:
dynamicType = <unset>,
faultCause = (vmodl.MethodFault) null,
invalidProperty = "changedValue.key",
msg = "",
So we can see that the Host Profile did a “change value” (changedValue) on the key “Misc.HostAgentUpdateLevel” and this is where our error was thrown with an “invalidProperty” (changedValue.key). If we google the message “vmodl.fault.InvalidArgument” we’ll arrive at the VMware SDK Reference Guide which states that “An InvalidArgument exception is thrown if the set of arguments passed to the function is not specified correctly.” In this case we’ll soon see that this is happening because the value that is trying to be changed is actually a read-only value for the Host – as it should be, as it just references the update level of the host – this wouldn’t normally be something you want to change.
The issue here was of course that original host off which the profile was based is update 2, whereas the new host having the profile applied is update 4. The two settings differ, therefore Host Profiles tries to change this value on the new Host. The setting is really read-only, therefore Host Profiles fails to apply the value and throws this error message at us, which also results in the rest of our host profile (annoyingly) not being applied. Ideally if Host Profiles found a read-only value that shouldn’t be changed, it would not change this value.
So the simple solution is to either:
Take a Host Profile from a Host with the settings you need which is on the same update level as the Hosts you will be applying this profile to.
Modify this Host Profile (edit) and remove the Advanced Setting for “Misc.HostAgentUpdateLevel“.
In my case, I was testing the host profile on a clean ESX Host before using it for other Hosts – that meant I also only had one new ESX host of this particular update level and therefore couldn’t use the first option (take the profile from an existing host). So I therefore just went to Home -> Host Profiles and edited this Host Profile to get rid of the unnecessary key called “Misc.HostAgentUpdateLevel” like so:
After removing the entries referring to this read-only key, I simply re-applied the profile and this time around all the settings went on as expected and there was no more error message. So to sum it all up, check that you aren’t first of all taking a Host Profile from a reference host of a different update level as your target hosts (and if you have to you can then resort to manually editing your profile as I did). If you get cryptic errors applying your Host Profiles, check your Host log files for more info and clues as to where the issue may lie.
Today I was creating an upgrade baseline for some old ESX 4.x hosts to be patched up to a newer update level. I ran into an error whilst uploading an ESX ISO with the new update version and subsequently found myself troubleshooting the issue. I thought I would do a quick post on general things to check when troubleshooting VMware Update Manager.
First of all check you are of course uploading the correct file / ISO! Note that ESX upgrade baselines work with ISO files and ESXi deal with .zip files. Ensure you are using the correct file and build of ESX or ESXi depending on which you are planning on using.
Consult the log files! Logs are kept in different locations depending on your OS that VUM is running on.
Windows XP, 2000, and 2003 – C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Logs
Windows Server 2008 and above – C:\ProgramData\VMware\VMware Update Manager\Logs\
ESX update manager logs are kept in – /var/log/vmware/esxupdate.log
use cat /var/log/vmware/esxupdate.log | more to view the log file in ESX from the shell / PuTTy SSH session.
The log file in Windows should be named something similar to “vmware-vum-server-log4cpp.log”
You should be able to locate an issue that has occurred by noting the time the issue happened in Update Manager. Open up the relevant log file and navigate down to the time it happened in your logs. Hopefully the description / entry will point you in the right direction.
In my case today, I was trying to upload an ESX 4.0 Update 4 ISO (Complete) to create a new Upgrade Baseline for some older ESX 4.0 hosts. I got an error after uploading the ISO using the new baseline upgrade wizard. See below:
Although the message above in the GUI is not very descriptive, after looking at the log files on the Update Manager server I found an entry which explained what my problem was:
The problem was that my ISO file was corrupt – the download had seemed to complete just fine when downloading from vmware.com, but there must have been an issue. A quick check of the ISO using my md5sum command line utility in Windows confirmed that the MD5 hash for this ISO file did not match the MD5 hash listed for the ISO on vmware.com (as pointed out in the log files above).
I downloaded a fresh copy of the ISO, checked the MD5 again to ensure it matched this time, and re-uploaded to create a new baseline. Everything worked as expected this time around.