0

I'm about to deploy a new low-end server and I had considered using ESXi to virtualize the OS to make it really easy to migrate this server to new hardware should the need arise.

I ended up talking to a Dell server tech and he was quick to point out that this is not valid use of virtualization and that I would be better off just using Ghost to create an image and then restore that image on a new server.

I have very little experience with Ghost, but my understanding is that this process could cause all sorts of problems with video drivers, network drivers and raid drivers if the new hardware was very different than the original.

Is Ghost sophisticated enough to solve this problem, or is the Dell rep talking out of his hat?

Darrel Miller
  • 190
  • 1
  • 3
  • 12

4 Answers4

2

What you are considering definitely is a valid use of Virtualization; whether that's the right way to go or not is entirely up to you and your needs.

As to the question of managing the drivers, Ghost (which for this discussion is genuine Ghost, sold in Ghost Solution Suite, not the unrelated product which assumed its place under the consumer "Norton Ghost" brand name a few years back) contains a tool called DeployAnywhere for retargeting systems to get the right drivers available after you deploy an image.

DeployAnywhere takes a little more work to use when you deploy manually, as you generally do with servers, mainly just to ensure that the drivers it needs to install into the newly-deployed system are available to it (such as on a boot disk or network share) at the time. For workstations, deployment through the Ghost management console takes more care of that for you, it's just another part of the process along with renaming the machine and reconfiguring it.

That driver retargeting generally isn't so important for migrations to VMWare since the emulated hardware is deliberately of a type that is widely supported and doesn't need specialized drivers, but it's definitely more useful for migrating from a VM to a physical machine.

For most editions of VMWare (ESX has limitations), Ghost can actually image both from a physical disk directly to a VMDK and back again as well as use the normal (non-runnable) .GHO image format, so virtualization isn't one-way. If you need to go physical->virtual for a while, that's fine, and you can generally go virtual->physical as well if you change your mind. Even if you do prefer to use VMware's tools to do the physical->virtual migration (and as a poster above mentions, those are excellent and mature), ours can still help you not only go the other way, but make life easier in a few awkward corner cases if you get stuck with a non-runnable physical machine (for instance after a motherboard failure, Ghost can P2V the physical hard disk for you).

The above will also apply fully to ESX at some point, but ESX is a little unusual in the VMWare family, and the internals of their virtual disk format are subtly different than the other products - not greatly, but enough to cause Ghost problems. Right this second getting ESX support fully to the same level as we have for VMWare Workstation is something we're still working on.

Full disclosure: I work for Symantec on Ghost.

Nigel Bree
  • 161
  • 4
1

Part of the "win" of virtualization absolutely is abstraction away from physical hardware. "Ghost" is a disk-duplication product, and while there have been "advances" made in various disk-dupe products creating images that are exhibit a degree of hardware-agnosticism, migrating virtual machines between hosts running the same hypervisor will provide no indication to the virtualized guest OS that any underlying change has occurred (the guest OS is living in "the Matrix").

I disagree with the "Dell server tech" making the statement that virtualization isn't a "valid" way to abstract operating system configurations away from hardware. If you were thinking about dedicating a single physical machine to each VM then I'd question the efficiency of the solution. (I'd think that he'd want you to buy as many physical boxes as he could get you to buy, anyway! I can't imagine why he'd talk you out of that... >smile<)

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • If they can sell you on the notion of running many servers on one piece of hardware then they can sell you the really big stuff with big margins. – Darrel Miller Dec 09 '09 at 15:02
  • What Dell server model are you thinking about doing this on, out of curiosity? – Evan Anderson Dec 09 '09 at 15:05
  • Ok, don't laugh. One of the T100 that they are currently getting rid of for less than $400 CDN. – Darrel Miller Dec 09 '09 at 15:08
  • Whatever works. I don't know if the T100 has hardware-assisted virtualiation support (VT). Your performance hit will be less with VT. – Evan Anderson Dec 09 '09 at 15:19
  • Ironically, that's why I called Dell. The E5400 processor has two specs, one with VT and one without. I called to find out which they used. I never found out, because the tech said the T100 is not certified for virtualization and I shouldn't be using virtualization for this purpose anyway. – Darrel Miller Dec 09 '09 at 15:23
  • It seems to me that the confusion is in how the Dell tech interpreted your question. Virtualizing a server to make it "portable" in the sense of being able to move it (as a vm guest) from one vm host to another is valid. Virtualizing a server to move it from one physical machine to another isn't, in this case imaging is the appropriate solution. So which is it that you're trying to accomplish? – joeqwerty Dec 09 '09 at 21:13
  • Definitely the former. – Darrel Miller Dec 24 '09 at 14:26
0

It's not a particularly valid use for virtualisation and you'd be better off using something like Ghost - :)

Seriously though virtualisation can do this for you but is likely to take as much effort as Ghosting will in the long run.

Chopper3
  • 101,299
  • 9
  • 108
  • 239
  • So Ghost is capable of installing into the OS all of the new drivers for the new hardware when you restore the image? – Darrel Miller Dec 09 '09 at 14:59
  • The poster is throwing away some performance re: running the OS in a virtualized environment rather than on the bare metal, but he can probably accept that on modern hardware. I'd never trust a Windows OS, at least, that was disk-duped from unlike hardware. A Windows OS installed in a VM from the beginnging (i.e. not P2V) and migrated between like hypervisors wouldn't give me any pause re: the OS stability at all. – Evan Anderson Dec 09 '09 at 15:00
  • No Darrel, but both paths involve similar degrees of effort - all I'm saying that is for a single box it's all a bit 50/50 which way you go. – Chopper3 Dec 09 '09 at 15:14
  • Oh and Evan, I'm totally with you, 100% VM-guy (VCP3&4 in fact) but if you only had one machine you're not going to gain that much from VMing it - I think he'll be happy either way. – Chopper3 Dec 09 '09 at 15:25
  • For me, I'm familiar with how to handle VMs. I have very little experience with Ghost. I was just curious if there was a major advantage to using Ghost. – Darrel Miller Dec 09 '09 at 15:29
0

Actually, one of the steps of the process of migrating a physical server to a virtual one, is taking an image of the hard-drive of the physical system and restoring it onto a virtual hard-drive.

Although it can definitely be done manually (I've done it a couple of times before), I'd suggest using the tools supplied with VMWare to do that for you. They will also take care of the other steps involved in virtualizing a physical server, and they are really mature by now (when I've done the manual migration, it was because the tools were too expensive or not mature enough at that time).

fretje
  • 1,644
  • 1
  • 14
  • 15
  • The idea is to install the server OS in a VM in the first place. I.e. I can setup the VM at my office on our main VMWare server and then when I get the server that will be co-located I can just move the image onto it. When that server does not cut it anymore, I can throw it away and put in a bigger server and simply move the image. – Darrel Miller Dec 09 '09 at 15:05
  • @Darrel: No need to install the server OS first... Restoring an image onto it will just overwrite everything. – fretje Dec 09 '09 at 16:02