Tag: VI

HOW TO force VirtualCenter to load after SQL Server on the same system

http://support.microsoft.com/kb/193888

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Service name>

<Service name> = vpxd for VirtualCenter
modify the DependOnService key and add MSSQLSERVER

ESX 3.5 HOW TO obtain storage information from vimsh

In case it is not apparent already, vimsh is something you can invoke on an ESX 3.5.x environment, in order to grab some sometimes necessary storage information.

One particular problem that was outstanding for some time was finding a way to read /proc/vmware/scsi/vmhba<x>/* content. Specifically, the SCSI/LUN ID was sought-after by some TSEs and customers, which are unavailable due to the relevant /proc/vmware/scsi/ nodes being omitted on ESX 3.5.x.

Provided is a simple line to grab the output using vimsh:

“vimsh -n -e hostsvc/storage/topology_info &> test.txt”

It will in this order:

–          Run vimsh in non-interactive mode with the “n” switch.

–          Using the “e” switch, will run “hostsvc/storage/topology_info” for you.

–          Will suppress STD_OUT with the “&” sign before the output redirector (benign “file not found” error shows up, may as well ignore).

–          Output the content to the test.txt file.

Obviously the above is run in BASH / the COS.

If you want a more general overview of storage, replace “topology_info” with “info”.

When running vimsh, remember that you can use “Tab” to list the available files/commands and categories. Content of a file/command is displayed by invoking it directly. We effectively execute hostsvc/storage/topology_info to list this information. Hostsvc and storage are directories or categories.

There is a wealth of information contained and accessed by this utility. I don’t believe we want customers to play around with it, but I imagine you may run into cases where they need the SCSI information for their SAN teams. The above should help a bit.

Note that vsish acts differently, and contained values are obtained using “get”.

Good luck, hope it helps some of you out there still confused.

ovftool …

OVF is an open-standard for VM distribution. OVF has a number of important benefits, like encapsulating the entire VM in a single file, storing metadata, support for multi-VM configurations, disk compression, and platform independence. VC 2.5 also allows the VI client to import an OVF image from a URL and download it and install it automatically over the
internet.

In order to create an OVF image, you can use the OVF tool that VMware provides to convert an existing VM into an OVF image.

You can get more information about OVF from:
http://www.vmware.com/appliances/learn/ovf.html

docs here:

Click to access ovf_tool.pdf

You can download the OVF tool from:
http://www.vmware.com/download/eula/ovf_eula.html

In terms of building and packaging the VA, a good starting point is the VA build page: http://www.vmware.com/appliances/build/how.html. I suggest you also take a look at the VA best practices doc (http://www.vmware.com/files/pdf/vam_best_practices_building.pdf), which covers issues about how to package and distribute virtual appliances. A few key suggestions from the paper including using virtual SCSI (and not IDE) drives, disconnecting virtual CDROMs, floppies, etc, and installing VMware tools. If you follow the best practice guidelines, you can request to certify the virtual appliance as well. Those guidelines are at http://www.vmware.com/appliances/build/list.html. I suggest you read and follow the best practices paper whether you plan to certify or not, as it will allow maximum portability for your virtual appliance.

iSCSI naming

Both targets and initiators require names for the purpose of
identification, so that iSCSI storage resources can be managed
regardless of location (address). Note that this means iSCSI names
are independent of location.

Furthermore, iSCSI names are associated with iSCSI nodes instead of
with network adapter cards to ensure the free movement of network
HBAs between hosts without loss of SCSI state information
(reservations, mode page settings etc) and authorization
configuration. An iSCSI node also has one or more addresses.
An iSCSI address specifies a single path to an iSCSI node and consists
of the iSCSI name, plus a transport (TCP) address which uses the following format: [: ] If the is not specified, the
default port 3260, assigned by IANA, will be assumed. For iSCSI
initiators, the is omitted.

The concepts of names and addresses have been carefully separated in
iSCSI:

– An iSCSI Name is a location-independent, permanent identifier for
an iSCSI node. An iSCSI node has one iSCSI name, which stays
constant for the life of the node.

– An iSCSI Address specifies not only the iSCSI name of an iSCSI
node, but also a location of that node. The address consists of a
host name or IP address, a TCP port number (for the target), and
the iSCSI Name of the node. An iSCSI node can have any number of
addresses, which can change at any time.

To assist in providing a more human-readable user interface for
devices that contain iSCSI targets and initiators, a target or
initiator may also provide an alias. The alias strings are communicated
between the initiator and target at login, and can be displayed by a user interface on either end, helping the user tell at a glance whether the
initiators and/or targets at the other end appear to be correct.
The alias is a variable length string, between 0 and 255 characters.

Constructing iSCSI names using the iqn. format.

– The string “iqn.”

– A date code specifying the year and month in which the
organization registered the domain or sub-domain name used as the
naming authority string.

– The organizational naming authority string, which consists of a
valid, reversed domain or subdomain name.

– Optionally, a ‘:’, followed by a string of the assigning
organization’s choosing, which must make each assigned iSCSI name
unique.

The following is an example of an iSCSI qualified name from an
equipment vendor:

Organizational Subgroup Naming Authority
Naming and/or string Defined by
Type Date Auth Org. or Local Naming Authority
+–++—–+ +———+ +——————————–+
| || | | | | |

iqn.2001-04.com.example:diskarrays-sn-a8675309

The following is an example of an iSCSI name string from a storage
service provider:

Organization String
Naming Defined by Org.
Type Date Authority Naming Authority
+-+ +—–+ +————-+ +———————-+
| | | | | | | |
iqn.1995-11.com.example.ssp:customers.4567.disks.107

Note that when reversing these domain names, the first component
(after the “iqn.”) will always be a top-level domain name, which
includes “com”, “edu”, “gov”, “org”, “net”, “mil”, or one of the
two-letter country codes. The use of anything else as the first
component of these names is not allowed.

Constructing iSCSI names using the eui. format

The iSCSI eui. naming format allows a naming authority to use IEEE
EUI-64 identifiers in constructing iSCSI names. The details of
constructing EUI-64 identifiers are specified by the IEEE
Registration Authority (see [EUI64]).

Example iSCSI name:

Type EUI-64 identifier (ASCII-encoded hexadecimal)
+–++————–+
| || |
eui.02004567A425678D

iSCSI Discovery

The goal of iSCSI discovery is to allow an initiator to find the
targets to which it has access, and at least one address at which
each target may be accessed. This should generally be done using as
little configuration as possible. The iSCSI discovery mechanisms
listed here only deal with target discovery and one still needs
to use the SCSI protocol for LUN discovery. In order for an iSCSI
initiator to establish an iSCSI session with an iSCSI target, the
initiator needs the IP address, TCP port number and iSCSI target name information.

iSCSI supports the following discovery mechanisms:

a. Static Configuration: This mechanism assumes that the IP address,
TCP port and the iSCSI target name information are already
available to the initiator. The initiators need to perform no
discovery in this approach. The initiator uses the IP address and
the TCP port information to establish a TCP connection, and it
uses the iSCSI target name information to establish an iSCSI
session. This discovery option is convenient for small iSCSI
setups.

b. SendTargets: This mechanism assumes that the target’s IP address
and TCP port information are already available to the initiator.
The initiator then uses this information to establish a discovery
session to the Network Entity (IP address). The initiator then subsequently issues the SendTargets text command to query
information about the iSCSI targets available at the particular
Network Entity (IP address).

c. Zero-Configuration: This mechanism assumes that the initiator does
not have any information about the target. In this option, the
initiator can either multicast discovery messages directly to the
targets or it can send discovery messages to storage name servers.
Currently, the main discovery frameworks available are
SLP and iSNS. (Not supported in the first release of ESX 3.)]]>