Author: buildbot
Date: Mon Dec 10 19:12:41 2012
New Revision: 841497
Log:
Staging update by buildbot for vcl
Modified:
websites/staging/vcl/trunk/content/ (props changed)
websites/staging/vcl/trunk/content/docs/vmwareconfiguration.html
Propchange: websites/staging/vcl/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Dec 10 19:12:41 2012
@@ -1 +1 @@
-1419673
+1419674
Modified: websites/staging/vcl/trunk/content/docs/vmwareconfiguration.html
==============================================================================
--- websites/staging/vcl/trunk/content/docs/vmwareconfiguration.html (original)
+++ websites/staging/vcl/trunk/content/docs/vmwareconfiguration.html Mon Dec 10
19:12:41 2012
@@ -78,29 +78,28 @@
<div id="content">
<h1 class="title">VMware Configuration</h1>
- <h2 id="vmware-configuration">VMware Configuration</h2>
-<p><strong>Terminology</strong></p>
-<p><strong>VM Host</strong></p>
+ <h2 id="terminology">Terminology</h2>
+<h4 id="vm-host">VM Host</h4>
<ul>
<li>A VM host is a physical computer running a VMware hypervisor</li>
<li>A VCL computer entry must be added for each VM host (Manage Computers >
Edit Computer Information)</li>
<li>After the computer has been added to VCL, it is designated as a VM host by
changing the computer state to vmhostinuse (Manage Computers > Computer
Utilities)</li>
</ul>
-<p><strong>VM</strong></p>
+<h4 id="vm">VM</h4>
<ul>
<li>A VM is a virtual machine managed by VCL</li>
<li>A computer entry must be added to VCL for each VM (Manage Computers >
Edit Computer Information)</li>
<li>Each VM must be assigned to a VM host (Virtual Hosts > VM Hosts tab
> Configure Host)</li>
<li>VMs do not need to be created manually in VMware, VCL automatically
creates and deletes VMs</li>
</ul>
-<p><strong>VM Host Profile</strong></p>
+<h4 id="vm-host-profile">VM Host Profile</h4>
<ul>
<li>A VM host profile contains several parameters which describe how a VM host
is configured so that VCL knows how to manage it</li>
<li>Each VM host is assigned a VM host profile</li>
<li>A VM host profile may be assigned to multiple VM hosts if they are
configured identically</li>
<li>VM host profiles may be added or modified via Virtual Hosts > VM Host
Profiles tab</li>
</ul>
-<p><strong>VMware Products Supported</strong></p>
+<h4 id="vmware-products-supported">VMware Products Supported</h4>
<ul>
<li>VMware Server 2.x</li>
<li>VMware ESX 3.5 - 4.x</li>
@@ -108,7 +107,7 @@
<li>VMware ESXi 5.x</li>
</ul>
<hr />
-<p><strong>VM Host Management Options</strong></p>
+<h2 id="vm-host-management-options">VM Host Management Options</h2>
<p>The VCL management node must be able to control the VM host and the VMs
running on it. VMware provides several different ways of doing this. VCL
currently supports the following methods for remote VM host management:</p>
<ul>
<li>VMware vSphere SDK</li>
@@ -116,10 +115,10 @@
</ul>
<p>The vSphere SDK can only be used if management is not restricted due to the
VMware license key installed on the host. This mainly affects hosts running
the free version of ESXi. Remote management using any of the methods supported
by VMware is restricted once a free license key is entered.</p>
<p>If remote management is restricted, the VM host can be managed if SSH is
enabled on it. VCL will execute vim-cmd and other commands on the VM host via
SSH. </p>
-<p><strong>How to enable SSH on the VM host:</strong></p>
-<p><em>VMware Server 2.x</em></p>
+<h2 id="how-to-enable-ssh-on-the-vm-host">How to enable SSH on the VM
host:</h2>
+<h4 id="vmware-server-2x">VMware Server 2.x</h4>
<p>Enable the SSH daemon and configure identity key authentication according
to the underlying VM host OS</p>
-<p><strong>ESX/ESXi 3.5 & 4.0</strong></p>
+<h4 id="esxesxi-35-40">ESX/ESXi 3.5 & 4.0</h4>
<ul>
<li>Connect to the console of the ESX/ESXi host</li>
<li>Press ALT-F1 - you should see a black screen with the VMware product name
at the top</li>
@@ -133,7 +132,7 @@
<li>You should see a line that looks like: 5065 5065 busybox inetd</li>
<li>Kill the process (enter the PID from the output of the previous command):
kill -HUP 5065</li>
</ul>
-<p><strong>ESXi 4.1</strong></p>
+<h4 id="esxi-41">ESXi 4.1</h4>
<p>Beginning with ESXi 4.1, SSH can be enabled using the vSphere Client:</p>
<ul>
<li>Select the ESXi host</li>
@@ -146,7 +145,7 @@
<li>Click Start</li>
<li>Click OK</li>
</ul>
-<p><strong>ESX 5.0</strong></p>
+<h4 id="esx-50">ESX 5.0</h4>
<p>In the case of ESX 5.0:</p>
<ul>
<li>Select the ESXi host</li>
@@ -159,7 +158,7 @@
<li>Click OK</li>
</ul>
<hr />
-<p><strong>How to configure ESX/ESXi to use SSH identity key
authentication:</strong></p>
+<h3 id="how-to-configure-esxesxi-to-use-ssh-identity-key-authentication">How
to configure ESX/ESXi to use SSH identity key authentication:</h3>
<p>SSH identity key authentication must be configured if SSH is used to manage
the VM host.</p>
<ul>
<li>
@@ -206,8 +205,150 @@
<p>IMPORTANT: Under ESXi 4.x, the authorized_keys file is erased when the ESXi
VM host is rebooted. Complete the following steps to make the authorized_keys
file persistent:</p>
<p><em>Note</em>: VCL will perform these steps automatically when the 1st
reservation assigned to the host is processed.</p>
<ul>
-<li>Create a compressed tarball file containing the /.ssh directory:</li>
+<li>
+<p>Create a compressed tarball file containing the /.ssh directory:</p>
+<div class="codehilite"><pre> <span class="n">tar</span> <span
class="o">-</span><span class="n">C</span> <span class="sr">/ -czf
bootbank/</span><span class="n">vcl</span><span class="o">.</span><span
class="n">tgz</span> <span class="o">.</span><span class="n">ssh</span>
+</pre></div>
+
+
+</li>
+<li>
+<p>Edit the /bootbank/boot.cfg file and append ' --- <strong>vcl.tgz</strong>'
to modules line as shown in the following example:</p>
+<div class="codehilite"><pre> <span class="n">kernel</span><span
class="o">=</span><span class="n">b</span><span class="o">.</span><span
class="n">z</span>
+ <span class="n">kernelopt</span><span class="o">=</span>
+ <span class="n">modules</span><span class="o">=</span><span
class="n">k</span><span class="o">.</span><span class="n">z</span> <span
class="err">â</span> <span class="n">s</span><span class="o">.</span><span
class="n">z</span> <span class="err">â</span> <span class="n">c</span><span
class="o">.</span><span class="n">z</span> <span class="err">â</span> <span
class="n">oem</span><span class="o">.</span><span class="n">tgz</span> <span
class="err">â</span> <span class="n">license</span><span
class="o">.</span><span class="n">tgz</span> <span class="err">â</span> <span
class="n">m</span><span class="o">.</span><span class="n">z</span> <span
class="err">â</span> <span class="n">state</span><span
class="o">.</span><span class="n">tgz</span> <span class="err">â</span> <span
class="n">vcl</span><span class="o">.</span><span class="n">tgz</span>
+ <span class="n">build</span><span class="o">=</span><span
class="mf">4.1.0</span><span class="o">-</span><span class="mi">260247</span>
+ <span class="n">updated</span><span class="o">=</span><span
class="mi">2</span>
+ <span class="n">bootstate</span><span class="o">=</span><span
class="mi">0</span>
+
+ <span class="o">::</span><span class="p">:</span><span
class="n">BashLexer</span>
+ <span class="n">Optionally</span> <span class="n">you</span> <span
class="n">can</span> <span class="n">run</span> <span class="n">the</span>
<span class="n">following</span> <span class="n">two</span> <span
class="n">commands:</span>
+ <span class="n">tar</span> <span class="o">-</span><span
class="n">C</span> <span class="o">/</span> <span class="o">-</span><span
class="n">czf</span> <span class="n">vcl</span><span class="o">.</span><span
class="n">tgz</span> <span class="o">.</span><span class="n">ssh</span>
+ <span class="n">BootModuleConfig</span><span class="o">.</span><span
class="n">sh</span> <span class="o">--</span><span class="n">add</span><span
class="o">=</span><span class="n">vcl</span><span class="o">.</span><span
class="n">tgz</span> <span class="o">--</span><span class="n">verbose</span>
+</pre></div>
+
+
+</li>
+</ul>
+<h2 id="vm-host-profile-parameters">VM Host Profile Parameters</h2>
+<h3 id="general-parameters">General Parameters</h3>
+<h4 id="name">Name</h4>
+<ul>
+<li>Descriptive name of the VM host profile</li>
+</ul>
+<h4 id="type-deprecated">Type (deprecated)</h4>
+<ul>
+<li>Removed in VCL 2.3</li>
+</ul>
+<h4 id="image-optional">Image (optional)</h4>
+<ul>
+<li>
+<p>VCL hypervisor image installed on VM host computers using xCAT</p>
+<ul>
+<li>xCAT is not required. VM host computers may be installed manually or by
some other means.</li>
+</ul>
+</li>
+<li>
+<p>If xCAT is not used, select "No Image"</p>
+</li>
+<li>VCL has the ability to install a hypervisor image on bare-metal computers
using xCAT. If the image property is configured, the image is installed when a
computer's state is changed to vmhostinuse via Manage Computers > Computer
Utilities</li>
+</ul>
+<h4 id="usernamepassword-optional">Username/Password (optional)</h4>
+<ul>
+<li>Name and password of the administrative or root user residing on the VM
host</li>
+<li>This account is used to manage the VM host and VMs assigned to the
host</li>
+<li>The username and password are currently only used if the vSphere SDK is
used to manage the VM host and VMs</li>
+</ul>
+<h4 id="storage-parameters">Storage Parameters</h4>
+<p>Resource Path (optional)
+Resource Path only needs to be configured if VMware vCenter is used. It
defines the location where VMs will be created in the vCenter inventory tree.
The inventory tree contains at least one Datacenter, and may also contain
Folders, Clusters, and Resource Pools.
+Example: /DatacenterA/Folder1/Cluster2/ResourcePool3</p>
+<h4 id="repository-path-optional">Repository Path (optional)</h4>
+<ul>
+<li>Path where master copies of images are stored which are used to transfer
images to VM host datastores or to other repositories:</li>
+<li>If a reservation is assigned to a host but the image does not exist in
that host's datastore, it is copied from the repository to the virtual disk
path when the VM is loaded</li>
+<li>If the VCL environment contains multiple management nodes and the image
does not exist in the repository or the host's datastore, the image will be
retrieved from another management node's repository by copying it via SCP</li>
+<li>The Repository Path parameter does not need to be configured if the VCL
environment contains a single management node and all VM hosts share the same
Virtual Disk Path</li>
+<li>Example: /vmfs/volumes/nfs-repository1</li>
+<li>VMs do not run directly off of the images stored in the repository</li>
+<li>Setting the Repository Path parameter determines whether or not an
additional copy of an image is created when an image is captured</li>
+<li>If repository path is not configured then only a single copy of the image
will exist in the virtual disk path after an image is captured</li>
+<li>If repository path is configured then two copies of the image will exist
after an image is captured - one in the virtual disk path and one in the
repository</li>
+<li>Repository Path location can refer to and be mounted on either the
management node or VM host</li>
+<li>It is highly recommended that the repository be mounted on the VM host<ul>
+<li>When mounted on the VM host, vmdk operations can be done directly on the
VM host in a single step</li>
+</ul>
+</li>
+<li>Images in the repository are stored in the 2 GB sparse vmdk format</li>
+<li>The size of the vmdk files will approximately be equal to the amount of
actual data saved in the image regardless of the size of the VM's hard
drive</li>
+<li>Storing images in the 2 GB sparse format is necessary to allow images to
be transferred via SCP without having to transfer data equal to the entire size
of the VM's hard drive</li>
+</ul>
+<h4 id="repository-image-type">Repository Image Type</h4>
+<p>Virtual disk file format for images stored in the repository.</p>
+<h4 id="virtual-disk-path-previously-datastore-path">Virtual Disk Path
(previously Datastore Path)</h4>
+<ul>
+<li>Location where master copies of images are stored which are used by
running VMs</li>
+<li>Example: /vmfs/volumes/nfs-datastore1
+ For ESXi, the path configured in the profile may simply be the short
datastore name as it appears in the vSphere Client: nfs-datastore1</li>
+<li>Storage location should be large enough to store all of the images which
may be loaded on the VM host (from 100's of GB to several TB)</li>
+<li>VCL creates a directory for each image in the Virtual Disk Path</li>
+<li>Images are stored in the vmfs thin vmdk format</li>
+<li>Virtual Disk Path may either reside on local or network storage</li>
+<li>Multiple VM hosts can share the same datastore if network storage is
used<ul>
+<li>A single datastore may be used by all VM hosts if performance is
adequate</li>
+<li>Multiple VMs on different hosts may access the same Virtual Disk Path
image at the same time</li>
+<li>It is recommended that datastores are shared among hosts so that fewer
copies of each image have to be stored</li>
+<li>The underlying storage hardware and network connectivity from the hosts to
the storage must be adequate</li>
+<li>Storage where the datastore is located should be optimized for read
performance</li>
+</ul>
+</li>
+<li>VCL configures VMs to access images stored in the Virtual Disk Path in
read-only mode<ul>
+<li>Changes made to the VM's hard drive are written to delta files located in
the VM Working Directory Path dedicated for the VM</li>
+</ul>
+</li>
+</ul>
+<h4 id="virtual-disk-image-type">Virtual Disk Image Type</h4>
+<p>Virtual disk file format for images stored in the virtual disk path.</p>
+<h4 id="virtual-disk-mode-previously-vm-disk">Virtual Disk Mode (previously VM
Disk)</h4>
+<ul>
+<li>Defines whether the storage where the VM host's Virtual Disk Path resides
is dedicated to a single host or shared among multiple hosts:</li>
+<li>dedicated (previously localdisk)<ul>
+<li>The VM host's Virtual Disk Path is located on local disks or dedicated
network storage</li>
+<li>The VM host is the only host which accesses the Virtual Disk Path</li>
+<li>Repository Path must be configured</li>
+</ul>
+</li>
+<li>
+<p>shared (previously networkdisk)</p>
+<ul>
+<li>The VM host's Virtual Disk Path is located on network storage which is
shared by other VM hosts</li>
+<li>Repository Path is optional</li>
+</ul>
+<p>The Virtual Disk Mode (VM Disk) parameter does not determine whether or not:
+...images are copied from the datastore to the repository during image capture
+...images are copied from the repository to the datastore during image load
+These are determined by whether or not Repository Path is configured in the
profile</p>
+</li>
+</ul>
+<h4 id="vm-working-directory-path-optional-previously-vm-path">VM Working
Directory Path (optional) (previously VM Path)</h4>
+<ul>
+<li>Defines path on VM host where VM working directories will reside (contains
.vmx, delta, .vswp, nvram files)</li>
+<li>If not configured, the Virtual Disk Path location will be used</li>
+<li>VCL creates a directory under the VM Working Directory Path for each VM it
creates<ul>
+<li>Contains the .vmx file which defines the VM</li>
+<li>Contains delta vmdk files which are written to as changes are made to the
VM's hard drive</li>
+</ul>
+</li>
+<li>VM Working Directory Path may either reside on local or network
storage</li>
+<li>Location should be dedicated for each VM host<ul>
+<li>Multiple VM hosts should not share the same VM Working Directory Path
location for performance and image safety reasons</li>
+<li>VM Working Directory Paths of multiple hosts may reside on the same volume
but a subdirectory should be created for each host</li>
+</ul>
+</li>
+<li>Storage where the VM Working Directory Path is located should be optimized
for read-write performance</li>
</ul>
+<h4 id="networking-parameters">Networking Parameters</h4>
+<p>VM Network (previously Virtual Switch)</p>
</div>
<div id="footer">
