Raj2796's Blog

March 14, 2012

Vmware vSphere 5 dead LUN and pathing issues and resultant SCSI errors

Filed under: san,vmware — raj2796 @ 3:13 pm

Recently we had a hardware issues with a san, somehow it appears to have presented multiple fake LUN’s to vmware before crashing and leaving vmware with a large amount of dead LUN’s it could not connect to. Cue a rescan all … and everthing started crashing !

Our primary cluster of 6 servers started to abend, half the ESX servers decided to vmotion of every vm and shutdown, the other 3 ESX servers were left running 6 servers worth of vm’s, DRS decided to keep moving vm’s of the highest utilised ESX server resulting in another esx server becoming highest utilised which then decided to migrate all vm’s of and so on in a never-ending loop

As a result the ESX servers were:

  • unresponsive
  • showing powered of machines as being on
  • unable to vmotion vm’s of
  • intermittently lost connection to VC
  • lost vm’s that were vmotioned i.e. the vms became orphaned

Here’s what i did to fix the issue.

1 – get NAA ID of the lun to be removed

 See error messages on server

Or see properties of Datastore in vc (assuming vc isn’t crashed)

Or from command line :

#esxcli storage vmfs extent list

Alternatively you could use #esxclu storage filesystem list however that wouldn’t work in this case since there were no filesystems on the failed luns

e.g. output

Volume Name VMFS UUID                           Extent Number Device Name                           Partition
———– ———————————– ————- ————————————  ———
datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6             0  naa.6001c230d8abfe000ff76c198ddbc13e        3
Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c2e7384fc9a        1
Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c51486715db        1
LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4             0 naa.60a98000572d54724a34655733506751        1

Look at the 3rd column, it’s the naa id of the luns, the 4th one is for a volume that’s labelled LUN01 – dodgy since they would have a recognisable label such as FASSHOME1 or FASSWEB6 etc if they were production servers, or even test servers

  • 2 – remove bad luns

 

If vc is working – in our case it wasn’t – goto configuration / device / look at the identifier’s and match the naa – e.g. random screenshot below to show where to look ( screenshot removed since it shows too much work information)

Right click the naa under identifier and select detach – confirm

Now rescan the fc hba

In our case vc wasn’t an option since the hosts were unresponsive and vc couldn’t communicate, also the luns were allready detached since they were never used, so :

list permanently detached devices:

# esxcli storage core device detached list

look at output at state off luns e.g.

Device UID                            State

————————————  —–

naa.50060160c46036df50060160c46036df  off

naa.6006016094602800c8e3e1c5d3c8e011  off

next permanently remove the device configuration information from the system:

# esxcli storage core device detached remove -d <NAA ID>

e.g.

# esxcli storage core device detached remove  -d naa.50060160c46036df50060160c46036df

 

OR

 

To detach a device/LUN, run this command:

# esxcli storage core device set –state=off -d <NAA ID>

To verify that the device is offline, run this command:

# esxcli storage core device list -d <NAA ID>

The output, which shows that the status of the disk is off, is similar to:

naa.60a98000572d54724a34655733506751

   Display Name: NETAPP Fibre Channel Disk (naa.60a98000572d54724a34655733506751)

   Has Settable Display Name: true

   Size: 1048593

   Device Type: Direct-Access

   Multipath Plugin: NMP

   Devfs Path: /vmfs/devices/disks/naa.60a98000572d54724a34655733506751

   Vendor: NETAPP

   Model: LUN

   Revision: 7330

   SCSI Level: 4

   Is Pseudo: false

   Status: off

   Is RDM Capable: true

   Is Local: false

   Is Removable: false

   Is SSD: false

   Is Offline: false

   Is Perennially Reserved: false

   Thin Provisioning Status: yes

   Attached Filters:

   VAAI Status: unknown

   Other UIDs: vml.020000000060a98000572d54724a346557335067514c554e202020

Running the partedUtil getptbl command on the device shows that the device is not found.

For example:

# partedUtil getptbl /vmfs/devices/disks/naa.60a98000572d54724a34655733506751

 

Error: Could not stat device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751- No such file or directory.

Unable to get device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751

 

AFTER DETACHING RESCAN LUNS

In our case we’re vmotioning the servers of then powering down/up the servers since they have issues and we want to force all references to be updated from a fresh network discovery which is the safest option

You can rescan through VC under normal operations – the scan all can cause errors however and its better to selectively scan adapaters to avoid stressing the system

Alternately theres the command line command which needs to be run on all affect servers:

# esxcli storage core adapter rescan [ -A vmhba# | –all ]

Othere usefull info

  • Where existing datastores have issues and need unmounting and vc not working

# esxcli storage filesystem list

(see above for example output)

Unmount the datastore by running the command:

# esxcli storage filesystem unmount [-u <UUID> | -l <label> | -p <path> ]

For example, use one of these commands to unmount the LUN01 datastore:

# esxcli storage filesystem unmount -l LUN01

# esxcli storage filesystem unmount -u 4e414917-a8d75514-6bae-0019b9f1ecf4

# esxcli storage filesystem unmount -p /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4

verify its unmounted by again running # esxcli storage filesystem list and confirming its removed from list

The above are the actions I found useful in my environment – to read the original Vmware TID i gained the majority of the information from go here

Advertisements

February 1, 2011

Deploying VM template including McAfee

Filed under: vmware — raj2796 @ 4:32 pm

I found this useful post on the mcafee forums

Cloning images containing the McAfee Agent can cause problems for ePO. Duplicate GUIDs and MAC addresses cause the problems.

Once the image is deployed, VirusScan Enterprise protects agains changes, so the batch file below needs to have these protections disabled prior to attempting changing the GUIDs and MAC addresses.

Do this before closing the image so that when the newly deployed image is first started new values will populate automatically with virtually no likely of duplicates. (Well, the MAC address needs to be considered in your environment.)

In order to make either registry change, you will have to temporarily change the default settings within VSE to allow the changes to occur.

From the VirusScan Console

  • Access Protection > Properties
  • Uncheck (unblock) ‘Prevent McAfee services from being stopped’
  • Common Standard Protection
  • Uncheck ‘Prevent modification of McAfee files and settings’
  • Uncheck ‘Prevent modification of McAfee Common Management Agent’

Then run the batch file below, or manually make the changes.

DeleteAgentGUID-MacAddress.Bat:

@echo off
title McAfee AgentGUID and MacAddress Removal Tool – by Ron Metzger
echo.
echo The McAfee Agent communicates with ePO, Protection Pilot, or McAfee’s
echo update services, using registry values of AgentGUID and MacAddress, to
echo uniquely identify each system. Imaging or duplicating a system breaks
echo these unique identifiers. Clearing these values, followed by a reboot or
echo services restart, repopulates these values with new and unique entries.
echo.
echo Prior to duplication, clear these registry entries and create the image
echo before restarting services or rebooting.
echo.
echo Otherwise,
echo.
echo After duplication, clear these values, then reboot or restart the services.
echo.
echo VSE v8.7i (or above) by default, self-protects against certain changes.
echo In order to make either registry change, temporarily disable the
echo self-protection settings within VSE v8.7i (or above).
echo.
echo From the VirusScan Console:
echo Access Protection > Properties
echo Uncheck ‘Prevent McAfee services from being stopped’
echo Common Standard Protection
echo Uncheck (un)Block ‘Prevent modification of McAfee files and settings’
echo Uncheck (un)Block ‘Prevent modification of McAfee Common Management Agent’
echo.
Choice.exe /C:YN /N ” Press Y to continue, N to skip . . . ?”
if ErrorLevel 2 goto Exit

echo Stopping services . . .
net stop McAfeeFramework /yes
net stop McShield /yes
net stop McTaskManager /yes
echo Stopping services, done.

echo Deleting registry entries . . .
REG delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent” /v AgentGUID /F
REG delete “HKLM\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent” /v MacAddress /F
REG delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent” /v AgentGUID /f
REG delete “HKLM\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent” /v MacAddress /f
echo Deleting registry entries, done.

echo.
echo Please re-enable the self-protection settings within
echo VSE v8.7i (or above) to there original values.
echo.
echo From the VirusScan Console:
echo Access Protection > Properties
echo Check ‘Prevent McAfee services from being stopped’
echo Common Standard Protection
echo Check Block ‘Prevent modification of McAfee files and settings’
echo Check Block ‘Prevent modification of McAfee Common Management Agent’
echo.
Choice.exe /C:YN /N ” Press YN to continue . . . ?”
echo.
echo About to restart McAfee services.
echo This will repopulate AgentGUID and MacAddress values.
echo.
echo Please do Not start these services if Imaging this system Now. (Choose Skip.)
echo.
Choice.exe /c:YN /T:N,15 /N ” Restart Services? Y to continue, N [or wait 15 seconds] to skip . . .
if ErrorLevel 2 goto Exit

echo Starting services . . .
net start McAfeeFramework /yes
net start McShield /yes
net start McTaskManager /yes
echo Starting services, done.

Choice /c:YN /T:Y,15 /N ” Press YN [or wait 15 seconds] to continue . . .
:Exit

This batch file can be used to prep and image or to simply change the values after the image has been issued.Hope this helps. Post back with more questions.

Thanks,

Ron Metzger

originally posted here

January 25, 2011

VMware Template renames network adaptor when deploying windows 7 or windows 2008 R2

Filed under: MS,vmware — raj2796 @ 10:40 am

This caught me out for a while and I originally thought i had made a mistake in creating my templates, however it appears this is a known issue with VMware, from the VMware knowledge base :

Deploying Windows 2008 R2 and Windows 7 templates with vmxnet3 renames the NIC as #2

Symptoms
When deploying virtual machines from a Windows 2008 R2 or Windows 7 template configured with the vmxnet3 Ethernet device, the resulting virtual machine’s guest operating system shows the Ethernet adapter as:

VMXNET Device #2 in Device Manager
Local Area connection #2 in Network Properties

Resolution
This issue occurs when virtual adapter VMXNET3 is used.
To workaround this issue, try one of these options:

  • Use E1000 virtual network cards in Windows 2008 R2 and Windows 7 templates.
  • Apply the Microsoft hotfix for this issue. For more information, see the Microsoft Knowledge Base article 2344941.

This hotfix may resolve issues with duplicate MACs when deploying Windows 2008 R2 from template using an E1000 driver.

Note: The preceding link was correct as of January 12, 2011. If you find the link is broken, provide feedback and a VMware employee will update the link.

From :
http://kb.vmware.com/kb/1020078

December 15, 2010

Configuring VMware High Availability fails with the error: Cannot complete the configuration of the HA agent on the host

Filed under: ha,vmware — raj2796 @ 4:40 pm

Symptoms
Configuring VMware High Availability (HA) fails
The vSphere Client may show one service console, however running the esxcfg-vswif -l command while logged into the ESX service console, reveals additional service consoles
You see the messages:
Cannot complete the configuration of the HA agent on the host. See the task details for additional information.
Misconfiguration in the host network setup
Resolution
This issue occurs if all the hosts in the cluster do not share the same service console or management network configurations. Some hosts may have service consoles using a different name or may have more service consoles than other hosts.

Address the network configuration differences between the hosts if you are going to use the Shut Down or Power Off isolation responses because these options trigger a VMware HA isolation in the event of Service Console or Management Network failures.

If you are using the Leave VM Powered on isolation response, the option to ignore these messages is available in VMware VirtualCenter 2.5 Update 3.

To configure VirtualCenter to ignore these messages, set the advanced option das.bypassNetCompatCheck to true:

Note: When using the das.bypassNetCompatCheck option, the heartbeat mechanism during configuration used in VirtualCenter 2.5 only pairs symmetric IP addresses within subnets across nodes. For example, in a two node cluster, if host A has vSwif0 “Service Console” 10.10.1.x 255.255.255.0 and vSwif1 “Service Console 2” 10.10.5.x and host B has vSwif0 “Service Console” 10.10.2.x 255.255.255.0 and vSwif1 “Service Console 2” 10.10.5.x, the heartbeats only happen on vSwif1. Starting in vCenter Server 4.0, they can be paired across subnets if pings are allowed across the subnets. However, VMware recommends having them within subnets.
Right-click the cluster, then click Edit Settings.
Deselect Turn on VMware HA.
Wait for all the hosts in the cluster to unconfigure HA.
Right-click the cluster, and choose Edit Settings.
Select Turn on Vmware HA, then select VMware HA from the left pane.
Select Advanced options.
Add the option das.bypassNetCompatCheck with the value True.
Click OK on the Advanced Options screen, then click OK again to accept the cluster setting changes.
Wait for all the ESX hosts in the cluster to reconfigure for HA.

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

October 19, 2010

Windows 2008 Vmware Vsphere additional disk issue

Filed under: MS,vmware — raj2796 @ 1:28 pm

All virtual machine disk files (VMDKs) are presented to VMs as SAN disks and Windows 2008 changed how SAN disks were handled, in effect they are offline until you set them online. You will see the “Disk is Offline because policy was set by an administrator” message.

First you need to change how Windows 2008 sees the SAN devices, then you need to clear a readonly flag, then you are good to go. Using ‘diskpart’ enter the following commands

DISKPART> SAN POLICY=OnlineAll
DISKPART> RESCAN
DISKPART> SELECT DISK 1
DISKPART> ATTRIBUTES DISK CLEAR READONLY
DISKPART> ONLINE DISK
DISKPART> CONVERT MBR

Now you can use your normal mechanisms to add, format, etc. the disk into the system.

http://www.astroarch.com/blog/?tag=policy-set-by-administrator

February 18, 2010

Vmware Vsphere PVSCSI white paper and article on interrupt coalescing

Filed under: pvscsi,vmware — raj2796 @ 10:51 am

As a final post on PVSCSI i’ve stummbled upon the vmware PVSCSI Storage Performance study paper
vsp_4_pvscsi_perf.pdf

Also the vmware VROOM! page

And lastly a more detailed explenation on why PVSCI is not allways best :

PVSCSI and Low IO Workloads
Filed under: Uncategorized — Tags: pvscsi, storage, vmkernel — Scott @ 10:46 am

Scott Sauer recently asked me a tough question on Twitter. My roaming best practices talk includes the phrase “do not use PVSCSI for low-IO workloads”. When Scott saw a VMware KB echoing my recommendation, he asked the obvious question: “Why?” It took me a couple of days to get a sufficient answer.

One technique for storage driver efficiency improvements is interrupt coalescing. Coalescing can be thought of as buffering: multiple events are queued for simultaneous processing. For coalescing to improve efficiency, interrupts must stream in fast enough to create large batch requests. Otherwise the timeout window will pass with no additional interrupts arriving. This means the single interrupt is handled as normal but after a useless delay.

An intelligent storage driver will therefore coalesce at high IO but not low IO. In the years we have spent optimizing ESX’s LSI Logic virtual storage adapter, we have fine-tuned the coalescing behavior to give fantastic performance on all workloads. This is done by tracking two key storage counters:

* Outstanding IOs (OIOs): Represents the virtual machine’s demand for IO.
* IOs per second (IOPS): Represents the storage system’s supply of IO.

The robust LSI Logic driver increases coalescing as OIOs and IOPS increase. No coalescing is used with few OIOs or low throughput. This produces efficient IO at large throughput and low latency IO when throughput is small.

Currently the PVSCSI driver coalesces based on OIOs only, and not throughput. This means that when the virtual machine is requesting a lot of IO but the storage is not delivering, the PVSCSI driver is coalescing interrupts. But without the storage supplying a steady stream of IOs there are no interrupts to coalesce. The result is a slightly increased latency with little or no efficiency gain for PVSCSI in low throughput environments.

LSI Logic is so efficient at low throughput levels that there is no need for a special device driver to improve efficiency. The CPU utilization difference between LSI and PVSCSI at hundreds of IOPS is insignificant. But at massive amounts of IO–where 10-50K IOPS are streaming over the virtual SCSI bus–PVSCSI can save a large number of CPU cycles. Because of that, our first implementation of PVSCSI was built on the assumption that customers would only use the technology when they had backed their virtual machines by world-class storage.

But VMware’s marketing engine (me, really) started telling everyone about PVSCSI without the right caveat (“only for massive IO systems!”) So, everyone started using it as a general solution. This meant that in one condition–slow storage (low IOPS) with a demanding virtual machine (high OIOs)–PVSCSI has been inefficiently coalescing IOs resulting in performance slightly worse than LSI Logic.

But now VMware’s customers want PVSCSI as a general solution and not just for high IO workloads. As a result we are including advanced coalescing behavior in PVSCSI for future versions of ESX. More on that when the release vehicle is set.
PVSCSI In A Nutshell

If you plodded through the above technical explanation of interrupt coalescing and PVSCSI I applaud you. If you just want a summary of what to do, here it is:

* For existing products, only use PVSCSI against VMDKs that are backed by fast (greater than 2,000 IOPS) storage.
* If you have installed PVSCSI in low IO environments, do not worry about reconfiguring to LSI Logic. The net loss of performance is very small. And clearly these low IO virtual machines are not running your performance-critical applications.
* For future products*, PVSCSI will be as efficient as LSI Logic for all environments.

(*) Specific product versions not yet announced.

original article can be found here at Scott Drummonds site – apologies for spelling your name wrong earlier 😛

When to use Vmware PVSCSI and when to use LSI Logic

Filed under: pvscsi,vmware — raj2796 @ 10:32 am

Now that the technology is officially supported by vmware, and we can expect to see a growth in the number of systems supported over the subsequent vmware updates, many of us are starting to use PVSCSI for all new vm’s. I’ve found it works fine with non offically supported OS’s, so long as you have the latest vmware tools installed (i have not tried netware yet though).

PVSCSI gives 12% more throughput and 18% less cpu use, thats enough of a gain to avoid having to upgrade your servers this year, added to thin provisioning and you can skip your storage upgrades, roll the money over and get something nice and shiny the following year.

It seems PVSCSI isn’t allways the best choice though, for heavy workloads its great, for lower workloads LSI is still champ. Vmware has a knowledgebase article on this which can summed upto :

PVSCSI – all else ( 2,000 IOPS + etc )
LSI Logic – less than 2,000 IOPS and issuing greater than 4 outstanding I/Os.

Vmwares knowledge base article:

Do I choose the PVSCSI or LSI Logic virtual adapter on ESX 4.0 for non-IO intensive workloads?
Details
VMware evaluated the performance of PVSCSI and LSI Logic to provide a guideline to customers on choosing the right adapter for different workloads. The experiment results show that PVSCSI greatly improves the CPU efficiency and provides better throughput for heavy I/O workloads. For certain workloads, however, the ESX 4.0 implementation of PVSCSI may have a higher latency than LSI Logic if the workload drives low I/O rates or issues few outstanding I/Os. This is due to the way the PVSCSI driver handles interrupt coalescing.

One technique for storage driver efficiency improvements is interrupt coalescing. Coalescing can be thought of as buffering: multiple events are queued for simultaneous processing. For coalescing to improve efficiency, interrupts must stream in fast enough to create large batch requests. Otherwise, the timeout window will pass with no additional interrupts arriving. This means the single interrupt is handled as normal but after an unnecessary delay.

The behavior of two key storage counters affects the way the PVSCSI and LSI Logic adapters handle interrupt coalescing:

* Outstanding I/Os (OIOs): Represents the virtual machine’s demand for I/O.
* I/Os per second (IOPS): Represents the storage system’s supply of I/O.

The LSI Logic driver increases coalescing as OIOs and IOPS increase. No coalescing is used with few OIOs or low throughput. This produces efficient I/O at large throughput and low-latency I/O when throughput is small.

In ESX 4.0, the PVSCSI driver coalesces based on OIOs only, and not throughput. This means that when the virtual machine is requesting a lot of I/O but the storage is not delivering, the PVSCSI driver is coalescing interrupts. But without the storage supplying a steady stream of I/Os, there are no interrupts to coalesce. The result is a slightly increased latency with little or no efficiency gain for PVSCSI in low throughput environments.

The CPU utilization difference between LSI and PVSCSI at hundreds of IOPS is insignificant. But at larger numbers of IOPS, PVSCSI can save a lot of CPU cycles.

Solution
The test results show that PVSCSI is better than LSI Logic, except under one condition–the virtual machine is performing less than 2,000 IOPS and issuing greater than 4 outstanding I/Os.

February 17, 2010

Vmware Vsphere NMP: nmp_Device problem

Filed under: san,vmware — raj2796 @ 4:45 pm

Whilst following links from a site discussing round robin IO optimisation for EVA’s, something i need to do myself in the following weeksm i came across the following info:

Recently saw a little uptick (still a small number) in customers running into a specific issue – and I wanted to share the symptom and resolution. Common behavior:

1. They want to remove a LUN from a vSphere 4 cluster
2. They move or Storage vMotion the VMs off the datastore who is being removed (otherwise, the VMs would hard crash if you just yank out the datastore)
3. After removing the LUN, VMs on OTHER datastores would become unavailable (not crashing, but becoming periodically unavailable on the network)
4. the ESX logs would show a series of errors starting with “NMP”

Examples of the error messages include:

“NMP: nmp_DeviceAttemptFailover: Retry world failover device “naa._______________” – failed to issue command due to Not found (APD)”

“NMP: nmp_DeviceUpdatePathStates: Activated path “NULL” for NMP device “naa.__________________”.

What a weird one… I also found that this was affecting multiple storage vendors (suggesting an ESX-side issue). You can see the VMTN thread on this here.

So, I did some digging, following up on the VMware and EMC case numbers myself.

Here’s what’s happening, and the workaround options:

When a LUN supporting a datastore becomes unavailable, the NMP stack in vSphere 4 attempts failover paths, and if no paths are available, an APD (All Paths Dead) state is assumed for that device (starts a different path state detection routine). If after that you do a rescan, periodically VMs on that ESX host will lose network connectivity and become non-responsive.

This is a bug, and a known bug.

What was commonly happening in these cases was that the customer was changing LUN masking or zoning in the array or in the fabric, removing it from all the ESX hosts before removing the datastore and the LUN in the VI client. It is notable that this could also be triggered by anything making the LUN inaccessible to the ESX host – intentional, outage, or accidental.

Workaround 1 (the better workaround IMO)

This workaround falls under “operational excellence”. The sequence of operations here is important – the issue only occurs if the LUN is removed while the datastore and disk device are expected by the ESX host. The correct sequence for removing a LUN backing a datastore.

1. In the vSphere client, vacate the VMs from the datastore being removed (migrate or Storage vMotion)
2. In the vSphere client, remove the Datastore
3. In the vSphere client, remove the storage device
4. Only then, in your array management tool remove the LUN from the host.
5. In the vSphere client, rescan the bus.

Workaround 2 (only available in ESX/ESXi 4 u1)

This workaround is available only in update 1, and changes what the vmkernel does when it detects this APD state for a storage device, basically just immediately failing to open a datastore volume if the device’s state is APD. Since it’s an advanced parameter change – I wouldn’t make this change unless instructed by VMware support.

esxcfg-advcfg -s 1 /VMFS3/FailVolumeOpenIfAPD

Some QnA:

Q: Does this happen if you’re using PowerPath/VE?

A: I’m not sure – but I don’t THINK that this bug would occur for devices owned by PowerPath/VE (since it replaces the bulk of the NMP stack in those cases) – but I need to validate that. This highlights to me at least how important these little things (in this case path state detection) are in entire storage stack.

In any case, thought people would find it useful to know about this, and it is a bug being tracked for resolution. Hope it helps one customer!

Thank you to a couple customers for letting me poke at their case, and to VMware Escalation Engineering!

The above post is from virtualgeek

February 11, 2010

VMWARE ACADEMIC SITE LICENSE

Filed under: Virtualisation,vmware — raj2796 @ 5:10 pm

VMware is finally starting to get their act together and will be trialing an academic site license at Warwick university in the uk, based on FTE numbers, and i believe an approx. guarantee of £60,000 a year, based on information from technicians at Warwick university. Allegedly the idea of starting with Warwick as a trial in the UK is since they have a low inital investment in VMware so it will be easy to maintain expenditure to cover a site license. The site license will include VC/ESX4/VIEW/SITE MANAGER and probably more by the time it’s finalised. Note that to my understanding Warwick have not yet signed up to the site license, they are however the first in the uk to be offered such a deal.

Vmware previously organised a meeting with a dozen or so educational establishments in the uk to investigate the demand and interest for such a license, the meeting was around August last year and most of the educational establishments had given up on the idea.

Why have VMware suddenly changed heart on the issue of offering site license’s? Citrix academic pricing must be a huge challenge to VMware, as is the growing feature list of MS, which is cover by UK HE Select agreements assuming they opt for the virtual options. Others say it’s the replacement of the former UK HE manager, Jason, with new blood, Dick (Robert)Balding, you gotta love the name. Either way I doubt we’ll know unless someone can ask Jason, what are the odds he’ll end up working for the NHS like other former VMware staff ?

Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters

Filed under: pvscsi,Virtualisation,vmware — raj2796 @ 5:08 pm

NOTE – although not officially supported, boot from PVSCSI adaptors seems to work fine so far on the OS’s i have tried – boot from PVSCSI is supported from 4 u1

Details
This article includes supplemental information about configuring and using VMware Paravirtual SCSI (PVSCSI) adapters.

PVSCSI adapters are high-performance storage adapters that can result in greater throughput and lower CPU utilization. PVSCSI adapters are best suited for environments, especially SAN environments, where hardware or applications drive a very high amount of I/O throughput. PVSCSI adapters are not suited for DAS environments.

Paravirtual SCSI adapters are supported on the following guest operating systems:

*
Windows Server 2008
*
Windows Server 2003
*
Red Hat Enterprise Linux (RHEL) 5

Paravirtual SCSI adapters also have the following limitations:

*
Hot add or hot remove requires a bus rescan from within the guest.
*
Disks with snapshots might not experience performance gains when used on Paravirtual SCSI adapters or if memory on the ESX host is overcommitted.
*
If you upgrade from RHEL 5 to an unsupported kernel, you might not be able to access data on the virtual machine’s PVSCSI disks. You can runvmware-config-tools.pl with the kernel-version parameter to regain access.
*
Because the default type of newly hot-added SCSI adapter depends on the type of primary (boot) SCSI controller, hot-adding a PVSCSI adapter is not supported.
*
Booting a Linux guest from a disk attached to a PVSCSI adapter is not supported. A disk attached using PVSCSI can be used as a data drive, not a system or boot drive. Booting a Microsoft Windows guest from a disk attached to a PVSCSI adapter is not supported in versions of ESX prior to ESX 4.0 Update 1.

Solution
To configure a disk to use a PVSCSI adapter:

1.
Launch a vSphere Client and log in to an ESX host.
2.
Select a virtual machine, or create a new one.
3.
Ensure a guest operating system that supports PVSCSI is installed on the virtual machine.

Note: Booting a Linux guest from a disk attached to a PVSCSI adapter is not supported. Booting a Microsoft Windows guest from a disk attached to a PVSCSI adapter is not supported in versions of ESX prior to ESX 4.0 Update 1. In these situations, the system software must be installed on a disk attached to an adapter that does support bootable disk.

4.
In the vSphere Client, right-click on the virtual machine and click Edit Settings.
5.
Click the Hardware tab.
6.
Click Add.
7.
Select Hard Disk.
8.
Click Next.
9.
Choose any one of the available options.

10.
Click Next.
11.
Specify the options your require. Options vary depending on which type of disk you chose.
12.
Choose a Virtual Device Node between SCSI (1:0) to SCSI (3:15) and specify whether you want to use Independent mode.
13.
Click Next.
14.
Click Finish to finish the process and exit the Add Hardware wizard. A new disk and controller are created.
15.
Select the newly created controller and click Change Type.
16.
Click VMware Paravirtual and click OK.
17.
Click OK to exit the Virtual Machine Properties dialog.
18.
Power on the virtual machine.
19.
Install VMware Tools. VMware Tools includes the PVSCSI driver.
20.
Scan and format the hard disk.

Note: In some operating system types, to perform this procedure, you need to create a virtual machine with the LSI controller, install VMware Tools, then change to the drives to paravirtualized mode.

The above article is from vmwares knowledge base

Raphael from Hypervisor.fr has a great video on this:

Next Page »

Create a free website or blog at WordPress.com.