http://technet.microsoft.com/en-us/systemcenter/hh278293Well, I wouldn't use a 1TB as the range, but let's use your example and say we doubled all of our expected minimums.
Then you have all the flexibility that you pointed out before. *>>Now, in order to know the max my virtuals might take, I have to look at each host store, find all of the virtual machines with VHD files on that store, then figure out each virtual’s drive letter for that VHD (is that even possible?), then add up all the file system sizes. * Why do you have to do that? I'd expect that you'd be using something like System Center VM Manager<http://technet.microsoft.com/en-us/systemcenter/hh278293>to manage your virtual hosts and give you a comprehensive view of storage consumption, utilization, etc. Right? *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker>* **Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market…*** On Mon, Jan 7, 2013 at 3:33 PM, Ken Cornetet <ken.corne...@kimball.com>wrote: > How do you “manage your capacity properly”? I’m not being facetious – I > really want to know since it looks like we are switching to HyperV.**** > > ** ** > > Microsoft’s recommendation is to create thin disks for more than you ever > think you need. Then, when creating the OS, use disk manager to create the > file system with the minimum you can get by with. This allows the VHD file > to only grow up to the size of the file system it contains.**** > > ** ** > > Then, if a virtual’s file system runs out of space, you can use storage > management to extend the disk into some the free space you allocated in the > VHD file. This allows you to have room for expansion, but keeps any one > virtual from exhausting free physical disk.**** > > ** ** > > For example: Let’s say we need a SQL server. We think we can get by with > the following disks:**** > > C: - 40GB (os)**** > > D: - 30GB (logs)**** > > E: - 100GB (data)**** > > ** ** > > Microsoft is telling us to create thin disks of, say, 1TB each. However, > when we install the OS, we create NTFS file systems on each disk with the > desired sizes of 40GB, 30GB, and 100GB. We now know that in the current > state, this virtual can only grow its thin disks to a total of 170GB. If > the E: runs out of space, we can use disk manager to extend the NTFS file > system, which will grow the thin disk up to the new NTFS file system size. > This gives you the ability to easily grow disks at will, but prevents any > one virtual from hogging all the free host disk.**** > > ** ** > > This sort of seems reasonable, but it complicates disk management > immensely. Now, in order to know the max my virtuals might take, I have to > look at each host store, find all of the virtual machines with VHD files on > that store, then figure out each virtual’s drive letter for that VHD (is > that even possible?), then add up all the file system sizes. Seems like a > lot of work, even if you script it up.**** > > ** ** > > **** > > *From:* Andrew S. Baker [mailto:asbz...@gmail.com] > *Sent:* Monday, January 07, 2013 12:08 PM > > *To:* NT System Admin Issues > *Subject:* Re: Time sync**** > > ** ** > > Yes, over subscribing can be an issue if you don't manage your capacity > properly.**** > > ** ** > > It hasn't proved to be an issue in any of the environments where I have > been.**** > > **** > > **** > > *ASB > **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker>* > **Providing Virtual CIO Services (IT Operations & Information Security) > for the SMB market…***** > > **** > > ** ** > > On Mon, Jan 7, 2013 at 11:35 AM, Ken Cornetet <ken.corne...@kimball.com> > wrote:**** > > Thin provisioning seems risky to me. Seems like you are always in danger > of non-critical virtuals deciding to use more disk space thus exhausting > physical space which would cause critical VMs to pause if they happen to > need more space. > > We tried thin provisioning back in the old VirtualServer days, and I ran > into this problem a few times.**** > > > -----Original Message----- > From: Michael B. Smith [mailto:mich...@smithcons.com] > Sent: Monday, January 07, 2013 10:28 AM > To: NT System Admin Issues**** > > Subject: RE: Time sync > > Because the overhead associated with dynamic disks in Hyper-V v3 is in the > very low single digits. We don't spend any time on this process, thin > provisioning still works seamlessly, and we get on with our lives. > > :) > > -----Original Message----- > From: Ken Cornetet [mailto:ken.corne...@kimball.com]**** > > Sent: Monday, January 7, 2013 10:06 AM > To: NT System Admin Issues**** > > Subject: RE: Time sync > > We are running ESX 5. To conserve SAN storage, we provision virtuals with > the bare minimum needed disk space because it is so easy to extend disks > later (extend the VMDK in VMWare, extend in Windows, done). No down time, > and no wasted disk. We don't have to spend a lot of time trying to > anticipate how big the disks will get and wasting disk if we guess too high. > > In HyperV, you can't extend disks without shutting down the virtual - > seriously. > > I can't for the life of me figure out why MS isn't fixing this instead of > adding silly features like 4TB of guest RAM. And, I also wonder why HyperV > users aren't howling about this. > > -----Original Message----- > From: Michael Leone [mailto:oozerd...@gmail.com] > Sent: Monday, January 07, 2013 9:43 AM > To: NT System Admin Issues > Subject: Re: Time sync > > On Mon, Jan 7, 2013 at 8:31 AM, Ken Cornetet <ken.corne...@kimball.com> > wrote: > > Lol, how many times do you need 64 vCPUs or 4TB of guest Ram versus > > needing to extend a disk? > > I run VMware ESXi 5.0, and I know I have had to extend a disk any number > of times. And Win2008 makes extending the boot disk so much easier, too. > > My largest VM has 16G of RAM, and I was even leery of that. And I have > 6 hosts with 512G RAM each ...**** > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
