Skip to main content

Posts

Assigning Static MAC address to othere VM after Migration (P2V)

 MAC address is not accepting and conflicting , which result its not powering on on destination VC Cause: This issue occurs when the virtual machine has been configured with a static MAC address in the 00:50:56:xx:xx:xx range. VMware vCenter Server 5.1 and later detects this as a protected range and refuses to power on the virtual machine. In vSphere 5.1 and later new policies have been implemented where the statically assigned MAC addresses can only be in the range 00:50:56:[00-3F]:XX:XX or other non-VMware OUI addresses. Prefix- and range-based MAC address allocation is supported only in vCenter Server 5.1 or later. This implies that if you add pre-5.1 hosts to vCenter Server 5.1, and use anything other than VMware OUI prefix- or range-based MAC address allocation, virtual machines assigned MAC addresses that are not VMware OUI prefixed fail to power on their pre-5.1 hosts. Now, from what we’ve seen, the restriction is a little more detailed

RAW Device Mapping (RDM)

  RDM (Raw Device Mapping) A Raw Disk Mapping (RDM) can be used to present a LUN directly to a virtual machine from a SAN. Rather than creating a virtual disk (VMDK) on a LUN, which is generally shared with other VMs and virtual disks. The reasons for doing this should purley be for functional and management reasons, NOT performance. There is a mis-understanding that RDMs offer greater performance compared to VMDK's on a VMFS datastore. I've seen lots of vSphere environments that have gone over kill on RDMs for SQL servers and the like for "performance reasons", its difficult to manage! If your looking for improved storage performance look into the VMware Paravirtual SCSI (PVSCSI) adaptor. The main reason for using an RDM should be as follows: To utilize native SAN tools and commands If using Microsoft Cluster Services (MSCS), Failover Clusters or other clustering solution. There are two RDM modes to be aware of: Virtual compatabi