|
(Off-topic, but I feel the need to defend VMware a bit... :-)
Wow, that's a little cold. What you consider an "antique" RHEL 3.x kernel others consider "stable" and "proven." When you're shooting for an enterprise virtualization system and you want the underlying platform to be rock-solid, you don't use the latest and greatest kernel with the latest and greatest tools, you use what's been there. You also aren't expecting people to be messing with the underlying system much, so who cares? It works, right?
Furthermore, there are a couple of pretty big problems with your implying that the support for BusLogic and LSI Logic has anything to do with what they use for their management console. First, it is by design that VMware supports a limited set of hardware. (Is XEN any different? For PV domUs, it's all PV drivers, which means you don't worry about the hardware, just whether the guest kernel supports PV. For HVM domUs, I dare say that Xen's hardware is more limited than VMware's hardware. I could make the same complaint about XEN - that it was such a pain that it didn't support LSI Logic or BusLogic hardware and when I went to migrate my VMware VMs over to XEN it took a lot of time - I just don't have anything like an "ancient kernel" argument to hang my complaint on. But neither do you...) But I digress - when you're trying to make a consistent hardware platform that works no matter what server ESX is running on and that your guest O/S's always see as the same, you pick a limited set of hardware to support. This produces an extremely consistent and stable environment for deploying VM-based servers across the organization. The more virtual hardware platforms you introduce the more people have to think about which VM has which hardware platform, so which one can I copy or image to my new VM, which type of VM should I create, etc.
The second flaw in your argument is the assumption or implication that what they choose to support in terms of storage controllers in the Virtual Machines has anything to do with the kernel in their management console. Their other products, like Server, Player, and Workstation have support for IDE and the same set of SCSI hardware, don't they? Does that have anything to do with what kernel you're running on your host? Nope - you can install RHEL3 and get IDE or SCSI storage controllers in the guests, even with that kernel. I'm guessing if they had wanted to implement an IDE controller on ESX that nothing would have stopped them - certainly the ancient RHEL 3 kernel supports IDE hardware, and supports the IDE chipset that VMware uses in their other products (Intel 440). In their minds, you're going to be running servers on ESX, and most server O/Ss support those two SCSI controllers. It is annoying when you go to migrate an IDE-based physical or virtual machine to ESX, but there is method to the madness.
Note that I'm not defending VMware's decision to not support IDE in ESX VMs - I've been bitten by this, too, and been really frustrated with them - but I am saying that it is completely inaccurate to blame this on the kernel they're using for their management console, and that VMware has their reasons for not supporting IDE in ESX.
Back on topic, though, the other possibility with Linux is that you can rebuild your initrd with the correct drivers *before* you migrate it over to ESX - then use the install CD as Nico suggested to do the grub install.
And why would you want to migrate to ESX?? :-)
-Nick
>>> On 2008/04/25 at 02:24, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
Diwaker Gupta wrote:
> Hi everyone,
>
> I'm trying to convert some Xen HVM images to run on VMware ESX,
> unsuccessfully thus far. I believe the problem is that ESX by default
> wants the VMs to use SCSI virtual disks, but my HVM VMs are configured
> to use IDE virtual disks. If you have any experience with this sort of
> thing, please get in touch.
>
> Thanks!
> Diwaker
>
I just went through this with SCO OpenServer 5.0.6 as a guest domain,
migratiing from VMware Workstation (which supports IDE) to VMware ESX
(which only supports BusLogic or LSI SCSI for disk controllers). The
limitation seems silly, but this is what you get when you insist on
running on the antique RHEL 3.x and its 2.4 kernel as your base OS for
your emulation server.
For Linux migrations, you should be able to boot with an installation
CD, detect and mount the hard drives, edit the system's
/etc/modprobe.conf and /etc/fstab and /boot/grub/grub.conf, re-run
grub-install, and be ready to boot. I've in fact previously written
tools to install RedHat operating systems from tarballs, so I know it's
feasible.
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
|
