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 use '&' to start four pktcap-uw on ESXi 5.5, is a better way?

pktcap-uw --uplink vmnic6 --ip 132.97.120.19   -o /vmfs/volumes/172.31.4.83-LocalDisk/83-6-in.pcap -P & pktcap-uw --uplink vmnic6 --ip 132.97.120.19   -o /vmfs/volumes/172.31.4.83-LocalDisk/83-6-out.pcap -P --dir 1 & pktcap-uw --uplink vmnic4 --ip 132.97.120.19   -o /vmfs/volumes/172.31.4.83-LocalDisk/83-4-in.pcap -P & pktcap-uw --uplink vmnic4 --ip 132.97.120.19   -o /vmfs/volumes/172.31.4.83-LocalDisk/83-4-out.pcap -P --dir 1 &

The packet capture by pktcap-uw has no time info? It show me 1970-01-01 00:46:31.839233.

The command is:

pktcap-uw --uplink vmnic6 --ip 132.97.120.19   -o /vmfs/volumes/172.31.4.83-LocalDisk/83-6-in.pcap -P

Hi Guys,

These posts where written a while ago and was wondering if anything came about:

https://blogs.vmware.com/vsphere/2011/11/vapp-startup-order-and-ha.html

HA Futures: Restart Order

Basically, is there a granular mechanism available (I cant find anything) to restart VMs in a vMSC setup, where an actual disaster occurs... i.e. all VMs reboot to the other site. Priority orders are okay, but not really enough when dealing with Multi Tier Apps that are quite sensitive on dependent servers being up and available before another servers service will kick in?

How do you guys that have a vMSC implementations deal with this kind of thing? On previous implementations for me, I never had this problem, but imagined one day I would... and now I do!!

Hello community,

I have an issue with an ESXi 5.5.0, ramdisk root partition is full

My problem is that i don't know how to clean it to make some available space, it seems logs folder doesnt consume that much space as everything is in /scratch and /scratch is linked to /vmfs

~ # du -hs /var/*

4.0K    /var/core

476.0K    /var/db

35.7M    /var/lib

8.0K    /var/lock

240.0K    /var/log

4.0K    /var/opt

848.0K    /var/run

16.0K    /var/spool

4.0K    /var/tmp

~ # ls -lh /var/log/

total 224

lrwxrwxrwx    1 root     root          21 Aug  3  2015 Xorg.log -> /scratch/log/Xorg.log

-rw-r--r--    1 root     root           0 Feb  2 12:22 arcconf.log

lrwxrwxrwx    1 root     root          21 Aug  3  2015 auth.log -> /scratch/log/auth.log

-rw-rw-rw-    1 root     root       50.8K Aug  3  2015 boot.gz

lrwxrwxrwx    1 root     root          22 Aug  3  2015 clomd.log -> /scratch/log/clomd.log

-rw-r--r--    1 root     root       20.5K Dec 11 20:35 configRP.log

lrwxrwxrwx    1 root     root          25 Aug  3  2015 dhclient.log -> /scratch/log/dhclient.log

-rw-r--r--    1 root     root           0 Feb  2 12:19 esxcli.log

lrwxrwxrwx    1 root     root          26 Aug  3  2015 esxupdate.log -> /scratch/log/esxupdate.log

lrwxrwxrwx    1 root     root          20 Aug  3  2015 fdm.log -> /scratch/log/fdm.log

lrwxrwxrwx    1 root     root          28 Aug  3  2015 hostd-probe.log -> /scratch/log/hostd-probe.log

lrwxrwxrwx    1 root     root          22 Aug  3  2015 hostd.log -> /scratch/log/hostd.log

lrwxrwxrwx    1 root     root          33 Aug  3  2015 hostprofiletrace.log -> /scratch/log/hostprofiletrace.log

drwxr-xr-x    1 root     root         512 Aug  3  2015 ipmi

lrwxrwxrwx    1 root     root          21 Aug  3  2015 lacp.log -> /scratch/log/lacp.log

lrwxrwxrwx    1 root     root          22 Aug  3  2015 osfsd.log -> /scratch/log/osfsd.log

lrwxrwxrwx    1 root     root          27 Aug  3  2015 rhttpproxy.log -> /scratch/log/rhttpproxy.log

lrwxrwxrwx    1 root     root          29 Aug  3  2015 sdrsinjector.log -> /scratch/log/sdrsinjector.log

lrwxrwxrwx    1 root     root          22 Aug  3  2015 shell.log -> /scratch/log/shell.log

-rw-------    1 root     root        4.4K Aug  3  2015 smbios.bin

lrwxrwxrwx    1 root     root          26 Aug  3  2015 storagerm.log -> /scratch/log/storagerm.log

lrwxrwxrwx    1 root     root          25 Aug  3  2015 swapobjd.log -> /scratch/log/swapobjd.log

-rw-------    1 root     root        4.6K Aug  3  2015 sysboot.log

lrwxrwxrwx    1 root     root          23 Aug  3  2015 syslog.log -> /scratch/log/syslog.log

lrwxrwxrwx    1 root     root          20 Aug  3  2015 usb.log -> /scratch/log/usb.log

lrwxrwxrwx    1 root     root          24 Aug  3  2015 vmamqpd.log -> /scratch/log/vmamqpd.log

lrwxrwxrwx    1 root     root          24 Aug  3  2015 vmauthd.log -> /scratch/log/vmauthd.log

lrwxrwxrwx    1 root     root          26 Aug  3  2015 vmkdevmgr.log -> /scratch/log/vmkdevmgr.log

lrwxrwxrwx    1 root     root          25 Aug  3  2015 vmkernel.log -> /scratch/log/vmkernel.log

lrwxrwxrwx    1 root     root          26 Aug  3  2015 vmkeventd.log -> /scratch/log/vmkeventd.log

lrwxrwxrwx    1 root     root          27 Aug  3  2015 vmksummary.log -> /scratch/log/vmksummary.log

lrwxrwxrwx    1 root     root          27 Aug  3  2015 vmkwarning.log -> /scratch/log/vmkwarning.log

drwxr-xr-x    1 root     root         512 Aug  3  2015 vmware

lrwxrwxrwx    1 root     root          21 Aug  3  2015 vobd.log -> /scratch/log/vobd.log

lrwxrwxrwx    1 root     root          23 Aug  3  2015 vprobe.log -> /scratch/log/vprobe.log

lrwxrwxrwx    1 root     root          24 Aug  3  2015 vprobed.log -> /scratch/log/vprobed.log

lrwxrwxrwx    1 root     root          21 Aug  3  2015 vpxa.log -> /scratch/log/vpxa.log

lrwxrwxrwx    1 root     root          19 Aug  3  2015 vsantraces -> /scratch/vsantraces

lrwxrwxrwx    1 root     root          24 Aug  3  2015 vsanvpd.log -> /scratch/log/vsanvpd.log

~ # ls -l /

total 529

lrwxrwxrwx    1 root     root            49 Aug  3  2015 altbootbank -> /vmfs/volumes/68867271-7c68f435-692d-c33e2403945c

drwxr-xr-x    1 root     root           512 Aug  3  2015 bin

lrwxrwxrwx    1 root     root            49 Aug  3  2015 bootbank -> /vmfs/volumes/dd2ebb77-30fe0cd0-acb9-14d71bf68873

-r--r--r--    1 root     root        300058 Feb 22  2014 bootpart.gz

drwxr-xr-x    1 root     root           512 Feb  3 10:57 dev

drwxr-xr-x    1 root     root           512 Jan 13 17:39 etc

drwxr-xr-x    1 root     root           512 Aug  3  2015 lib

drwxr-xr-x    1 root     root           512 Aug  3  2015 lib64

-r-x------    1 root     root         17615 Aug  3  2015 local.tgz

lrwxrwxrwx    1 root     root             6 Aug  3  2015 locker -> /store

drwxr-xr-x    1 root     root           512 Aug  3  2015 mbr

drwxr-xr-x    1 root     root           512 Aug  3  2015 opt

drwxr-xr-x    1 root     root        131072 Feb  3 10:57 proc

lrwxrwxrwx    1 root     root            22 Aug  3  2015 productLocker -> /locker/packages/5.5.0

lrwxrwxrwx    1 root     root             4 Feb 22  2014 sbin -> /bin

lrwxrwxrwx    1 root     root            49 Aug  3  2015 scratch -> /vmfs/volumes/559a8840-bef1f5b0-63c4-44a84225154e

lrwxrwxrwx    1 root     root            49 Aug  3  2015 store -> /vmfs/volumes/559a8823-5d176df8-004a-44a84225154e

drwxr-xr-x    1 root     root           512 Aug  3  2015 tardisks

drwxr-xr-x    1 root     root           512 Aug  3  2015 tardisks.noauto

drwxrwxrwt    1 root     root           512 Feb  3 10:01 tmp

drwxr-xr-x    1 root     root           512 Aug  3  2015 usr

drwxr-xr-x    1 root     root           512 Aug  3  2015 var

drwxr-xr-x    1 root     root           512 Aug  3  2015 vmfs

drwxr-xr-x    1 root     root           512 Aug  3  2015 vmimages

lrwxrwxrwx    1 root     root            17 Feb 22  2014 vmupgrade -> /locker/vmupgrade

any help on solving this issue would be really appreciated

thanks

G

Hi,

We have recently built EXSi 5.5 build-3248547 and plan to map in existing VCenter 5.5.0, 1476327 but it fails

I believe EXSi and Vcenter must in same version correct me if iam wrong

Let me know without upgrading my Vcenter how to add the EXSi host.

Regards,

Venkat

Hi.

I have two vCenters:

vCenter1, v5.5

HostA, v5.1

HostB, v5.1

vCenter2, v6.0

I want to migrate the hosts from vCenter1 to vCenter2. I assume I should add the license same keys to the new vCenter and then run the usual host migration process. But I want to check what happens to the host and VMs during the short time between vCenters as I assume the host loses its license.

I obviously want to ensure operations continue uninterrupted.

Thanks

I have virtualized version routerOS 6.29 license level 6 over ESXI 5.5 but not work function bridge

thanks.

We are trying to run Vsphere HA and have our domain controller in fault tolerant mode. The DC has 1 vcpu, 8 gb of ram and no CPU reserve.

I am running ESXI 5.1 and have a domain controller that fails a live migration to change a host. I also have a windows 7 VM that live migrates just fine. The error stack states:

The Vm failed to resume on the destination during early power on

The virtual machine cannot be powered on

I have no clue where to look for this error. I do not think its a datastore or network issue as the windows 7 vm can migrate just fine. We have enough memory and CPU resources so we are not starved.

In the vmware.log on the DC that failed to power on, I did see a msg.checkpointPASizeMismatch : The virtual machine cannot be powered on

I googled this error and found a fix in 5.5.

Any help would be greatly appreciated.

Hi All,

Would the below be an APD/PDL condition? and if so, what should actually happen?

Environment:

- VMSC setup with 4 servers each site.

- ESXi 5.5

- I have set the values as per Duncans post on VMSC for the following:

1. VMkernel.Boot.terminateVMOnPDL = True
2. Das.maskCleanShutdownEnabled = True
3. Disk.AutoremoveOnPDL = 0

- Using 3Par as storage

- One Active LUN hosted of out Site 1 replicated to Site 2

- From Site 1 all VMs have their disks on the one Active LUN on Site 1

- Site 2 hosts just 1 VM and its disks are also on the one Active LUN in Site 1

- Site 2 VM talks to its disks therefore over  over the stretched FC connection between the sites (I know not the best thing to do but I am testing )

Now, when the stretched fabric between the 2 sites is physically disconnected the following is observed (Note the network between all hosts remains up):

- Site 2 ESXi hosts can longer see the one Active LUN in Site 1. Accepted.

- Site 1 ESXi hosts continue to see the one Active LUN in Site 1. Accepted.

- Site 1 VMs continue to run. They respond to ping. They respond to RDP and browsing through the file system of the VM. Accepted

- Site 2 VM though, confusingly, continues to responds to Ping. Accepts an RDP connection, but when trying to browse the file system just hangs. But I can still get to VM even though its of no use anymore as its disks have been pulled. Why is this happening? Shouldn't the VM be killed and restarted elsewhere?

I'm pretty sure I am seeing something that been addressed by restarting the VM in version 6 with an APD timeout value... But can this applied to 5.5 environments in the case where the preferred VM to Storage alignment is overidden

Hi,

I have run into a little trouble upgrading out vCenter server to the latest 5.5 Update 3B

For some reason it keeps failing when trying to install the components for the Vmware SSO

More specifically it seems to be failing on the Vmware JRE components.

I have attached the screenshot of the error plus the install logs.

I have looked through them and tried to fine an solution  myself but cannot seem to find anything related to the JRE components.

I have also tried to install them separately from vJRE folder on the dvd

The server is a Windows 2012 R2, and current vCenter is 5.5 RTM

Any help will be appreciated

hi,guys:

can anyone help me with this:

  I want to create a raid in esxi shell,my raid card is megaraid sas 2208 .Google tell me i can use the Megacli，but i can not  find the megacli version for esxi 5.5 in http://www.avagotech.com/ .

How can i do in this situation?

I am looking for a way to connect my cd/dvd(contians an iso) to virtualmachine which runs on esxi from esxi shell. vsphere client proivdes connect to cd/dvd option which i cannot do it because i have to run the command from esxi shell. i cannot use

I tried to google it but no use.Is there any command esxi provides which connects an cd/dvd to vm? or is there anyway to copy myfiles from esxi datastore to vm?

Informationen:
ESXi 5.5.0 Build 2403361

Situation:
Zur Situation wir haben mehrere ESXi-Hosts in zwei Standorte aufgeteilt. (Standort A und Standort B)
Auch unser Storage ist auf diesen zwei Standorten aufgeteilt.
Wir haben die LUNs/Datastores (naa.600…) per Fibre Channel angeschlossen.
Pro LUN haben wir vier Pfade. Zwei Pfade für den Standort A und zwei Pfade für den Standort B.
Der Standort der Pfade kann mittels der letzten zwei Zeichen, sprich der IO-Gruppe (blau markiert (bd/b9) oder im zweiten Bild rot umrandet), im Target ausgelesen werden:

Standort A: B9, A1, 9C
Standort B: BD, CB, C6

Beispiel:
Alle Storage-Pfade die B9, A1 oder 9C am Schluss des Targets haben sind im Standort A.
Alle Storage-Pfade die BC, CB oder C6 am Schluss des Targets haben sind im Standort B.

Anforderungen:
Bis anhin haben wir die Storage-Pfade per Round Robin (VMW_PSP_RR) angebunden.
Nun wollen wir durch Performance Probleme diese auf Fixed (VMW_PSP_FIXED) umschalten. Sprich die Storage-Pfade Policy umschalten.

Was wir bereits haben bzw. herausgefunden haben:
Mit folgender Befehl-Schleife können wir die Storage-Pfade Policy  aller LUNs auf Fixed (VMW_PSP_FIXED).

for i in `esxcli storage nmp device list | grep -B4 VMW_PSP_RR | grep ^naa.`

do

esxcli storage nmp device set --device $i --psp VMW_PSP_FIXED

done

Nur leider nimmt da der ESXi-Host der Pfad der ihm am besten passt und nicht immer den Pfad der am richtigen Standort ist.

Zudem wollen wir nicht das alle LUNs über den gleichen Pfad des Standortes verläuft. Darum wollen wir das in Fabric's einteilen (in 10ner Schritten, siehe Bild rechts):
Alle LUNs die mit nur einer Stelle, sprich LUN 1, 2, 3, usw. sind gerade.
Alle LUNs die zwei Stellen haben, sprich LUN 10, 11, 12, usw. muss nur auf die erste Stelle geachtet werden, 10, 11, 12 sind somit ungerade. Hingegen 20, 21, 22 sind gerade.
Alle LUNs die drei Stellen haben, sprich LUN 110, 112, 113, usw. sind ungerade. Hingegen LUN 101, 102, 103 gerade. (Bei drei Stellen soll nur auf die mittlere Ziffer geachtet werden.)

Informationen zum Skript:
Damit das Skript funktioniert muss es meiner Meinung nach zwei Skripte geben.
Eins für den Standort A (B9, A1, 9C) und eins für den Standort B (BD, CB, C6).

Beispiel: Alle LUNs für den Standort B anzeigen und auf einer Linie darstellen:

esxcli storage core path list | grep -A1 UID: | grep -A1 -E "bc-|cb-|c6-" | grep -v "^--" | sed 'N;s/\n/;/g'

Ausgabe des Beispiels:

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002f4;   Runtime Name: vmhba64:C0:T3:L16

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000328;   Runtime Name: vmhba64:C0:T3:L19

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000026f;   Runtime Name: vmhba64:C0:T3:L50

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000354;   Runtime Name: vmhba64:C0:T3:L54

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000357;   Runtime Name: vmhba64:C0:T3:L55

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000355;   Runtime Name: vmhba64:C0:T3:L56

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000356;   Runtime Name: vmhba64:C0:T3:L58

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000329;   Runtime Name: vmhba1:C0:T1:L21

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000295;   Runtime Name: vmhba1:C0:T1:L22

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002ce;   Runtime Name: vmhba1:C0:T1:L23

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002cd;   Runtime Name: vmhba1:C0:T1:L25

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002cc;   Runtime Name: vmhba1:C0:T1:L26

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002ca;   Runtime Name: vmhba1:C0:T1:L27

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002cb;   Runtime Name: vmhba1:C0:T1:L28

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000028a;   Runtime Name: vmhba1:C0:T1:L29

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000329;   Runtime Name: vmhba64:C0:T3:L21

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000295;   Runtime Name: vmhba64:C0:T3:L22

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002ce;   Runtime Name: vmhba64:C0:T3:L23

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002cd;   Runtime Name: vmhba64:C0:T3:L25

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002cc;   Runtime Name: vmhba64:C0:T3:L26

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002ca;   Runtime Name: vmhba64:C0:T3:L27

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002cb;   Runtime Name: vmhba64:C0:T3:L28

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000028a;   Runtime Name: vmhba64:C0:T3:L29

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000001cf;   Runtime Name: vmhba64:C0:T3:L2

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000001d0;   Runtime Name: vmhba64:C0:T3:L3

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000001f7;   Runtime Name: vmhba1:C0:T1:L30

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000020a;   Runtime Name: vmhba1:C0:T1:L31

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000258;   Runtime Name: vmhba1:C0:T1:L32

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000259;   Runtime Name: vmhba1:C0:T1:L33

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000266;   Runtime Name: vmhba1:C0:T1:L35

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000026b;   Runtime Name: vmhba1:C0:T1:L37

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000267;   Runtime Name: vmhba1:C0:T1:L38

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000333;   Runtime Name: vmhba1:C0:T1:L39

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000001f7;   Runtime Name: vmhba64:C0:T3:L30

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000020a;   Runtime Name: vmhba64:C0:T3:L31

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000258;   Runtime Name: vmhba64:C0:T3:L32

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000259;   Runtime Name: vmhba64:C0:T3:L33

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000266;   Runtime Name: vmhba64:C0:T3:L35

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000026b;   Runtime Name: vmhba64:C0:T3:L37

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000267;   Runtime Name: vmhba64:C0:T3:L38

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000333;   Runtime Name: vmhba64:C0:T3:L39

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000269;   Runtime Name: vmhba1:C0:T1:L40

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000026a;   Runtime Name: vmhba1:C0:T1:L41

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000334;   Runtime Name: vmhba1:C0:T1:L42

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000028b;   Runtime Name: vmhba1:C0:T1:L43

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000291;   Runtime Name: vmhba1:C0:T1:L44

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000292;   Runtime Name: vmhba1:C0:T1:L45

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000293;   Runtime Name: vmhba1:C0:T1:L46

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000294;   Runtime Name: vmhba1:C0:T1:L47

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002a0;   Runtime Name: vmhba1:C0:T1:L49

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000001cf;   Runtime Name: vmhba1:C0:T1:L2

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000001d0;   Runtime Name: vmhba1:C0:T1:L3

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000269;   Runtime Name: vmhba64:C0:T3:L40

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000026a;   Runtime Name: vmhba64:C0:T3:L41

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000334;   Runtime Name: vmhba64:C0:T3:L42

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de80000000000028b;   Runtime Name: vmhba64:C0:T3:L43

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000291;   Runtime Name: vmhba64:C0:T3:L44

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000292;   Runtime Name: vmhba64:C0:T3:L45

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000293;   Runtime Name: vmhba64:C0:T3:L46

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de800000000000294;   Runtime Name: vmhba64:C0:T3:L47

UID: fc.50060b0000c26a27:50060b0000c26a26-fc.500507680100e9cb:500507680140e9cb-naa.600507680180874de8000000000002a0;   Runtime Name: vmhba64:C0:T3:L49

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de8000000000002f4;   Runtime Name: vmhba1:C0:T1:L16

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000328;   Runtime Name: vmhba1:C0:T1:L19

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000026f;   Runtime Name: vmhba1:C0:T1:L50

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000354;   Runtime Name: vmhba1:C0:T1:L54

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000357;   Runtime Name: vmhba1:C0:T1:L55

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000355;   Runtime Name: vmhba1:C0:T1:L56

UID: fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de800000000000356;   Runtime Name: vmhba1:C0:T1:L58

Wenn man wie im obigen Befehl zwei Skripts (eines Pro Standort) erstellt bzw. danach filtert sind nur noch zwei Pfade pro LUN da.

Anforderungen an das Skript:

Das Skript müsste nun zwei Zahlen überprüfen können (gerade oder ungerade):

Die LUN-ID 32 ist ungerade da man sie zweistellig ist und so nur auf die 3 geachtet werden muss.

Nun muss noch das richtige Fabric ausgewählt werden. Sprich wenn die LUN-ID 32 ist muss der Pfad des Fabrics gewählt werden der ebenfalls ungerade ist. In diesem Fall:

Nun haben wir den richtigen Storage-Pfad, dieser müsste nun bevorzugt (preferred) werden.
Dies funktioniert mit folgendem Befehl:
esxcli nmp fixed setpreferred --device <naa_id> --path <storage-path>

Beispiel mit dem oberen Beispiel:
esxcli nmp fixed set preferred --device naa.600507680180874de800000000000258 --path fc.50060b0000c26a25:50060b0000c26a24-fc.500507680100e9cb:500507680130e9cb-naa.600507680180874de80000000000025

Nun alle diese Schritte sollten automatisch mit einem Skript gemacht werden (Ein Skript pro Standort). Könnt Ihr mir da helfen?

Ich bedanke mich für jede Bemühung und hoffe meine Beschreibung ist einigermassen verständlich.

Hi,

We have an IBM pureflex chasis with 5 compute nodes. This chassis has two brocade switches.

Each compute node have two NIC. NIC one is connected to switch one, and NIC 2 is connected to switch two.

Those brocade switches are connected witch CISCO core switches.

Cisco core switch port are configured as trunk port for vlan 1(native) and Vlan 4.

Brocade switch External ports (connected to cisco) are also configured as trunk ports.

Brocade switch internal ports (connected to compute node PNICs) are configured as trunk ports.

I have created two port groups.

1 - Default port group for native vlan.  ( 172.16.x.x/255.255.255.248)

2 - Vlan id 4 port group for vlan 4.       (172.16.230.1/255.255.255.0)

My all ESXi hosts management network is in Vlan 4. As of now I'm able to ping my both vlan VMs but unable to ping ESXi hosts.

Kindly help me to sort out it.

After upgrading my vCenter and hosts from 5.5U2 to 5.5 U3, i noticed that browsing some datastore folder was slower than before.

I have 2 ESX hosts and 1 SAN (ISCSI).

When i browse a VM folder executing in ESX-2 it work like before but when i browse a VM folder executing on ESX-1 i have to wait 10-15 sec before file display.

If i disconnect ESX-2, i can normally browse VM folder on ESX-1.

If i stop a VM on ESX-1, i can normally browse this VM folder.

I found these KB :

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024874

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1034573

It seem that vCenter determine a path for retrieving filesytem information on datastore and in my case it always choose ESX-2 even if VM executing in ESX-1.

So when ESX-2 try to retrieving information for a VM running on ESX-1 it see locked file.

I am not remeber of having had this issue with 5.5U2. Is anyone noticed this too ?

I there a way to configure vCenter to querry the host where the VM is running for retrieving datastore filesytem ?

Thank you.

Hello,

  does anybody have any idea why VM might swapping in this scenario ?

Esxi is with 2 cpu sockets.

esxtop

PMEM  /MB: 147445  total:  2380    vmk, 94536 other, 50528 free

VMKMEM/MB: 147060 managed:  2085 minfree, 72161 rsvd,  74899 ursvd,  high state

NUMA  /MB: 73727 (25330), 73716 (24813)

PSHARE/MB: 54183  shared,  2288  common: 51895 saving

SWAP  /MB: 21495    curr, 19533 rclmtgt:                0.01 r/s,  0.00 w/s

ZIP  /MB:  978  zipped,  535  saved

MEMCTL/MB:  149    curr,  149  target, 120152 max

So Esxi has 50528 MB free.

     GID NAME MEMSZ    GRANT    SZTGT     TCHD   TCHD_W    SWCUR    SWTGT   SWR/s   SWW/s  LLSWR/s  LLSWW/s   OVHDUW     OVHD  OVHDMAX

22337523 X1   65536.00 45561.91 14038.55  1310.72  1310.72 18735.35 18030.91    0.01    0.00     0.00     0.00    11.33   452.70   536.31

22326807 X2   49152.00 48950.75 47509.36 18186.24 14254.08     0.00     0.00    0.00    0.00     0.00     0.00    10.71   386.31   413.77

22330771 X3   24576.00 15906.00 10594.84   245.76   245.76     0.00     0.00    0.00    0.00     0.00     0.00    14.15   157.07   234.34

22225951 X4   24576.00 14925.84 13254.63     0.00     0.00     0.00     0.00    0.00    0.00     0.00     0.00    14.08   160.47   234.27

22225964 X5   24576.00 19298.36 14181.61   244.27   244.27  2757.98  1490.13    0.00    0.00     0.00     0.00    14.08   184.22   234.27

SWCUR for vm X1 and X5 is > 0 . I have no idea, why ESXi wants to swap VM memory to disk, if he still have 50 GB memory free. Host is currently in memory High state so, that would mean > 6% mem is free, if anything he should try balooning first.

I would appreciate any hints that would allow me to understand this.

Many thanks!

Hi,

on ESXi 5.5. I have created a VM (oracle Linux 6).

I can not ping Host.

Here is my ifcfg-eth0.

[root@OracleDB11gR24 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0

TYPE=Ethernet

UUID=293a365c-1afa-4156-8878-5dd3a0ae8fc4

ONBOOT=yes

NM_CONTROLLED=yes

BOOTPROTO=none

IPADDR=xxx.31.71.165

PREFIX=31

GATEWAY=xxx.80.36.254

DNS1=yyy.186.33.99

DEFROUTE=yes

IPV4_FAILURE_FATAL=yes

IPV6INIT=no

NAME="System eth0"

HWADDR=00:50:56:07:9D:8F

LAST_CONNECT=1454600502

When I ping Host :

ping xxx.80.36.69

connect: Network is unreachable

But I can ping other VMs and also GATEWAY which is xxx.80.36.254

Thank you.

Hi

I have been trying to get a Windows Server 2012 iso to auto install using an 'autounattend.xml' file, and it keeps failing at the following point:

Windows could not apply the unattend answer files <DiskConfiguration>

But if I use the same ISO file with the same 'autounattend.xml' setting up a VM on my local computer it work perfectly. So it is only failing when I try and setup the VM on VMware vSphere.

Attached is the XML file.

Any help would be appreciated.

Cheers

I have a Windows file server set up as a virtual machine with ESXi 5.1. The storage currently being used is a 1008.47 GB virtual disk on a datastore that is contained in the host machine's internal drives.

The file server is running out of space, and the datastore it's using is also running out of space, so we bought a new storage array that we have connected all of our VMware hosts to. I've successfully created a new VM using the new storage, so I know there isn't a problem there.

Where my problem exists is trying to add an additional virtual drive to the file server VM. In the vSphere client, I click on Edit Settings, Add, then select Hard Disk. I then select Create a new virtual disk, chose a size of 500 GB, thick provision (I've also tried thin), and for the Location, I navigated to the new shared datastore, which has 4.43 TB free.

In the Advanced Options, I've left the Virtual Device Node setting at its default (SCSI (0:1)), and under Mode I've tried both leaving it alone and also Independent/Persistent.

No matter what options I try, I keep getting the same error message: "File [the name of the datastore] is larger than the maximum size supported by datastore [the name of the datastore]."