The Complete Geek

Here is another rather quick one

In our situation we have HIT 3.2 installed (Host integration Toolkit) for equallogic, we have a piece of software which is taking VSS snapshots and not cleaning up after itself afterwards. Equallogic’s host integration toolkit takes a SAN snapshot when a VSS snapshot is taken.

What prompted this to be an issue is that because the application did not clean up after itself we got lots of online snapshots that the server was logging into.

We ran into a bug with the host integration toolkit that resulted in the dropping of a volume that had an online snapshot when an asynchronous logout was requested (in our case moving it between pools) This is slated to be resolved in the next HIT

The resolution in our case was to disable VSS integration on the problematic servers, this is actually a rather simply process

Simply disable and shut down the eqlvss service

The long term is to un-install the feature but I am unsure of a reboot so it may be advantageous to just disable the service, this causes no impact.

Labels: Eqlvss, equallogic, HIT, Host Integration Toolkit, VSS

Speaking as virtualization guy the ideal of a cloud
computing resource has some very interesting applications specially when it
comes to DR and HA. The idea that for example at month end when your business
sucks up compute cycles for accounting you can just "borrow" or
transfer load to a rented per cycle resource is intriguing. Allowing you to
plan for the average and rent the difference without having to buy

We are closer than we think:

Yes you heard me say it ... while there is a big push across
the market, heck even vmware is marketing their Vsphere4 as the "Cloud
OS" We really were introduced to most of the idea's of a cloud (at least
an internal one) with ESX3.X

I say this because most of what you think of when talking
about the vague term "Cloud" Really is done at that level with HA and
DRS

You have groups of hosts pooling resources, as load changes
and increases on a host virtuals move around to distribute load across the
cluster. In the cases of failures in hardware virtuals spin up on alternative
resources turning Multi hour outages into seconds.

The idea of a cloud OS really to me is just being able to
vmotion my virtual to someone else’s cluster based on policy or interaction
from me. The basic tools are there, heck some people already operate multiple
"Clouds" in separate data centers and use tools like SRM to be able
to spin up workloads based on policy between datacenters simply with a click of
a button.

Why not just rent the second datacenter?

The challenges:

Some of these are basic, fundamental, and hard to overcome.

1) Latency

Workload and workload interaction is key, the idea of
latency introduces complications to the concept. These are not insurmountable
in most cases ... the idea that you have several virtuals that make up an
"Application" and you simply pool those resources and always move
them together rather than as individuals reduces a lot of those problems (For
example always keeping an exchange frontend and backend together)

2) Security

A commonly brought up problem that has no easy answer

How can we ensure data integrity?

Really the answer is through policy for the most part ...
you can ensure data transmittal is secure ... you can control where when and
how that data comes into and out of your own data center but in the remote environment
it is all done by contract and holding them to the standards

While it is hard as IT guys to relinquish control there are
plenty of hosted models that already do that very same concept (heck I work for
one) It is do-able if they are held to be responsible.

Conclusion:

In the end the concept is nice but we are a long ways off to
a full cloud computing model. I think we will still see further developments in
the internal cloud, more features (E.X. FT virtuals) before we are able to
leverage those features seamlessly remotely

Labels: Cloud, Cloud Computing, CloudComputing, ESX, Vsphere

this one is really short and to the point but it is a change from 3.5 and I did spend a few min looking for how to do it.

Simply you can not import .ovf directly into ESX (I know dont know why they REMOVED this functionality ... you CAN buy ovf's off the marked place and import but not from file)

Simply use vmware converter and select "virtual appliance" and follow through

short and simple

Labels: ESX4, Ovf, Vsphere