Hello,
I tried to install ESXI4.1 on my brand-new Asus P8P67.
I managed to patch the ISO with varazir´s script for the on-board RTL8111 NIC. That seems to work (at least the installation continues)

Unfortunately the P67 Chipset AHCI / SATA driver is not supported.

There are two SATA/AHCI Controllers on board :

the Intel P67 Chipset (Cougar Point 6) Controller and
the Marvell 9120 Controller

does anyone have drivers for one of them ?
the P67 Controller would be prefered, because it is faster then the Marvell.

What's the PCI id for the Cougar controller? http://www.vm-help.com/esx40i/find_PCI_ID.php

Thanks for Your fast reply.

For the Asus P8P67 based on Cougar Point 6 Chipset the Mass storage Controllers have following PCI Ids :

lspci -v is showing :

For the Intel Controller :
000:000:31.2 SATA controller Mass storage controller: Intel Corporation
Class 0106 : 8086:1c02

For the Marvell Controller :
000:010:00.0 SATA controller Mass storage controller:
Class 0106 : 1b4b:9120

yours sincerely
Robert Nowotny
Vienna

Robert, thanks for posting this thread. I'm about to order parts to build a Sandy Bridge ESX host using wither the P67 or H67 chipset, the power efficiency of this CPU can not be ignored and will be a great platform for a server that will be running 24 x 7. Please keep us updated with your progress.

Indeed keep us updated! These chipsets and CPU's are ideal for home low-idle but high performance usage!

Especially when the "Q" chipsets will be released in february. These feature the Intel vPRO and AMT extensions. And since version 6 (these new boards will have version 7) they can actually function as a sort of "Remote IP KVM" granting you console access to your server using VNC!

http://hw-lab.com/cougar-point-sandy-bridge-chipset-lineups.html has a good comparison between the chipsets.

Quindor, you are a life-saver. Thanks for posting the link to the upcoming chipsets. I did not know we' d have to wait until the Q67 is released to get VT-d support, which is very important to me for my ESX installation.

Thanks, but I have found that the situation is seemingly even more complex then that! See : http://siphon9.net/loune/2011/01/sandy- ... alization/ and http://siphon9.net/loune/2011/01/list-o ... port-vt-d/ .

Let's try and get all information out there! And best to gather it here on the forums.

Right now it seems that VT-d is actually a BIOS function and the manufacturer has to choose to implement it or not. Quite confusing!

Myself I want the vPRO/AMT features so that I have remote KVM! But vt-d would be sad if it was missing for no apparent reason.

Yes, VT-d still has to be turned on in the BIOS, but it can't happen unless the chipset and processor combo actually supports it. So as of today, there are no Sandy Bridge motherboards that can do VT-d.

I've done some further research and apparently there are Q67 motherboards from both ASUS and Supermicro waiting in the wings, hopefully they'll be released for public sale the same day as the official launch of the Q67 in February.

I finally decided to switch to the 3ware® SAS 9750 SAS/SATA2 Raid Controller, that seems the perfect choice for me. It is supported for ESXI4.1 and is much faster then the outdated 96xx series controllers.
Thats for one of my new servers .... (never get tired to mention : bandwith is dependent on the number of drives, so better use 8 x 500Mb then 3 x 2TB ..... )

First, i was curiouse to test my new P8P67 board with ESXI4.1 so I searched for the Cougar Point AHCI Driver, but now I decided to use the raid controller for better disk performance and more security. I will come back definitely later to let You folks know about my experience installing that controller in ESXi 4.1 (or might beg for some help)

For my new personal workstation I guess I will wait for the Q67 Chipset that supports vt-d. In that case I might use XEN to get VGA-pass through working, just for some special and rarely used CAD VM-s I use.
Please check my other post for the vt-d issue.

My personal opinion : vt-d it is (almost) useless for servers, only for some very special configurations. And for such special configurations I would suggest not to use virtual machines because the main advantages of VM-Machines get lost (see my other post). Paravirtual drivers (vmtools) are offering almost the same performance.
For workstations it will make some limited sense, in conjunction with XEN (because vm-workstation does not support vt-d) to get full VGA performance.

yours sincerely

Robert / Vienna

Hello,

for the VT-d issue :

the short version :
- only supported in vmware esxi 4.x
- many disadvantages, you loose lots of vm-features like snapshots etc.
- paravirtualisation (aka vm-tools) offers almost the same speed
- devices can be only used exclusively for one vm. (so You would need for instance one deticated NIC or SAN Controller for each VM)
- only very limited use in conjunction with vmware.
- might be useful on some workstation setups in conjunction with XEN, if You can get the VGA Card working in pass-through mode. (and You really really need that)


the long version starts here :

see : http://www.vmware.com/pdf/Perf_Best_Pra ... ere4.1.pdf
see : http://software.intel.com/en-us/article ... o-devices/
see : http://vmstudy.blogspot.com/2010/04/net ... -vt-d.html

VT-d is an I/O memory management unit that remaps I/O DMA transfers and device interrupts. This can allow virtual machines to have direct access to hardware I/O devices, such as network cards. In AMD processors this feature is called AMD I/O Virtualization (AMD-Vi or IOMMU) and in Intel processors the feature is called Intel Virtualization Technology for Directed I/O (VT-d).

see : http://www.vmware.com/pdf/Perf_Best_Pra ... ere4.1.pdf

VMDirectPath I/O leverages Intel VT-d and AMD-Vi hardware support (described in “Hardware-Assisted I/O MMU Virtualization (Intel VT-d and AMD AMD-Vi)” to allow guest operating systems to directly access hardware devices. In the case of networking, VMDirectPath I/O allows the virtual machine to access a physical NIC directly rather than using an emulated device (E1000) or a para-virtualized device (VMXNET, VMXNET3). While VMDirectPath I/O has limited impact on throughput, it reduces CPU cost for networking-intensive workloads. VMDirectPath I/O is incompatible with many core virtualization features, however. These include vMotion, Snapshots, Suspend/Resume, Fault Tolerance, NetIOC, Memory Overcommit, and VMSafe. Typical virtual machines and their
workloads don't require the use of VMDirectPath I/O. For workloads that are very networking intensive and don't need the core virtualization features mentioned above, however, VMDirectPath I/O might be
useful to reduce CPU usage. (but in that case I would use a dedicated machine for that purpose and cluster it)

Here some testresults (for xen / kvm) between native vs paravirtual drivers (aka vmtools for vmware) vs vt-d :
http://vmstudy.blogspot.com/2010/04/net ... -vt-d.html

the results will be very similar for vmware.

the conclusio there is :
One should use Para-virtualized drivers
KVM and XEN have close network performance for both VT-d and Para-virt. The MAX bandwidth of Virtio connecting to a remote is very close to VT-d or Native

If You use XEN, then You might get pass-through working for the VGA Card, what might be interesting for some workstation setups, to use all the 3D features the vga card is offering. This might make some sense for a few people out there.

yours sincerely
Robert , Vienna