Just a few thoughts.
As you probably all heard, VMware has announced the availability of there VSAN now integrated in the vmkernel of the vSphere 5.5 suite. If I read the specification and serveral blog post I get real excited. But is this the end of the SAN?
You probably all know the (dis)advantages of a traditional SAN, so I won’t sum this up. The next question is: When is a VSAN better than a traditional SAN? In my opinion a VSAN becomes interesting when it a can do the following:
- It has to be as or faster than a traditional SAN.
If you look at the architecutre of the VSAN you probaly would say that it’s faster than a traditional SAN because you have local disk. Much will depend on a mechanism that a vSphere host will always access a virtual machine rom his local storage. If the virtual machines is on a other vSphere host you will access a traditional SAN. So this concept has to prove itself
- It has to be the same or cheaper than a traditional SAN.
This really depends on the size of you storage and what kind of features you want to use. So this can be a advantage of disadvantage for both. I think that for most companies the VSAN will be cheaper, but if you need a large amount storage, VSAN will be more expensive because you need 3 times the amount of disks. And this all has to be replicated with 10G. I agree that 10G in the datacenter is the future, but at this time is to expensive for most companies.
- It has to be easier to administer than a traditional SAN.
This is a fact. A VSAN is easy to administer. But don’t forget that this is a fact because a VSAN doesn’t have the options as a NetApp or 3PAR, EMC etc.
- It has to have the same extra options (replication, HA, application awareness, backup, duplicate block tracking, etc) as a traditional SAN.
This one is simple. VSAN doesn’t have all the extra option that you could buy with a traditional SAN. For me application awareness for backup purposes is a real issue. If this feature could be added to the VSAN software it would great!
- It has to be more green as a traditional SAN.
One of the benefits of virtualization is that you need less physical hardware. Less phusical hardware meens less power consumption, less rackspace and less cooling (witch result in less power consumption). With a VSAN you won’t use a 1U server because of the lack of disk bay’s. So you probably will switch to 2u or 4u severs in larger environments. As you need a least 3 hosts for replication a VSAN will use more power, rackspace and cooling. Of course, a traditional SAN also uses rackspace, power and cooling, but you won’t need 3 times the disk. At the most 2 times in most configurations.
I don’t want to sound to negative about VSAN. Actually I’m quite excited and see a lot of potential. But I also see disadvantage and don’t thinks a VSAN is the solution for all our storage problems. But I’m convinced that with the next release of VSAN, these disadvantages will be solved and that a VSAN (doesn’t matter form witch vendor) is the future.
Don’t you just hate when you want to use a password but that the default password policy of a product prohibits you to use this password. I know, these password policies are here for a reason but centrally when I’m testing software I want to use my default password. This is also the case with the vCenter Appliance. It’s my lab and I want to choose my password that I have been using for ages now! 🙂
So how can we adjust the password policy of the VCA?
- Login to the vSphere web client on hhttps://server-FQN:9443/vsphere-client
- Goto Administration | Sing-On and Discovery | Configuration | Policies and Edit the default password policy.
- Alter the password policy to your needs.
And you’re done 🙂
With a college of mine, I’m setting up a new business. Where going to provide a virtual desktop to (small) customers who have the need for a enterprise enviroment (mail, shared calanders, shared storage etc) but don’t have the budget for it. When we combine all those customers together you have a budget to provide those functionality at a fractions of the costs.
Of course we want to use VMware vSphere and View for this environment. Later I will provide some more details.
First step was to setup a test enviroment so we can show some functionality to customers. All went fine until my lab had a power failure. And of course at home I don’t have a UPS who can back this up. I switched on the power again and my servers start up up (very loud,because in my lab I only have one power supply connected.)
When I opened vCenter again I noticed that some virtual machine have red alarm icons on them. But when I looked at the alarm tap there was no triggered alarm.
So what trigger this red alarm icon. After some investigation I discovered that the ESXi servers where up and running before the storage was available. When the datastores where available the virtual machines where started. But the weren’t properly registered. A simply vMotion to another ESXi host solved the problem.
In my lab I changed the IP address of my vCenter 5.1 appliance.
I thought it would be pretty easy. Just connect to the vCenter appliance management port 5490 with HTTPS.
Login as root and go to the Network tab. Change the IP and reboot the vCenter appliance.
But after the reboot all my vSphere ESXi hosts where marked as “Not responding”. When I did a connect on the ESXi host the ESXi server connected. But after a minute the where marked as “Not responding” again. This minute is the default timeout value when vCenter doesn’t receive any heartbeats from the ESXi hosts. I read that vCenter listens at TCP and UDP 902. So I tried to telnet to the new vCenter IP address at port 902 and I didn’t get a response. So obvious vCenter isn’t listing on the TCP 902.
Then I looked at the vCenter settings. Login on the vCenter appliance with a vSphere client. Select the vCenter, select settings, general. Click “Edit”. Under runtime settings you will see the configured IP address. In my case this was the old IP address. After changing the old IP to the new IP address and a reboot my ESXi hosts kept connected.
During a storage migration the SAN team had to create and delete multiple LUNs for the VMware vSphere 5.1 environment.
Accidentally they deleted a LUN that wasn’t deleted in VMware vSphere. Gladly there were no more virtual machine on that datastore. When I tried to unmount the volume I got the following error:
The message is clear. I cannot unmount the datastore because SIOC is enabled. But I can’t disabled SIOC because the datastore ain’t available anymore. There are 2 solutions for this.
- Reboot the hosts. During boot SIOC won’t be enabled on the datastore anymore and you will be able to unmount the datastore.
- SSH to the ESXi console and stop the SIOC deamon by entering:
/etc/init.d/storageRM stop
Give a Rescan all on the storage adapter and enable the SIOC deamon again with the command:
/etc/init.d/storageRM start
Now you’re able to unmount the datastore.
Option 2 is nice if you don’t want or are unable to reboot your vSphere hosts.
VMware | Michael December 13, 2012 |
Comments Off on Unable to umount greyed-out datastore due to Storage I/O Control