5 Essential Tips for Maximizing Your Experience at Nutanix .NEXT for Bloggers
We see this often on HP Servers, the RAID controller spits out duplicate Serial numbers for the drives. If you look at the GUI during the installation you probably will notice that either they have NO serial numbers, or all the serials are the same. If any CVM or Data disk have the same serial you’ll see this issue.Thankfully, it’s not difficult to fix:SSH into the AHV host (username root, password: nutanix/4u) Get the name of the CVM from AHV via “virsh list --all” Shutdown the CVM Modify the CVM xml file with “virsh edit <name of CVM from Step 1>” Scroll down to the <disk> sections that have your devices with duplicate serials Modify JUST the serial listed in-between the <serial> </serial> tags. Just change a digit or something, do NOT change anything else, be sure it is unique. The editor is vi based BTW. Save the file (esc, wq, enter) Start the cvm (virsh start <name of CVM from Step 1>”Note we’re just changing the serial # presented to the CVM,
This public article should help, it describes a couple different ways of getting the data onto the cluster besides the image service. https://portal.nutanix.com/page/documents/kbs/details?targetId=kA032000000TTgPCAWI would suggest looking at how that data is structured and see if there’s any value to breaking it up into multiple disks/VMDKs before migration just to simplify the move.
As Jeroen said, a single node cluster cannot be expanded (CE or not). Storage only nodes are really just nodes where they have been set to not be schedulable by AHV (or in the case of storage only nodes deployed with ESXi, they’re running AHV so ESXi can’t schedule VMs on them)My recommendation would be to build a 3 node cluster, with two nodes having enough CPU and memory to run the CVM (and maybe FSVM if you’re working with fiels) and then your MS-01 to run your VMs, then just set an affinity rule that keeps your VMs from running on the other two storage only nodes.You will need to rebuild your cluster from scratch though.
The installer needs to complete first and the system reboot to get to the point where the duplicate serial bug can be fixed. Does your installation actually finish and system reboot into AHV?If you don’t mind starting a new thread and then tagging me in it with the details of which hardware your using, screen shot of your drive selection screen and where the installation is failing, that would be the best way for us to help.
Have you checked that md5sum of your image? If you’ve used multiple USB drives and it still doesn’t work then your image is probably corrupt in some way, especially with it saying “invalid compressed data--crc error”I would redownload, write to a new USB using Rufus or UNetBootin and then go from there. If that is the process you are following what version of Rufus or UNetBootin are you using?
What is your use case for an unattended installation of PC? If you use Foundation Central to automate deployments you can also leverage the zero touch framework for deploying additional PCs at remote sites. https://github.com/nutanixdev/zerotouch-framework
That’s extremely strange. We’ve had some issues with different (old) versions of rufus, and I’ve confirmed that I use 4.4, so that’s not the issue, and your MD5sum matches, so your image is good. That leaves us to a hardware challenge of some type.What kind of hardware are you using from a platform perspective? Are you plugged into a USB3 port? If the system has front or rear ports, try using the opposite of what you’re using to get onto a different USB bridge maybe? When it fails, take a look at the output of ‘dmesg’ and see if you’re getting any bus or hardware errors?
SHould be fine, the only other concern might be the NIC on that motherboard. 2.5G NIC drivers are a bit all over the place in the Linux world and depending on the firmware and revision they may cause trouble or may not. It might be worthwile to pick up a super cheap intel based PCIe NIC card that is 1G to put in there.Also, make sure the drive you’re going to install the hypervisor on is the smallest in the system. I use a little 128GB NVMe drive for my hypervisor boot also on a PCIe card. There’s a known bug in the installer that may cause the install to fail if that’s not the case.
Hardware causing I/O errors is not uncommon, especially for the USB bus. There does seem to be a few checkstop errors in the dmesg from a processor perspective but they’re recovered. What also concerns me is that it’s failing when trying to extract the nos tarball into memory. I know you said you have 48GB of memory in the system. With it booted up can you confirm that it actually sees all 48GB of memory, and possibly run memtest86 against your system. I’m wondering if you have a bad DIMM that might be causing this issue?Outside of that I’m sorry but I’m at a loss. Never seen this type of failure in any of our testing without it being something hardware related.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
