same here:
random BSOD (NTFS_FILE_SYSTEM 0x00000024 - nfts.sys ) after quiesced snapshot (Symantec Netbackup)...
Win Server 2008 R2
VM tools: 9.4.11 build 2400950
Paravirtual SCSI
Host: 5.5.0 2403361
same here:
random BSOD (NTFS_FILE_SYSTEM 0x00000024 - nfts.sys ) after quiesced snapshot (Symantec Netbackup)...
Win Server 2008 R2
VM tools: 9.4.11 build 2400950
Paravirtual SCSI
Host: 5.5.0 2403361
In order to improve performance with the application servers, you need to better understand what the actual bottleneck is during the huge data execution. You have stated memory and CPU look OK, next you should look at the network usage as well as the datastore I/O and latency metrics at the time of the performance issue. These metrics are available in vCenter. I am assuming you have already verified the database metrics are OK.
Also, what network adapter type are the VMs configured with? VMXNET3?
Have you read the XenApp on VMware best practice guide? There are answers to some of your questions in it.
Hi,
Yes, network adaptor is VMXNET3
Using prefixes in vcenter like tsmon.vmname.blalalala or tsmoff.vmname.blalala can be used in powercli and you can trigger TSM backups of those specific VMs using that system. We do use that system for our secondary backup solution and it works quite well.
I will however warn you that TSM backup for vmware is very particular that you have VSS installe din vmware tools, and otherwise you risk TSM "shooting" down your VMs without warning every night.
Our TSM team consisting of 3 people managing 4000 VMs did not find it to be a viable solution, and even though we had it for 5 years, the total managment cost was to high when combined with the issues we experienced. However it might be that it is suitable for your infrastructure, but then have in mind my warnings so you dont have to search for the "unknown" cause of crashes like we had to
> and VMX should be read only when powered on.
That assumption is incorrect. Parameters that are changed via the UI can be applied on the fly - depends on the parameter.
Easy example: changing the iso for a CDrom - this can be altered while the VM is running.
Other parameters like the amount of RAM can be altered on the fly for some guestOS.
Other parameters like guestOS need a poweroff.
As far as I know there are 3 types of parameters:
- can be changed on the fly for all guestOS
- can be changed on the fly for some guestOS and some virtual hardware versions only
- always need a poweroff
Hello,
Is there a report or view that can show the model of NICs our guests are using? I've upgraded many from E1000 to the VMXNET3, but would like a fresh view.
Thanks
thanks! I'll make sure to let everyone know that!
Here is some error i had these days
The Microsoft Exchange Replication service VSS Writer (Instance 00000000-0000-0000-0000-000000000000) failed with error 8007064A when processing the backup completion event.
The Microsoft Exchange VSS Writer (Instance 2a82147b-f63e-4c0f-bdb6-f67988fb1123) failed when processing the post-snapshot event.
Writer Microsoft Exchange Writer experienced some error during snapshot creation. More info: .
A VSS writer has rejected an event with error 0x00000000, The operation completed successfully.
. Changes that the writer made to the writer components while handling the event will not be available to the requester. Check the event log for related events from the application hosting the VSS writer.
Operation:
PrepareForBackup event
Context:
Execution Context: Writer
Writer Class Id: {7e47b561-971a-46e6-96b9-696eeaa53b2a}
Writer Name: MSMQ Writer (MSMQ)
Writer Instance Name: MSMQ Writer (MSMQ)
Writer Instance ID: {ba43e868-6174-4d26-9935-22b7e7835eef}
Command Line: C:\Windows\system32\mqsvc.exe
Process ID: 1628
Do you see any NTFS and VSS related error messages in the systemlogfs of the guests ?
In the VEEAM Knowledgebase there is a nice article that walks through a detailed VSS troubleshooting - I highly recommend to verify the correct function of VSS inside the guests - especially if the guest will be automatically backed up and runs a database or acts as a fileserver.
Hi,
I'm having trouble with my Windows 10 Technical preview instance and I was thinking if you could help me. All help is very much appreciated.
Host: HP BL460c (intel)
Esxi 5.5
Guest OS: Windows 10 Technical Preview Build 10061
VM version 10
2 CPU's, 8gb memory
When the Guest OS has been powered on AND nobody has used it for exactly 24 hours it crashes. So I revert it from a snapshot and after 24 hours it goes down. If I look at the events in vCenter I can see: "VMware ESX unrecoverable error: (vcpu-0) NOT_REACHED bora/devices/ahci/ahci_user.c:1521" I know it is not a supported Windows version but I was hoping someone might know what this error means and maybe point me to the right direction. All previous windows 10 builds have worked perfectly and from the Windows logs it seems just like someone suddenly pulled the power cord so no luck there.
From the log just before the crash:
2015-04-27T08:17:05.726Z| vcpu-0| I120: NOT_REACHED bora/devices/ahci/ahci_user.c:1521
2015-04-27T08:17:10.375Z| vcpu-0| W110: A core file is available in "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmx-zdump.001"
2015-04-27T08:17:10.375Z| vcpu-0| W110: Writing monitor corefile "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmmcores.gz"
2015-04-27T08:17:10.610Z| vcpu-0| I120: Counting amount of anonymous memory
2015-04-27T08:17:10.628Z| vcpu-0| I120: Total Count of Anon Pages and CR3 pages 8924
2015-04-27T08:17:10.635Z| vcpu-0| W110: Dumping core for vcpu-0
2015-04-27T08:17:10.635Z| vcpu-0| I120: CoreDump: dumping core with superuser privileges
2015-04-27T08:17:10.635Z| vcpu-0| I120: VMK Stack for vcpu 0 is at 0x4123a0c55000
2015-04-27T08:17:10.635Z| vcpu-0| I120: Beginning monitor coredump
2015-04-27T08:17:11.947Z| vcpu-0| I120: End monitor coredump
2015-04-27T08:17:11.948Z| vcpu-0| W110: Dumping core for vcpu-1
2015-04-27T08:17:11.948Z| vcpu-0| I120: CoreDump: dumping core with superuser privileges
2015-04-27T08:17:11.948Z| vcpu-0| I120: VMK Stack for vcpu 1 is at 0x4123a0cd5000
2015-04-27T08:17:11.948Z| vcpu-0| I120: Beginning monitor coredump
2015-04-27T08:17:12.828Z| vcpu-0| I120: End monitor coredump
2015-04-27T08:17:12.829Z| vcpu-0| W110: Dumping extended monitor data
2015-04-27T08:17:16.162Z| vcpu-0| I120: CoreDump: ei->size 53374976 : len = 53374976
2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace:
2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace[0] 000003fffe592190 rip=00000000237be60e rbx=00000000237bdde0 rbp=000003fffe5921b0 r12=0000000000000000 r13=000003fffdb29100 r14=0000000000000000
r15=00000000325d1700
2015-04-27T08:17:16.177Z| vcpu-0| I120: Backtrace[1] 000003fffe5921c0 rip=00000000231e6805 rbx=00000000241bf148 rbp=000003fffe5926b0 r12=0000000000000001 r13=000003fffdb29100 r14=0000000000000000
r15=00000000325d1700
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[2] 000003fffe5926c0 rip=00000000234ef288 rbx=000003fffdb27930 rbp=000003fffe5926e0 r12=00000000325d3078 r13=000003fffdb29100 r14=0000000000000000 r15=00000000325d1700
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[3] 000003fffe5926f0 rip=00000000234efcdc rbx=000003fffdb27930 rbp=000003fffe592c60 r12=000004001a59f480 r13=000003fffdb29100 r14=0000000000000000 r15=00000000325d1700
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[4] 000003fffe592c70 rip=0000000023387950 rbx=00000000325d1700 rbp=000003fffe592ce0 r12=0000000000000000 r13=000000000000017a r14=000003fffdb2e100
r15=00000000323b8a30
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[5] 000003fffe592cf0 rip=0000000023536b9d rbx=00000000243083e0 rbp=000003fffe592d20 r12=0000000024063c00 r13=000000000000017a r14=000003fffdb2e100
r15=00000000323b8a30
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[6] 000003fffe592d30 rip=0000000023568b3e rbx=0000000000000000 rbp=000003fffe592d70 r12=000000000000012d r13=00000000241bf148 r14=00000000243032e0
r15=0000000024183080
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[7] 000003fffe592d80 rip=0000000023536ca9 rbx=00000000241cb3a8 rbp=000003fffe592d80 r12=0000000032383cb0 r13=0000000000000000 r14=0000000000000000
r15=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[8] 000003fffe592d90 rip=00000000232c8ad8 rbx=00000000241cb3a8 rbp=000003fffe592ec0 r12=0000000032383cb0 r13=0000000000000000 r14=0000000000000000
r15=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[9] 000003fffe592ed0 rip=00000000243b7ddc rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000
r15=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[10] 000003fffe592fe0 rip=0000000024a041cd rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000
r15=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: Backtrace[11] 000003fffe592fe8 rip=0000000000000000 rbx=0000000000000000 rbp=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000
r15=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[0] 000003fffe592190 rip=00000000237be60e in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[1] 000003fffe5921c0 rip=00000000231e6805 in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[2] 000003fffe5926c0 rip=00000000234ef288 in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[3] 000003fffe5926f0 rip=00000000234efcdc in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[4] 000003fffe592c70 rip=0000000023387950 in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[5] 000003fffe592cf0 rip=0000000023536b9d in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[6] 000003fffe592d30 rip=0000000023568b3e in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[7] 000003fffe592d80 rip=0000000023536ca9 in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[8] 000003fffe592d90 rip=00000000232c8ad8 in function (null) in object /bin/vmx loaded at 0000000023071000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[9] 000003fffe592ed0 rip=00000000243b7ddc in function (null) in object /lib64/libpthread.so.0 loaded at 00000000243b0000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[10] 000003fffe592fe0 rip=0000000024a041cd in function clone in object /lib64/libc.so.6 loaded at 0000000024931000
2015-04-27T08:17:16.178Z| vcpu-0| I120: SymBacktrace[11] 000003fffe592fe8 rip=0000000000000000
2015-04-27T08:17:16.178Z| vcpu-0| I120: Msg_Post: Error
2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-0)
2015-04-27T08:17:16.178Z| vcpu-0| I120+ NOT_REACHED bora/devices/ahci/ahci_user.c:1521
2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/543d0569-8bfc70dd-5584-0017a4770408/WINDOWS 10/vmware.log".
2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.requestSupport.withoutLog] You can request support.
2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.requestSupport.vmSupport.vmx86]
2015-04-27T08:17:16.178Z| vcpu-0| I120+ To collect data to submit to VMware technical support, run "vm-support".
2015-04-27T08:17:16.178Z| vcpu-0| I120: [msg.panic.response] We will respond on the basis of your support entitlement.
2015-04-27T08:17:16.178Z| vcpu-0| I120: ----------------------------------------
2015-04-27T08:17:16.188Z| vcpu-0| I120: Exiting
Have you experienced something similar or can you tell what seems to be the issue? Thank you very much for your help!
I would highly recommend to study this http://kb.vmware.com/kb/1007696
Also check the Knowledgebase of the vendor of your automatic backup software.
I do not know of any report or view from with vCenter, but I use this little powershell script:
Function Get-NicType {
$VM = Get-Cluster -Name <Your Cluster Name> | Get-VM
foreach ($VMS in $VM) {
$Nettype = Get-NetworkAdapter -VM $VMS
foreach ($nic in $Nettype) {
"{0} {1} {2}" -f $VMS.Name, $nic.Name, $nic.Type
}
}
}
Actually the easiest way to transfer a VM between hosts that arent in the same cluster/datacenter is to just enable SSH on the hosts and copy it. You can do this from the command line with something like SCP or you can download something like WinSCP and use a gui to accomplish that.
Good luck!
I'm having intermittent connection issues with a VM. During troubleshooting, I noticed that when I go to edit the VM from the VSphere Client, the hard drives show "inconsistent" (see attached).
Does this mean the image is corrupt? I tried cloning the machine, and the clone shows the same "inconsistent".
It boots and reboots fine.
Please post the current vmx-file and check if the referenced vmdk-files are present.
If they are - post them as well - to do so use WinSCP - that can not be done with the Datastorebrowser
I can see the vmx file in the datastore, but it fails to download. I can download other vmx files on other VM's in that datastore.
I've tried both web client and the stand alone client.
Did you already take a look at RVTools which is an excellent freeware tool to get an overview of the environment?
André
Hi
I'm planning on migrating a number of servers between 2 clusters under the same datacenter. At present the two clusters don't have access to the same network adaptor so vMotion is not possible, that's fine and will be resolved shortly. However I'm getting another error message though which reads as follows:
The virtual machine requires hardware features that are unsupported or disabled on the target host:
*general incompatibilities
If possible use a cluster with Enhanced vMotion Compatibility (EVC) enabled; see KB article 1003212.
CPUID details: incompatibility at level 0x1 register 'ecx'
Host bits: 0110:0010:1001:1000:0010:0010:0000:0011
Required: x0xx:x01x:1001:10xx:xxxx:xx1x:xxxx:x011
I'm assuming that this is because the CPUs in the hosts are slightly different between the two clusters, all hosts in both clusters are IBM HS23 blades but...
cluster 1 - Inter(R) Xeon(R) CPU E5-26700 @ 2.60GHz
cluster 2 - Inter(R) Xeon(R) CPU E5-2650v2 @ 2.60GHz
Can someone please advise if there is anything I can do to get rid of this error, if I power off the VMs first I can migrate them and they will function with no issue however I would really like to avoid system downtime if possible.
I'm assuming that the solution may involve EVC (this is currently disabled on both clusters) however I'd like some confidence that enabling this won't cause any connection issues etc.
Thanks
You still are limited to one etherchannel per host.
in all of my clusters we setup at least three vSwitches with two NICs connected to Cisco equipment with all of the ports set to trunks with specific allowed vlans.
for example, our management vSwitch has two vincs assigned to it (nic1 and nic2). Those are linked to Cisco switches with each port set to trunk (802.1q). We then specify that only our mgmt VLAN is allowed. We set the native to 999 and don't allow it on the port (prevent hopping out of vlans). we then let ESXi pick which nic to use.
We stopped using LACP and ether channels in 5.0. It simply was too much trouble and not worth the added complexity. We instead just hand ESXi multiple single member uplinks and let ESXi load balance now. It's far easier to maintain and add new hosts.
Hi,
i am not using any vma. using windows machine with power cli installed on this machine.
and connect the vcenter to access all my vm to shutdown using the following command
get-vm | Shutdown-VMGuest -Confirm:$false
is there any way i can pass the reason for the shutdown with the above commend
Regards,
Subbu