I'm gonna stretch the theme of the blog slightly this time. Xen virtualisation is based on Linux (Red Hat) so that's OK. Windows at some point in history had network related stuff from BSD which Mac OS X partly is based on so that's OK as well. NetApps are also based on BSD so there goes, everything is in line with the theme of the blog :-)
Apparently virtualised Windows (in this specific case Windows Server 2008 R2 hosted on a Xen 5.6 pool) can be really slow to update network changes (not putting the blame on any specific actor). Not only can the network change updating be slow (as in minutes or even five minutes) it looks totally OK from the Windows GUI and ping starts to work almost immediately. That doesn't mean everything is OK though since different parts of the network is starting to work much later. Therefore, for example, ping is not that a good tester of the network when handling virtualised Windows (2008 server R2 on Xen 5.6, don't know about other combinations). According to collegauges Microsoft's Remote Desktop is among the latest things to start working so if possible that is a better test (although not possible from, say, firewalls).
Another thing is that when planning a Change you have to plan for this update delay, something like ''change - delay - change - delay'' and so on or ''change - change - change - long delay''. It can build up to substantial amounts of time.
It also means that if you're working fast and change something and it doesn't work you tend to go on and change something else to make it work but you really don't know if it worked or not because the Windows network weren't updated and while it's updating you're already doing the next change and then Windows has to update again and during that time you discover that it doesn't work (or so it seems). Then you might go on and do some other change or even a roll back just to discover that your roll back didn't work either (or so it seems). Patience seems to be the key word here.
No comments:
Post a Comment