| Author | Messages | |
sbradcpa
Posts:299
 | | 07/16/2008 8:32 PM |
| The Blade config that HP is showcasing for this is a blade storage unit
on wheels.
http://h18004.www1.hp.com/products/blades/components/enclosures/c-class/c3000/comparison.html
EBS goes up to 300.
Al Mulnick wrote:
> I'd like to hear the medium / large business case. A small case like
> that might be of interest, but I wouldn't consider a DC in that
> scenario. I'd consider SBS as Susan mentions. Once I did that,
> virtualizing or no, I'm more likely to have my DC be the host that
> then hosts the other virtuals. My only remaining issue then is the
> physical issue and recoverability. To be honest, I'm not interested in
> recovering *that* DC though. One is enough. And I don't want to
> virutalize it just for recoverability. That issue has been around for
> years (due to system state) and personally find it worth the
> investment to have the DC not virtualized. It is also worth it to
> have at least one DC be dedicated even in that environment for
> recovery puproses.
>
>
> I don't find the case for Blade and server room environmentals
> investment in a 100 person environment always a straightforward case
> either, if that helps 
>
>
>
>
> On Wed, Jun 11, 2008 at 11:44 PM, Susan Bradley, CPA aka Ebitz - SBS
> Rocks [MVP] <sbradcpa@pacbell.net <mailto:sbradcpa@pacbell.net>> wrote:
>
> We are ssooo virtualizing SBS boxes because it means we are no
> longer tied to the physical hardware with bare metal restores
> problems and issues.
>
> EBS on HP's blades are expected to put out a virtualized platform
> as well.
>
>
>
>
> Brandon Shell wrote:
>> 1) I am a small business that has two offices with 2 servers in each
>> office. Only about 100 users per office.
>>
>> A) I can either waste an entire machine as a WAY over powered DC and
>> shove everything that is left on the other machine. Killing any
>> ability to provide site local fault tolerance.
>>
>> B) I can make both machines VMHost and partition my hardware.
>>
>> Which do you choose?
>>
>> I have a large BO scenario as well if you like.
>>
>>
>>
>> On 6/11/08, Al Mulnick <amulnick@gmail.com> <mailto:amulnick@gmail.com> wrote:
>>
>>> Such as?
>>>
>>> On Wed, Jun 11, 2008 at 7:41 PM, Brandon Shell <tshell@gmail.com> <mailto:tshell@gmail.com> wrote:
>>>
>>>
>>>> I still do not think it is right to categorically say it is bad to
>>>> virtualize a DC.
>>>>
>>>> There are times when it is not only ok, but recommended.
>>>>
>>>> On Wed, Jun 11, 2008 at 7:29 PM, Al Mulnick <amulnick@gmail.com> <mailto:amulnick@gmail.com> wrote:
>>>>
>>>>
>>>>> You may as well bring up the security implications while you're there.
>>>>>
>>>>> Thanks for the interesting discussion to all, I'm now firmly back with
>>>>> the
>>>>> mindset that virtualizing a DC is a bad idea. I'll even go joe one
>>>>> better
>>>>> and say that virtualizing a rodc just because I can is not going to make
>>>>> me
>>>>> happy. I'd better have a great reason for doing so, although the risk is
>>>>> much more diminished.
>>>>>
>>>>> The risks to this type of system would still preclude me from
>>>>> recommending
>>>>> such an architecture regardless of my good experience with virtualization
>>>>> (vendor really doesn't matter to me as it is really not the bits, but the
>>>>> architecture that introduces the risks in my mind) to date.
>>>>>
>>>>> Truth is, I've had similar experience to what joe mentions - half baked
>>>>> thoughts and work go into the architecture to the point that I cannot
>>>>> guarantee with turnover and other factors "that just happen" that the
>>>>> virtualization architecture will protect the AD investment well enough to
>>>>> make it a good idea to virtualize a DC. The exception of course is the
>>>>> rodc
>>>>> which by definition would warrant the hardware, heating, and other
>>>>> environmental efficiencies I could gain by virtualizing without having
>>>>> the
>>>>> same risks associated with malicious physical access.
>>>>>
>>>>> Time settings aside of course. I would fully expect that a virtualization
>>>>> company would have other thoughts on what could and could not be
>>>>> virtualized
>>>>> and what should and should not be as well. In the past virtualization has
>>>>> been contentious as a matter of fact, to the point that I have to
>>>>> consider
>>>>> vendor support for virtualizing their products in my risk profile.
>>>>>
>>>>> Useful thread.
>>>>>
>>>>> On Wed, Jun 11, 2008 at 5:43 PM, Susan Bradley, CPA aka Ebitz - SBS Rocks
>>>>> [MVP] <sbradcpa@pacbell.net> <mailto:sbradcpa@pacbell.net> wrote:
>>>>>
>>>>>
>>>>>> Center for Internet Security - VM Benchmarks:
>>>>>> http://www.cisecurity.org/bench_vm.html
>>>>>>
>>>>>> Along with paranoia.
>>>>>>
>>>>>> Gabrie wrote:
>>>>>>
>>>>>>
>>>>>>> Ok, so can we agree that if we have a good virtual design and good
>>>>>>> admins responsible for the ESX environment, there is no problem
>>>>>>> virtualizing
>>>>>>> the DCs?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 10:53 PM, Wells, James Arthur
>>>>>>> <jw1@bcm.tmc.edu <mailto:jw1@bcm.tmc.edu><mailto:
>>>>>>> jw1@bcm.tmc.edu> <mailto:jw1@bcm.tmc.edu>> wrote:
>>>>>>>
>>>>>>> "And ofcourse, when implemented bad, you won't be happy with it.
>>>>>>> But isn't this true for a bad AD implementation?"
>>>>>>>
>>>>>>>
>>>>>>> Aaaah, and there's the rub…AD is pretty hard to break, out of the
>>>>>>> box. VMWare ESX? MUCH easier to do it badly.
>>>>>>>
>>>>>>> I find it much more common to see a bad ESX implementation (and
>>>>>>> require more expertise to do it RIGHT, on the
>>>>>>> server/infrastructure side). AD placed on a handful of physical
>>>>>>> hosts – not so much.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --James
>>>>>>>
>>>>>>>
>>>>>>> *From:* ActiveDir-owner@mail.activedir.org <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> [mailto:ActiveDir-owner@mail.activedir.org
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>] *On Behalf Of *Gabrie
>>>>>>> *Sent:* Wednesday, June 11, 2008 3:44 PM
>>>>>>>
>>>>>>> *To:* ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org>
>>>>>>> <mailto:ActiveDir@mail.activedir.org>
>>>>>>>
>>>>>>> *Subject:* Re: [ActiveDir] OT: Time Synchronization issue in
>>>>>>> Windows Server 2003 systems running as VMware Guests:
>>>>>>>
>>>>>>>
>>>>>>> Well, you shouldn't look at virtualization as all Eggs in one
>>>>>>> basket.
>>>>>>>
>>>>>>> Our datacenter now has 30 ESX hosts, 1 virtual center for
>>>>>>> management of those ESX hosts, 400+ VMs on it. Chances that I
>>>>>>> loose more then one, ok, maybe two esx hosts at one time are very
>>>>>>> low. All ESX hosts will keep on running even if virtual center
>>>>>>> would go down. Chances your virtualization layer goes down are
>>>>>>> very low. Only complete SAN failure could bring the complete
>>>>>>> environment down. All ESX hosts have at least 4 nics for just VM
>>>>>>> network traffic and those nics are spread over 2 physical
>>>>>>> switches. I don't aggree to "Eggs in one basket".
>>>>>>>
>>>>>>> As to the comments of joe. I do aggree with you about that it is
>>>>>>> much easier to mess things up. But I think it is also a little far
>>>>>>> fetched. In our environment we have granular permissions control.
>>>>>>> For example on Exchange, SQL and DC's the right to do anything
>>>>>>> with the VMs are limited to only the very experienced admins.
>>>>>>>
>>>>>>> When discussing virtualization, it is ofcourse very important to
>>>>>>> have a good design and good admins. I think virtualization, when
>>>>>>> implemented very well, is like your network infra. Its just there
>>>>>>> and you use it without having to think about it twice.
>>>>>>>
>>>>>>> And ofcourse, when implemented bad, you won't be happy with it.
>>>>>>> But isn't this true for a bad AD implementation?
>>>>>>>
>>>>>>> Gabrie
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 7:17 PM, Susan Bradley, CPA aka Ebitz -
>>>>>>> SBS Rocks [MVP] <sbradcpa@pacbell.net <mailto:sbradcpa@pacbell.net>
>>>>>>> <mailto:sbradcpa@pacbell.net>> wrote:
>>>>>>>
>>>>>>> Agreed on that. May I point out that when everything is
>>>>>>> virtualized on one piece of physical hardware .... that sounds an
>>>>>>> awful lot like a SBS box. Granted you've got separation of
>>>>>>> roles... but you don't have separation of risk of physical issues.
>>>>>>>
>>>>>>> President and Chairman of "Eggs in one basket", Inc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Steve K wrote:
>>>>>>>
>>>>>>> Sorry Susan, I was replying to Brandon's last comment, not yours.
>>>>>>> I was not trying to be confrontational, I was just trying to get
>>>>>>> people to think about the mad rush to make everything a VM.
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 12:59 PM, Susan Bradley, CPA aka Ebitz -
>>>>>>> SBS Rocks [MVP] <sbradcpa@pacbell.net <mailto:sbradcpa@pacbell.net>
>>>>>>> <mailto:sbradcpa@pacbell.net>> wrote:
>>>>>>>
>>>>>>> I didn't say "this" debate. But when someone says a debate is
>>>>>>> useless, chances are someone else did get something out of it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Steve K wrote:
>>>>>>>
>>>>>>> I would disagree with that assessment. I was asking if things
>>>>>>> should be done just because they can be done. We have different
>>>>>>> opinions on how the technology should be applied, but I am always
>>>>>>> open to new ways of thinking.
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 11:54 AM, Brandon Shell <tshell@gmail.com <mailto:tshell@gmail.com>
>>>>>>> <mailto:tshell@gmail.com>> wrote:
>>>>>>>
>>>>>>> Susan... I agree, but those weren't the questions asked. They have
>>>>>>> been just categorically yes or no.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 11:42 AM, Susan Bradley, CPA aka Ebitz -
>>>>>>> SBS Rocks [MVP] <sbradcpa@pacbell.net <mailto:sbradcpa@pacbell.net>
>>>>>>> <mailto:sbradcpa@pacbell.net>> wrote:
>>>>>>>
>>>>>>> But in this debate, fleshing out why there is a preference or
>>>>>>> opinion helps the rest of us to have a preference or opinion.
>>>>>>>
>>>>>>> Why? Size? Just because you are enterprise? Would you feel
>>>>>>> differently at a smaller scale?
>>>>>>>
>>>>>>> IMHO they aren't useless. Many times debates like these just make
>>>>>>> you aware that one is holding on to old fashioned values that
>>>>>>> aren't relevant anymore.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Brandon Shell wrote:
>>>>>>>
>>>>>>> IMO... the answer to this question is that it depends on the
>>>>>>> environment. I "personally" am completely comfortable virtualizing
>>>>>>> a DC if it fits, but of course it is not always the best option.
>>>>>>>
>>>>>>>
>>>>>>> These are useless debates because they are simply preference and
>>>>>>> opinion.
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 10:55 AM, Steve K <irish.bug@gmail.com <mailto:irish.bug@gmail.com>
>>>>>>> <mailto:irish.bug@gmail.com>> wrote:
>>>>>>>
>>>>>>> You keep on bringing up technical reasons for virtualizing
>>>>>>> everything. And you are correct, it can be technically done. But
>>>>>>> should it. Should you put every egg in one virtualized basket?
>>>>>>> What I am suggesting is that there are certain key components of
>>>>>>> the infrastructure that are better suited being physical devices.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 10:20 AM, Gabrie <thegabeman@gmail.com <mailto:thegabeman@gmail.com>
>>>>>>> <mailto:thegabeman@gmail.com>> wrote:
>>>>>>>
>>>>>>> Yep, it sure is the question WHY should you NOT virtualize a DC?
>>>>>>>
>>>>>>> I'm now in the middle of a project virtualizing 600 servers.
>>>>>>> Almost every application owner has his (or her) own reasons why
>>>>>>> this application / server cannot go virtual. It takes many talks
>>>>>>> before they allow us to go ahead. Until now we have 400 VMs
>>>>>>> running without problems (including SQL2005 VMs, Exchange 2007
>>>>>>> VMs), none of the potential pitfalls have come true.
>>>>>>> So why should you virtualize a DC? Well, I see no real reasons to
>>>>>>> say: This is WHY you should virtualize a DC. However, when already
>>>>>>> virtualizing that many systems, you should have realy good reasons
>>>>>>> to NOT virtualize the DCs. And I can't find those.
>>>>>>>
>>>>>>> Uptime / availibility is not an issue. When a ESX host should die,
>>>>>>> the VMs get restarted. If a DC is running on the failing ESX host,
>>>>>>> other DC's will pickup the DC function and the dead DC is
>>>>>>> immediately restarted on a running ESX host. Uptime will be better
>>>>>>> or at least equal to a standalone physical DC.
>>>>>>>
>>>>>>> Should a complete datacenter or SAN fail, then I can easily
>>>>>>> switch to my 2nd datacenter. (Tests have shown we need just 15min
>>>>>>> to connect to 2nd datacenter and be ready to restart all systems).
>>>>>>> We have a number of ESX hosts running there that are connected to
>>>>>>> SAN replica's. I can then connect to them and first start the most
>>>>>>> important servers like DNS, ADir (DC's).
>>>>>>>
>>>>>>> Are there technical reasons why not virtualize a DC? Well maybe
>>>>>>> you should pay real good attention to the timing issues, but I
>>>>>>> haven't seen them with any of my clients yet and our ESX hosts are
>>>>>>> realy loaded. (30+ VMs on one ESX host). If it turns out that a DC
>>>>>>> gets fewer resources then it is asking for, we're still able to
>>>>>>> assign guaranteed cpu / memory to it.
>>>>>>>
>>>>>>> Gabrie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 3:03 PM, Steve K <irish.bug@gmail.com <mailto:irish.bug@gmail.com>
>>>>>>> <mailto:irish.bug@gmail.com>> wrote:
>>>>>>>
>>>>>>> I guess the question isn't really can you virtualize a DC, but
>>>>>>> really should you? Domain controllers are the heart of most
>>>>>>> application authentication in many companies. Would you virtualize
>>>>>>> your network? How about your VM server itself. These arent real
>>>>>>> questions, but I am just trying to make a point. You need to
>>>>>>> maintain some level of real servers for key infrastructure. A good
>>>>>>> domain architecture still would have multiple DC's in multiple
>>>>>>> sites for all but the smallest companies. Virtualizing domain
>>>>>>> controllers or any other server just because you can isn't really
>>>>>>> wise decision. Each server/app should be analysed individually to
>>>>>>> determine the real benefit versus risk associated by doing it.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 8:18 AM, Dan Holme
>>>>>>> <dan.holme@intelliem.com <mailto:dan.holme@intelliem.com> <mailto:dan.holme@intelliem.com>> wrote:
>>>>>>>
>>>>>>> The clock issue is only a problem when a DC has a non-normal power
>>>>>>> operation.
>>>>>>>
>>>>>>>
>>>>>>> Having seen plenty of clients with virtualized VMs, isn't it
>>>>>>> reasonable to assume that you can minimize or eliminate
>>>>>>>
>>>>>>> /suspend/resume, snapshot, disk shrink, or VMotion operation/
>>>>>>>
>>>>>>> (the second of which isn't even really 'allowed' on a DC) when a
>>>>>>> DC is "booted"? That's a pretty specific list of VM operations
>>>>>>> that can be avoided or around which workflows can be built.
>>>>>>>
>>>>>>> Seems pretty reasonable to assume an environment can survive a DC
>>>>>>> reboot (which doesn't take that long on a dedicated DC) so
>>>>>>> shutdown à operate on VM à reboot…? In that case, all this is moot.
>>>>>>>
>>>>>>>
>>>>>>> Also, FWIW, I've had projects where the client required MUCH more
>>>>>>> accurate time synchronization than what w32time provides (we
>>>>>>> needed to-the-subsecond synchronization). Some of these
>>>>>>> third-party time sync options can be more fully configured than
>>>>>>> w32time. W32time isn't the only option out there for time sync,
>>>>>>> and it certainly isn't the best one in some scenarios.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>> Dan Holme
>>>>>>>
>>>>>>> dan.holme@intelliem.com <mailto:dan.holme@intelliem.com> <mailto:dan.holme@intelliem.com>
>>>>>>>
>>>>>>> www.intelliem.com <http://www.intelliem.com/> <http://www.intelliem.com/>
>>>>>>>
>>>>>>> Phone: 415.670.9360 (finds me)
>>>>>>>
>>>>>>> Land: 808.573.0726
>>>>>>>
>>>>>>> Mobile: 602.295.1692
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* ActiveDir-owner@mail.activedir.org <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> [mailto:ActiveDir-owner@mail.activedir.org
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>] *On Behalf Of *Roelf
>>>>>>> Zomerman
>>>>>>> *Sent:* Wednesday, June 11, 2008 8:06 AM
>>>>>>>
>>>>>>>
>>>>>>> *To:* ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org>
>>>>>>> <mailto:ActiveDir@mail.activedir.org>
>>>>>>> *Subject:* RE: [ActiveDir] OT: Time Synchronization issue in
>>>>>>> Windows Server 2003 systems running as VMware Guests:
>>>>>>>
>>>>>>>
>>>>>>> I was also wondering about the monitoring inside VM's .. since the
>>>>>>> CPU cycle is not like a real box and most meters are directly
>>>>>>> linked to xx/second (where /second is not a real second).. how can
>>>>>>> you trust the values given by the monitoring solution.
>>>>>>>
>>>>>>>
>>>>>>> External monitoring of the VM is only limited to
>>>>>>> Disk/Memory/CPU/Network.. no real internal options like
>>>>>>> requests/second etc..
>>>>>>>
>>>>>>>
>>>>>>> Any hints on better monitoring inside VM's?
>>>>>>>
>>>>>>>
>>>>>>> Roelf
>>>>>>>
>>>>>>>
>>>>>>> *From:* ActiveDir-owner@mail.activedir.org <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> [mailto:ActiveDir-owner@mail.activedir.org
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>] *On Behalf Of *Tony
>>>>>>> Gordon
>>>>>>> *Sent:* Wednesday, June 11, 2008 1:58 PM
>>>>>>> *To:* ActiveDir
>>>>>>> *Subject:* Re: [ActiveDir] OT: Time Synchronization issue in
>>>>>>> Windows Server 2003 systems running as VMware Guests:
>>>>>>>
>>>>>>>
>>>>>>> Reading that (a few years back) was precisely what made uneasy
>>>>>>> about running my dcs virtualized.
>>>>>>>
>>>>>>> It is not a problem when there are a few hosts running with a few
>>>>>>> vms on each. However, when there are hundreds of hosts with 20-30
>>>>>>> hosts on each monitoring them becomes difficult.
>>>>>>>
>>>>>>> Cpu starved box isn't that good at telling you what is wrong with
>>>>>>> it. Out of band monitoring can help, but the issue is likely to be
>>>>>>> intermittent.
>>>>>>>
>>>>>>> AD is extremely fault tolerant (as long as there is a sufficient
>>>>>>> number of dcs around), but there is client impact is to consider.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> * From: *Gabrie [thegabeman@gmail.com <mailto:thegabeman@gmail.com> <mailto:thegabeman@gmail.com
>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>> * Sent: *06/11/2008 08:01 AM ZE2
>>>>>>> * To: *ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org>
>>>>>>> <mailto:ActiveDir@mail.activedir.org>
>>>>>>> * Subject: *Re: [ActiveDir] OT: Time Synchronization issue in
>>>>>>> Windows Server 2003 systems running as VMware Guests:
>>>>>>>
>>>>>>>
>>>>>>> Some snippets from http://www.vmware.com/pdf/vmware_timekeeping.pdf
>>>>>>> ):
>>>>>>>
>>>>>>>
>>>>>>> /"Because the guest operating system keeps time by counting
>>>>>>> interrupts, time as measured by
>>>>>>> the guest operating system falls behind real time whenever there
>>>>>>> is a timer interrupt backlog. A
>>>>>>> VMware virtual machine deals with this problem by keeping track of
>>>>>>> the current timer interrupt
>>>>>>> backlog and delivering timer interrupts at a higher rate whenever
>>>>>>> the backlog gets too large, in
>>>>>>> order to catch up. Catching up is made more difficult by the fact
>>>>>>> that a new timer interrupt
>>>>>>> should not be generated until the guest operating system has fully
>>>>>>> handled the previous one;
>>>>>>> otherwise the guest operating system may fail to see the next
>>>>>>> interrupt as a separate event and
>>>>>>> miss counting it. This phenomenon is called a lost tick.
>>>>>>> If the guest is running too slowly, perhaps due to competition for
>>>>>>> CPU time from other virtual
>>>>>>> machines or processes running on the host machine, it may be
>>>>>>> impossible to feed the guest
>>>>>>> enough interrupts to keep up with real time. In current VMware
>>>>>>> products, if the backlog of
>>>>>>> interrupts grows beyond 60 seconds, the virtual machine gives up
>>>>>>> on catching up, simply
>>>>>>> setting its record of the backlog to zero. After this happens, if
>>>>>>> VMware Tools is installed in the
>>>>>>> guest and the time synchronization feature is enabled, the tools
>>>>>>> correct the clock reading in the
>>>>>>> guest operating system sometime within the next minute by
>>>>>>> synchronizing the guest operating
>>>>>>> time to match the host machine's clock. The virtual machine then
>>>>>>> resumes keeping track of its
>>>>>>> backlog and catching up any new backlog that accumulates."/
>>>>>>>
>>>>>>> And:
>>>>>>>
>>>>>>> /"W32Time is not aware of any attempts by a virtual machine to
>>>>>>> process timer interrupt backlogs and catch
>>>>>>> up the virtual machine's clock to real time. So, W32Time can set
>>>>>>> the clock too far ahead or
>>>>>>> otherwise be confused by the clock behavior, and it can conflict
>>>>>>> with VMware Tools time
>>>>>>> synchronization. In most cases, it's recommended that you turn the
>>>>>>> W32Time service off in
>>>>>>> virtual machines and run only VMware Tools time synchronization"
>>>>>>> /
>>>>>>> And:
>>>>>>>
>>>>>>> /"VMware Tools time synchronization is designed to be a second
>>>>>>> line of defense to deal with
>>>>>>> special cases where a guest operating system's clock falls behind
>>>>>>> real time despite the built-in
>>>>>>> catchup mechanism provided in the virtual machine. It is normal
>>>>>>> for a guest's clock to be behind
>>>>>>> real time whenever the virtual machine is stopped for a while and
>>>>>>> then continues running; in
>>>>>>> particular, after a suspend/resume, snapshot, disk shrink, or
>>>>>>> VMotion operation. These are the
>>>>>>> main cases that VMware Tools time synchronization is meant to
>>>>>>> handle. The guest's clock may
>>>>>>> also fall behind in less common circumstances, such as under heavy
>>>>>>> load when the guest has
>>>>>>> not been able to get enough CPU time to handle all its timer
>>>>>>> interrupts."/
>>>>>>>
>>>>>>> The VMware pdf is a real good read. Don't miss it :-)
>>>>>>>
>>>>>>> Gabrie
>>>>>>>
>>>>>>> On Wed, Jun 11, 2008 at 1:57 AM, Al Mulnick <amulnick@gmail.com <mailto:amulnick@gmail.com>
>>>>>>> <mailto:amulnick@gmail.com>> wrote:
>>>>>>>
>>>>>>> So, just for the sake of conversation, why would you not sync your
>>>>>>> other hosts off the same time infrastructure vs. using the
>>>>>>> vm-host-of-choice? Given that a pdce can move around the
>>>>>>> environment, you'd be adding a level of complexity to the whole
>>>>>>> thing if you had your pdce sync from one source and your vm'd DC's
>>>>>>> NOT syncing from the pdce but instead from the vm-host-of-choice.
>>>>>>> Not even counting the changes to the pdce to take virtualization
>>>>>>> into account.
>>>>>>>
>>>>>>>
>>>>>>> Just curious mostly. As I indicated earlier, I think it would
>>>>>>> greatly depend on where in the boot cycle the ntp client takes
>>>>>>> over to really help determine what the best config is going to be
>>>>>>> or what those rapid kb thingy's might change to recommend in the
>>>>>>> future.
>>>>>>>
>>>>>>>
>>>>>>> Your thoughts?
>>>>>>>
>>>>>>> On Mon, Jun 9, 2008 at 8:45 AM, Roelf Zomerman
>>>>>>> <roelf.zomerman@avanade.com <mailto:roelf.zomerman@avanade.com> <mailto:roelf.zomerman@avanade.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Very old indeed.. funny however that they only refer to Vmware..
>>>>>>> while Virtual Server and Hyper-V have the same problems.
>>>>>>>
>>>>>>> But with ESX 3.5 you can use the Descheduled Time Accounting
>>>>>>> option.. only available on ESX 3.x when the VM's are configured
>>>>>>> with UniProcessor. When you want to use this one, select a custom
>>>>>>> install of the Vmtools and select the option. This option launches
>>>>>>> a process in the VM OS that allows the date/time to be updated a
>>>>>>> lot quicker than the original one. (Make sure the ESX has a good
>>>>>>> external time source)
>>>>>>>
>>>>>>> Else: Use regular Vmware Time Service in the VMTools, or if the
>>>>>>> virtualized server is the PDC of the domain or root domain, use an
>>>>>>> external time source:
>>>>>>>
>>>>>>> Modify registry settings on the PDC emulator for the forest root
>>>>>>> domain:
>>>>>>> HKLM\System\CurrentControlSet\Services\W32Time\Parameters
>>>>>>> Change Type REG_SZ value from NT5DS to NTP
>>>>>>> Change NtpServer value from time.windows.com <http://time.windows.com/>
>>>>>>> <http://time.windows.com/>,0x1 to an external stratum 1 time
>>>>>>> source, i.e. tock.usno.navy.mil <http://tock.usno.navy.mil/> <http://tock.usno.navy.mil/>,0x1
>>>>>>> HKLM\System\CurrentControlSet\Services\W32Time\Config
>>>>>>> Change AnnounceFlags REG_DWORD from 10 to 5
>>>>>>> Stop and restart time service – net stop w32time - net start
>>>>>>> w32time
>>>>>>> Manually force update w32tm /resync /rediscover
>>>>>>>
>>>>>>>
>>>>>>> And ALWAYS choose only 1 of the solutions.. never both!
>>>>>>>
>>>>>>> Just to make the conversation complete with Vmware's answer
>>>>>>>
>>>>>>> = Roelf
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ActiveDir-owner@mail.activedir.org <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> [mailto:ActiveDir-owner@mail.activedir.org
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org>] On Behalf Of Han Valk
>>>>>>> Sent: Monday, June 09, 2008 2:03 PM
>>>>>>> To: ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org> <mailto:
>>>>>>> ActiveDir@mail.activedir.org> <mailto:ActiveDir@mail.activedir.org>
>>>>>>> Subject: RE: [ActiveDir] OT: Time Synchronization issue in Windows
>>>>>>> Server 2003 systems running as VMware Guests:
>>>>>>>
>>>>>>> So this is what they call "Rapid Publishing" these days? It's old
>>>>>>> very old
>>>>>>> news...
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>> From: ActiveDir-owner@mail.activedir.org <mailto:ActiveDir-owner@mail.activedir.org>
>>>>>>> <mailto:ActiveDir-owner@mail.activedir.org> on behalf of Susan
>>>>>>> Bradley, CPA aka
>>>>>>> Ebitz - SBS Rocks [MVP]
>>>>>>> Sent: Fri 6/6/2008 2:40 AM
>>>>>>> To: activeDir@mail.activedir.org <mailto:activeDir@mail.activedir.org> <mailto:
>>>>>>> activeDir@mail.activedir.org> <mailto:activeDir@mail.activedir.org>
>>>>>>>
>>>>>>> Subject: [ActiveDir] OT: Time Synchronization issue in Windows
>>>>>>> Server 2003
>>>>>>> systems running as VMware Guests:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Time Synchronization issue in Windows Server 2003 systems running as
>>>>>>> VMware Guests:
>>>>>>> http://support.microsoft.com/?kbid=953797
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx
>>>>>>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>>>>>>> List archive: http://www.activedir.org/ma/default.aspx
>>>>>>>
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx
>>>>>>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>>>>>>> List archive: http://www.activedir.org/ma/default.aspx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> The information contained in this e-mail and any accompanying
>>>>>>> documents may contain information that is confidential or
>>>>>>> otherwise protected from disclosure. If you are not the intended
>>>>>>> recipient of this message, or if this message has been addressed
>>>>>>> to you in error, please immediately alert the sender by reply
>>>>>>> e-mail and then delete this message, including any attachments.
>>>>>>> Any dissemination, distribution or other use of the contents of
>>>>>>> this message by anyone other than the intended recipient is
>>>>>>> strictly prohibited. All messages sent to and from this e-mail
>>>>>>> address may be monitored as permitted by applicable law and
>>>>>>> regulations to ensure compliance with our internal policies and to
>>>>>>> protect our business. E-mails are not secure and cannot be
>>>>>>> guaranteed to be error free as they can be intercepted, amended,
>>>>>>> lost or destroyed, or contain viruses. You are deemed to have
>>>>>>> accepted these risks if you communicate with us by e-mail.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx List FAQ :
>>>>>>> http://www.activedir.org/ListFAQ.aspx List archive:
>>>>>>> http://www.activedir.org/ma/default.aspx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx List FAQ :
>>>>>>> http://www.activedir.org/ListFAQ.aspx List archive:
>>>>>>> http://www.activedir.org/ma/default.aspx
>>>>>>>
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx List FAQ :
>>>>>>> http://www.activedir.org/ListFAQ.aspx List archive:
>>>>>>> http://www.activedir.org/ma/default.aspx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> List info : http://www.activedir.org/List.aspx
>>>>>>>
>>>>>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>>>>>> List archive: http://www.activedir.org/ma/default.aspx
>>>>>>
>>>>>>
>>>>>
>>
> List info : http://www.activedir.org/List.aspx List FAQ :
> http://www.activedir.org/ListFAQ.aspx List archive:
> http://www.activedir.org/ma/default.aspx
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
|
|