November 19, 2008
With the number of times I’ve installed and re-installed the various builds of Essential Business Server over the last year, I’ve compiled a list of install notes and various shortcuts that have shaved my install time considerably.
All of these have been used for a lab environment only, inside Hyper-V. Installing EBS in a production environment may require different tactics. Here’s the initial list of topics, each of which will get its own post…
- Configuring Virtual Networking for EBS
- Configuring Virtual Machines for EBS
- Time Synchronization in Hyper-V
- EBS Core Operating System Installation
- Getting EBS Planning Data Into Hyper-V
- EBS Server Installation
- Avoiding EBS Installation Errors
- Testing EBS Licensing
FYI: I expect this list to grow over time.
|| posted by chris under essential business server, funlab, migration, virtualization || comments (0) ||
||
August 29, 2008
Make no mistake about it.
I personally think Hyper-V is a seriously kickass slice of awesome from Microsoft. And if you aren’t at least checking it out, you’re really, truly and seriously missing out.
But it is abso-freaking-lutely INSANE how long it takes Hyper-V to fully delete a virtual machine if it has more than say…2 snapshots in it.
While doing some wickedly massive content dev recently, I was having to export some fairly large and semi-complex virtual machines, then fully wipe out them out before importing other fairly large and semi-complex virtual machines back in.
The export and import phases were awesome. Easily Hyper-V’s second best feature, only slightly behind the new snapshot feature.
But I literally would be waiting HOURS for the more involved virtual machines to finish detroying/merging/whatever.
Call me crazy…
But if I tell Hyper-V to “Delete” a given virtual machine, how freaking hard can it be to simply…oh I don’t know…dump the freaking contents of the virtual machine directory, and then clean its references out of Hyper-V?
|| posted by chris under clueless, kma, thumbs down, virtualization || comments (0) ||
||
July 6, 2008
There’s no single more important thing to the long-term health of any network system than accurate time.
Without accurate time, there is no way to assure than any transactions flying in that environment will maintain fidelity. In other words…
There’s no way to know that databases, Active Directory, file systems, or anything else that uses any kind of timestamp isn’t shredding itself to bits.
10 years ago or so, time sync used to be much more of an issue. Oh sure, you could always load a dialer program that would call Colorado (in the US) and get a time adjust to the master clocks. But that was a major pain in the tookus. And it cost you money with each call.
Thanks to the glorious achievement that is the Internet, and a little gem called Network Time Protocol AKA NTP (including its eponymous sibling Simple Network Time Protocol AKA SNTP), time sychronization became largely a moot issue in data networks during the 90s.
The key to time synchronization, at least as far as maintaining a healthy network goes, is not so much having correct time (more on that in a minute), but having consistent time, which are two very different concepts.
Although it might make your users mad when the clocks on their PCs are off a bit, it is usually far more healthy for the average data network to be 5 minutes off everywhere, as opposed to having different parts of the network running on-time whle other parts do not.
The consistency of time in a data network has far-ranging implications. For Active Directory, one of the primary functions that depends on consistent time is network logon.
That’s because Active Directory uses Kerberos tickets to validate logon traffic. The tickets, which are by design time sensitive and expire so that captured traffic cannot be replayed and used to compromise systems in a classic man-in-the-middle attack, rely on consistent time. We’re normally talking about a 5 minute (which is an absolute eternity, in computer time actually) for everything to remain both hunky and dory.
The stampede rush to all things virtualization is poised to make time synchronization a key network design issue, all over again.
Because when the magic act that is virtualization makes the hardware go poof, there’s one major thing that goes away forever…
The BIOS Clock
Sure, a BIOS clock isn’t the end all, be all.
But it will keep you, and your systems, in the ballpark.
So if you aren’t spending time planning clock synchronization for your virtual systems, you’d best get that taken care of, and pronto.
|| posted by chris under business, hardware, it pro, migration, rx, time, virtualization || comments (2) ||
||
June 26, 2008
The officially official version of Hyper-V just hit the download site today at noon Pacific time.
In an amazing feat of time-warping, this post was sent back in time to coincide with the exact moment of Hyper-V’s release.
Before you go all crazy downloading and installing Hyper-V, remember that upgrading your virtualization platform takes some planning and forethought…
If you care at all whether your virtual machines will still work, that is.
Some standard cautions about new versions of Hyper-V…
- Once you put Hyper-V RTM on, there’s no removing it.
- Virtual machines in a paused or saved state usually can’t be upgraded.
- Before you do anything else, export a copy of your virtual machines to an external drive exactly as you want them preserved.
- Archive all your exports into .zip files, so you don’t blow your only shot at an import later.
- Snapshots might not survive an upgrade. So merge your changes before shutting down your virtual machines for the upgrade. But push those exports first!
- Don’t forget to install the new Integration Services at some point, once you’ve verified your machines are all happy and working on the final release.
And for Pete’s sake…
- Keep a copy of the current version of Hyper-V that you are running, just in case. Otherwise, the export copies you pushed will be less than worthless.
In fact, why don’t you store that copy of Hyper-V used to make the export copies right WITH the export copies, so you’ll always have it if you need it.
In case the absolute very worst happens.
|| posted by chris under freebie, hardware, it pro, migration, rx, virtualization || comments (0) ||
||
June 20, 2008
With the public release candidate of Small Business Server 2008 floating around and about, there might be a few folks who want to stand it up inside of Hyper-V RC1.
When configuring a virtual machine to run SBS08, you’ll want to remove the native adapter that is configured by default, and add a Legacy Network adapter instead.
Otherwise, you’ll get the following error during installation
Network Adapter was not found
SBS08 can’t see native adapters until Integration Services are loaded. Which you really can’t do safely until after SBS is done installing.
Talk about a Catch-22, huh?
Also, certain things in SBS08 won’t install correctly without an adapter loaded. So you end up with a borked install.
Which maybe is something you’re after. But prolly not.
Go legacy adapter, if all you are wanting to do is put SBS08 through its paces with the least amount of hassle.
|| posted by chris under beta, hardware, rx, virtualization || comments (2) ||
||
