<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: VMware Lab Manager Design Considerations</title>
	<atom:link href="http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/</link>
	<description>The weblog of an IT pro specializing in virtualization, storage, and servers</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:13:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Jon</title>
		<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/comment-page-1/#comment-50919</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Thu, 09 Jun 2011 17:53:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1678#comment-50919</guid>
		<description>Re: &quot;Lab Manager 4 can’t use vSphere’s thin provisioning for disks – Lab Manager uses the concept of Linked Clones for copies of virtual machines.  The first one in the chain is “thick”.

This is incorrect.  The first disk can be thinly provisioned.  Newer versions of Lab Manager will also allow for any clone of a thin disk to also be thinly provisioned.

RE: Increase the Service Console on ESX/vSphere servers from 272MB to 800MB

I would also increase your COW value for older versions of ESX (default of 32), and set it to the max.

RE: VMware is now supporting and suggesting that you run the Lab Manager 4 server in a virtual machine.

It&#039;s always been supported as a VM, and I personally prefer it that way for management purposes.  In larger deployments, you would typically have a Management Cluster (holding Lab Manager Server, vCenter server, Domain functions (AD,DNS,etc).  This is where the Lab Manager server would be placed.</description>
		<content:encoded><![CDATA[<p>Re: &#8220;Lab Manager 4 can’t use vSphere’s thin provisioning for disks – Lab Manager uses the concept of Linked Clones for copies of virtual machines.  The first one in the chain is “thick”.</p>
<p>This is incorrect.  The first disk can be thinly provisioned.  Newer versions of Lab Manager will also allow for any clone of a thin disk to also be thinly provisioned.</p>
<p>RE: Increase the Service Console on ESX/vSphere servers from 272MB to 800MB</p>
<p>I would also increase your COW value for older versions of ESX (default of 32), and set it to the max.</p>
<p>RE: VMware is now supporting and suggesting that you run the Lab Manager 4 server in a virtual machine.</p>
<p>It&#8217;s always been supported as a VM, and I personally prefer it that way for management purposes.  In larger deployments, you would typically have a Management Cluster (holding Lab Manager Server, vCenter server, Domain functions (AD,DNS,etc).  This is where the Lab Manager server would be placed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/comment-page-1/#comment-50737</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Wed, 27 Apr 2011 17:39:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1678#comment-50737</guid>
		<description>I&#039;m trying to clean up an existing install of Labmanager and this is precisely what I was looking for.</description>
		<content:encoded><![CDATA[<p>I&#8217;m trying to clean up an existing install of Labmanager and this is precisely what I was looking for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Johns</title>
		<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/comment-page-1/#comment-47051</link>
		<dc:creator>John Johns</dc:creator>
		<pubDate>Tue, 15 Dec 2009 19:56:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1678#comment-47051</guid>
		<description>I am looking for help in the HW design aspect of Lab Manager.  I have been searching for the appropriate ratios for both Memory and Processor oversubscription.  I have seen conflicting information on the memory, I have seen where you should be able to see as high as 2:1 memory oversubscription and I have also seen that memory oversubscription is not recommended by some.  I have yet to see any &quot;standard&quot; ratios for processor oversubscription.

Any help or direction is greatly appreciated.  

Thanks,  John</description>
		<content:encoded><![CDATA[<p>I am looking for help in the HW design aspect of Lab Manager.  I have been searching for the appropriate ratios for both Memory and Processor oversubscription.  I have seen conflicting information on the memory, I have seen where you should be able to see as high as 2:1 memory oversubscription and I have also seen that memory oversubscription is not recommended by some.  I have yet to see any &#8220;standard&#8221; ratios for processor oversubscription.</p>
<p>Any help or direction is greatly appreciated.  </p>
<p>Thanks,  John</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hphuhtin</title>
		<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/comment-page-1/#comment-46291</link>
		<dc:creator>hphuhtin</dc:creator>
		<pubDate>Thu, 22 Oct 2009 11:19:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1678#comment-46291</guid>
		<description>Revisit the Lab Manager use guide on groups. You do not need to use Lab Manager groups. Instead, you manage groups in your LDAP and map these groups the the Organizations in Lab Manager.</description>
		<content:encoded><![CDATA[<p>Revisit the Lab Manager use guide on groups. You do not need to use Lab Manager groups. Instead, you manage groups in your LDAP and map these groups the the Organizations in Lab Manager.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hphuhtin</title>
		<link>http://blog.scottlowe.org/2009/10/04/vmware-lab-manager-design-considerations/comment-page-1/#comment-46232</link>
		<dc:creator>hphuhtin</dc:creator>
		<pubDate>Sat, 17 Oct 2009 07:47:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1678#comment-46232</guid>
		<description>About having no groups - the &quot;Organizations&quot; in Lab Manager are quite close to having groups. A user or group can belong to an organization, and organization can have quotas defined for it. Something I haven&#039;t gotten around to finding out yet is how it works if a user belongs to multiple organizations.

And LM as a VM? I don&#039;t see any problem with this, just don&#039;t run it under Lab Manager control, and in a separate datastore. I wouldn&#039;t worry about this more than about running the VC as a VM.

Some of my other ideas: as Lab Manager burdens the datastore with lots and lots of open VMDK&#039;s, this might be a case where putting the VM swap on the ESX host local datastore might be a good idea. All that swapping load removed.

Also, increasing the logical unit IO queues seems obvious. We run ~120 VMs in one datastore which just feels all wrong when you compare to traditional virtual infrastructure design.</description>
		<content:encoded><![CDATA[<p>About having no groups &#8211; the &#8220;Organizations&#8221; in Lab Manager are quite close to having groups. A user or group can belong to an organization, and organization can have quotas defined for it. Something I haven&#8217;t gotten around to finding out yet is how it works if a user belongs to multiple organizations.</p>
<p>And LM as a VM? I don&#8217;t see any problem with this, just don&#8217;t run it under Lab Manager control, and in a separate datastore. I wouldn&#8217;t worry about this more than about running the VC as a VM.</p>
<p>Some of my other ideas: as Lab Manager burdens the datastore with lots and lots of open VMDK&#8217;s, this might be a case where putting the VM swap on the ESX host local datastore might be a good idea. All that swapping load removed.</p>
<p>Also, increasing the logical unit IO queues seems obvious. We run ~120 VMs in one datastore which just feels all wrong when you compare to traditional virtual infrastructure design.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

