How to transfer ESXi server to another server

Introduction

This material describes how to install an ESXi server on hardware that is not supported by its installer. The problem is avoided by transferring an ESXi image from a working server to the server where the installation problem occurred. In my case, the problem was with HP Proliant Blade 35p.

Problem with 35 blade

It took us to install ESXi on Blade HP BL35p. But for some reason during installation ESXi cannot detect the hard disk installed there. And on HP BL20p it is put without problems, but on 35 it doesn’t want at all - it gives an error:



Search for information
An Internet search on ESXi gave information about the ability to boot from a flash drive (http://www.yellow-bricks.com/2008/07/29/esxi-35-update-2-on-a-usb-memory-key/) . But there appeared another problem - the BL35p does not have external USB ports.
The ILO download option is also not very suitable, since for this you need to go to the Blade browser and mount an image for it.
')
There was another possibility to use USB devices. On the front panel of the server there is a special connector where you can connect a tricky cable with outputs for PS / 2 mouse, keyboard, monitor and 2 USB ports. But this solution is more suitable for a temporary connection, and not for regular work.

Dd flash option

failure from dd to partition

Since there is already a ready-made image for working directly from a flash drive, I thought of transferring it directly to disk. Damn Small Linux also did not want to boot on the blade. I tried and in a safe mode and a couple more options - did not work.
Therefore, I just put our corporate CentOs on the disk, and then I recorded this image in a specially assigned partition:
centos # dd bs=512 if=VMware-...-.i386.dd of=/dev/hda3
Then he climbed into grub.conf and added a download point for ESXi
title ESXi
root (hd0,2)
chainloader +1
Naive! I thought everything was so simple :)
This method could not earn in principle, but then I did not know it.
It is worth noting here that I did all this, looking for at least a small but a whole time interval, between other, though small, but urgent tasks. And such interruption does not contribute to a deep understanding of the issue :)
I was hoping that everything will work itself out after several successful manipulations found on the Internet.

failure from dd to a separate disk

Again began to look for a way to start the server. This time I was looking for an opportunity to dual boot from grub.
Found a discussion of a similar problem. How do I setup ESXi in a dualboot with Linux? ( communities.vmware.com/message/1205801;jsessionid=8858F14289C5790501D2BE15F4E048CF )

Added 2nd winchester to the server, recorded the image there
centos # dd bs=512 if=VMware-...-.i386.dd of=/dev/hdb
Repeated grub manipulations
title ESXi
root (hd1,0)
chainloader +1
but something he did not want to be loaded from grub. Disconnected 1st disk and now it is loaded from the 2nd. I was delighted: finally! Still, it's pretty simple!
But this time the download was interrupted. I can not find a bootable partition, waiting for a bootable USB device to appear, - this is how the server reported. And as a result, a loading error.

The dd image already contains several sections.

Further search led me to this document www.grid.org/blog/cameron/updating-vmware-esxi-disk-dump-file
Then I understood why the method did not work with recording the image in a disk partition - the image itself already contains several disk partitions.
~# fdisk -ul VMware-...-.i386.dd
You must set cylinders.
You can do this from the extra functions menu.
Disk VMware-...-.i386.dd: 0 MB, 0 bytes
64 heads, 32 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
VMware-...-.i386.dd1 8192 1535999 763904 5 Extended
VMware-...-.i386.dd4 * 32 8191 4080 4 FAT16 <32M
VMware-...-.i386.dd5 8224 106495 49136 6 FAT16
VMware-...-.i386.dd6 106528 204799 49136 6 FAT16
VMware-...-.i386.dd7 204832 430079 112624 fc Unknown
VMware-...-.i386.dd8 430112 1535999 552944 6 FAT16
Partition table entries are not in disk order

After a bit of searching and thinking, I refused this method (writing the dd image from the distribution kit directly to disk), since I didn’t know what had to be done so that the server would understand how to boot in this case.

Network ESXi boot using PXE

In the process of searching, I also met a rather tempting way to download ESXi over the network using PXE. Everything is as simple as creating a bootable flash drive, just adding a few more steps to set up a PXE server.
In this document, everything is described in detail in communities.vmware.com/docs/DOC-6824 . Even apply the desired configuration after the download can communities.vmware.com/docs/DOC-7510 .
But in this case, you need a separate PXE server, which you did not want to configure right now, so I went the other way :)

Successful option with transferring partitions from BL20p

I thought that all this is simply organized for both flash drives and PXE boot. You can add entries for your device drivers by manipulating the oem.tgz file. So I just need a normal Live Cd and a server on which ESXi has already been installed.
So I installed ESXi on the backup BL20p, where there are no problems. Download ubuntu-8.10-desktop-i386.iso

partition map of the newly installed ESXi

Boot into Ubuntu looked at the disk with ESXi. I saw this picture:



And almost everything became clear to me :)
the / dev / cciss / c0d0p4 section is bootable, the additional section ( extended ) / dev / cciss / c0d0p1 with its subsections ( p5, p6, p7, p8 ) contains everything you need for ESXi to work.
There are still two main sections:
/ dev / cciss / c0d0p2 - here is the paging file (uwswap)
/ dev / cciss / c0d0p3 is the repository for which the rest of the space is allocated during installation.

transfer of the main part

Then I started transferring the ESXi server from the BL20p to the BL35p. For this, I downloaded both from the Ubuntu Live CD.
On BL20p fulfilled
blade20p #fdisk -ul /dev/cciss/c0d0
Disk /dev/cciss/c0d0: 18.3 GB, 18345246720 bytes
64 heads, 32 sectors/track, 17495 cylinders, total 35830560 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/cciss/c0d0p1 8192 1535999 763904 5 Extended
/dev/cciss/c0d0p2 1536000 9922559 4193280 6 FAT16
/dev/cciss/c0d0p3 9922560 35830559 12954000 fb VMware VMFS
/dev/cciss/c0d0p4 * 32 8191 4080 4 FAT16 <32M
/dev/cciss/c0d0p5 8224 106495 49136 6 FAT16
/dev/cciss/c0d0p6 106528 204799 49136 6 FAT16
/dev/cciss/c0d0p7 204832 430079 112624 fc VMware VMKCORE
/dev/cciss/c0d0p8 430112 1535999 552944 6 FAT16
Partition table entries are not in disk order
A picture familiar to us is already visible here. Knowing where extended section №1 ends ( / dev / cciss / c0d0p1 ), I film its image
blade20p # dd bs=512 if=/dev/cciss/c0d0 of=/tmp/boot_esxi.dd count= 1535999
Then I transfer this image in size 786`431`488 bytes to another server
blade20p # scp /tmp/boot_esxi.dd bl35p:/tmp/
Well, I am writing this image to the hard disk.
blade35p # dd bs=512 if=/tmp/boot_esxi.dd of=/dev/sda

copying the contents of a partition2

I format the 2nd partition (/ dev / sda2) in FAT16, because although it is in the partition table, it really is not marked on the disk.
On both servers I mount 2nd section
blade35p # mount /dev/sda /mnt ( BL35p)
blade20p # mount /dev/cciss/c0d0p2 ( BL20p)
I copy the contents of sections from the 20th to the 35th
blade20p # echo > /mn t/uwswap ( swap 1 )
blade20p # scp /mnt/* blade35p:/mnt/ -r

manipulations with partition3 (it is possible that this is not necessary)

Since the third section is / dev / cciss / c0d0p3 in vmfs format, I do not know what to do with it in Ubunt. Therefore, I simply transfer 400MB of this section as an image. Before that, I found out by booting into ESXi that there are utility files on this section that occupy 366 MB
blade20p # df -h
Filesystem Size Used Available Use% Mounted on
unknown 183.9M 116.4M 67.5M 63% /
unknown 4.0G 1.0G 3.0G 25% /vmfs/volumes/49df3145-f290113e-defa-001635c10df4
unknown 12.3G 366 .0M 11.9G 3% /vmfs/volumes/49df314a-a47bf89f-e95d-001635c10df4
unknown 539.8M 175.0M 364.8M 32% /vmfs/volumes/3abb47ef-875ea67c-c948-7bf6ff8d3c38
unknown 47.8M 1.0k 47.8M 0% /vmfs/volumes/f25a177c-84106917-bb27-25e3fe8f8471
unknown 47.8M 36.6M 11.2M 77% /vmfs/volumes/c8f8fc7d-7c221e9a-67b6-5dcb9d3b36ad

I transfer as well as the first piece to this:
blade20p # dd bs=512 if=/dev/cciss/c0d0p3 of=/tmp/partit3.dd count=819200 (819200 = 400*1024*1024/512)
blade20p # scp /tmp/partit3.dd bl35p:/tmp/
Well, I write this image on the hard disk in the desired section
blade35p # dd bs=512 if=/tmp/partit3.dd of=/dev/sda3

After a reboot, ESXi works as if nothing had happened. Hooray! Everything worked out! :)

Creating Storage from VI Client

It remains only to configure our server.
I configure the ip address of the new server from the console. I access it using the VMWare Infrastructure Client. In the settings, I see that this server has a storage capacity of 13.3 GB and about 40 GB more of unused space, since the 60 GB hard drive is installed here.
I delete the existing storage for 13.3 GB, then create a new one from the unallocated space of 55 GB.

There is one danger here . When a new storage is created, my default is to use the entire disk. Although a warning pops up there that all data will be destroyed, I’m sure that I’m working with the unallocated part of the disk successfully organized the storage on top of ESXi itself, which continued to function until the next reboot. Only then I realized that I was wrong, destroying everything on the disk :)

This situation was described by DimkaPhantom dimkaphantom.habrahabr.ru/blog/54322

I had to repeat the server transfer procedure described above.

Conclusion

When all the way is passed, everything seems so simple and obvious that I just wonder why I was so tormented in the beginning :)
Suddenly, someone will be at the beginning of this path and not everything will be obvious to him. Maybe my description will help him a little :)