- #Vmware esxi 5 clone failed install
- #Vmware esxi 5 clone failed full
- #Vmware esxi 5 clone failed iso
- #Vmware esxi 5 clone failed Offline
The clone will not suceed until this is resolved.Ģ. As you can see it fails to clone the following files: "FileLevelCloning::task step "clone to VM" destroyed After reviewing the converter logs I found the following error:
I was recently using VMware converter to perform a file level clone of a physical server. I would suggest this to anyone looking for a Master’s Degree Project in Computer Science.Converter - File level clone failed - The filename, directory name, or volume label syntax is incorrect Research: A detailed analysis of the GPT partition on the clone (prior to running sudo sgdisk) would be a good contribution to the Sum of Human Knowledge. There may be expert mode options in Clonezilla that will force a good GPT copy.
#Vmware esxi 5 clone failed Offline
Buy an offline clone device like the WEme USB 3.0 to SATA Dual-Bay External Hard Drive Docking Station With Offline Clone/ Duplicator Function from Amazon. Then run sudo sgdisk from gparted as described above. Examination of both disks with gparted showed that both disks had GPT partitions. The root cause of the failure is Clonezilla did not create a working GPT partition on the clone. Attempts to boot the clone gave the error “boot device not found”. The clone process ran but the clone disk didn’t boot. I had the same problem with my ESXi 6.0 boot disk. Using GParted like this is a great way to visualise the partition table of an ESXi boot volume. ESXi started without issue, now on a completely new boot volume.
In the above example, partitions /dev/sdb7, /dev/sdb9 and /dev/sdb3 were the ones.įinally I clicked Apply to commit. I then powered off the host, removed the original USB key, reconnected the fibre and powered it back on. Some of the partitions couldn’t be copied, but this didn’t prove to be an issue. I then selected each partition in turn on the original USB key, right-clicked to copy it, and then pasted it into the same place on the new key. Now all that was left was to copy the data.īack in GParted I refreshed the devices. This created an empty partition table on the new USB key, but with no data on it: If you get that wrong, you will wipe your existing disk! Sgdisk –replicate=/dev/target /dev/source
The important thing to note here is the syntax, which should be: It saw two, one empty and one with partitions:Īs you can see, /dev/sda is the new USB key.įrom here I ran the Terminal application, and then cloned the partition table using: sudo sgdisk -replicate=/dev/sda /dev/sdb When the GUI loaded, I ran GParted to see what disks were available. I then typed 0 to start X and run GParted: I then booted into the GParted Live image: After choosing the default image, I received the console screen. Finally I disconnected the fibre cables (this is really important – if you accidentally erase or resignature a SAN LUN you’re going to have a really bad day).įortunately the server still recognised the old key, despite ESXi previously reporting it as lost. I disabled HA host monitoring on the cluster, evacuated the first host, placed it into maintenance mode and then shut it down. I then replaced the internal USB key with the new model, and inserted the old one into a random port on the front.
#Vmware esxi 5 clone failed iso
I downloaded the GParted Live ISO to my workstation and connected to the first server’s remote management card (iDrac/IMM/iLO). Unfortunately due to the critical nature of the hosts, the window wasn’t as large as we hoped. I had to find a way to reprovision ESXi on a number of hosts in the time allocated. We raised a Request for Change and scheduled a maintenance window with the client.
#Vmware esxi 5 clone failed full
We decided to replace the USB keys, meaning a full reinstallation of ESXi was necessary. This resulted in the familiar error of losing the device backing the boot filesystem. While ESXi will continue to run (the image is copied into memory during boot), it does mean the system is highly unlikely to boot next time. Recently at the company I work we discovered a number of hosts where the USB keys that had been provisioned were substandard, and had a low mean time between failure (MTBF).
Unfortunately, cheap doesn’t always equate to cheerful, as not all USB keys are made equally. We no longer needed two 146GB disks and an expensive RAID card to host the boot volume and service console, as we could use cheap and cheerful USB keys. I remember thinking this would save us a lot of money. It was only when ESXi 4.0 came along were USB keys officially supported as a boot volume. Initially it was always a hack… I remember getting a 3.5 image and using dd in a very unsupported way to write an image.
#Vmware esxi 5 clone failed install
Since ESXi was introduced it has been possible to install it to a USB key.
0 kommentar(er)
