(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@gmail.com>
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.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users