<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
adam bultman wrote:
<blockquote cite="mid:509BFC44.7090602@glaven.org" type="cite">
<pre wrap="">On 11/08/2012 09:15 AM, Jim Ockers wrote:
</pre>
<blockquote type="cite">
<pre wrap="">That said, the VMDKs for startup disks do need to be on a VMFS5 (or
VMFS3) formatted datastore. The secondary/tertiary disks (which in our
case are individual iSCSI targets) can be formatted however the guest
OS wants, because the block device is passed directly through from the
ESX iSCSI initiator into the guest OS as a plain disk, which it can
format however it wants.
</pre>
</blockquote>
<pre wrap=""><!---->Huh? Can you define "startup disk?" Are you referring to the HDD that
the server and ESXi boots from, or the VM? VMs can boot from whatever
they want; but ESXi can PXE boot, if you set them up to.
</pre>
</blockquote>
The ESX server boots from whatever it wants, of course.<br>
<br>
We find it's most convenient for VMs to boot from a "startup disk"
which is located on a VMware datastore and is typically a VMDK. Yes
there are lots of other alternatives, but what I was getting at is that
it is most convenient for VMs to boot from a VMDK on a VMFS datastore.<br>
<blockquote cite="mid:509BFC44.7090602@glaven.org" type="cite">
<blockquote type="cite">
<pre wrap="">The workflow for moving a VM between ESX servers manually is pretty
easy and quick, since all our storage and all VMware datastores are on
iSCSI targets from an OpenFiler. We haven't invested in the vMotion
wizzy stuff that lets you migrate VMs without shutting them down,
because we don't feel we need it at this point.
</pre>
</blockquote>
<pre wrap=""><!---->
vMotion is snazzy. We have an Enterprise Plus license, and I just
migrated our VMs (280+) from our older, HP blade infrastructure (40+
blades, two locations) to newer Cisco UCS infrastructure (16 blades, two
locations) by simply vmotioning them over. And host profiles make
provisioning new ESXi hosts a breeze in comparison.
</pre>
</blockquote>
I guess you know a lot more about this than I do. One thing I noticed
is that in our environment we have 5 different networks (IP address
ranges) and our ESX servers participate in those (so that VMs have
access to them). When moving VMs I find I have to re-choose the VM
Network from the connections picklist because they may be in different
orders and have different network names between different servers. I
guess if you have vMotion then you have to have the discipline to cable
each ESX server the same and also name the networks the same on each
ESX host? I was wondering how you make sure the network connections
work the same from one ESX server to another.<br>
<blockquote cite="mid:509BFC44.7090602@glaven.org" type="cite">
<pre wrap="">
I will say this: The CLI on ESXi is veeeery minimal. The CLI on ESX was
much more fully featured. A large amount of my work on our vSphere 4.0
(ESX) hosts was done via the CLI, but with ESXi, I am a lot more limited
there, and am forced to use the gui. However, there is a toolkit that
lets you use powershell (or perl, I think, too) to issue commands.
Which is nice.
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Jim Ockers, P.E., P.Eng. (<a class="moz-txt-link-abbreviated" href="mailto:ockers@ockers.net">ockers@ockers.net</a>)
Contact info: <a class="moz-txt-link-freetext" href="http://www.ockers.net/">http://www.ockers.net/</a>
</pre>
</body>
</html>