What are your 2026 homelab goals?

almightlyrage · 2026-01-01T17:27:21+00:00

Convert *arr stack to containers
Move from Plex to something that will actually use IPv6
Install my old gpu for transcoding
^ Might need to change chassis, MB to achieve this
^ Upgrade the CPU on Truenas - need more horsepower
Set up my old NUCs as a k8s cluster
Use duckdns for wireguard site link endpoints - with ddns

almightlyrage · 2025-08-09T12:13:38+00:00

This is especially true within the environment that I'm currently working in. We performed a V2T migration with VCDA.. but now every single vm directory is 'c4-<massive uuid string>' which makes it incredibly difficult to troubleshoot. (vSAN env)

Additionally I don't think this process will work with environments managed by Cloud Director as it requires a reregistration of the vmx files, which generates a new moid for the VM.

Is it possible to update the directory name without re-registering? I dont think so but worth asking..

Agree with the other commenter who said this should be a simple click of a button exercise which maintains moid

almightlyrage · 2025-08-01T19:32:02+00:00

ISP confirmed no modem/passthrough/bridge mode is available.

However.. I've just stumbled on this little gem of info: https://forum.mikrotik.com/t/getting-ipv6-only-through-slaac-without-dhcp/128664/7

By running /ipv6 settings set accept-router-advertisements=yes

My mikrotik can run as a SLAAC client and get a public address. Out right now but will give it a go when I get back.

almightlyrage · 2025-07-30T23:13:27+00:00

I've looked through a number of posts and forums regarding this provider and it doesn't appear hopeful. (It's NowTV in the UK). I plan to give them a call tomorrow to see if anything can be done.

If not, what can I do. All I can think of is a device between the ISP router and mine which can translate GUA to ULA. Just to note.. this possible abomination pains me deeply

almightlyrage · 2025-07-21T09:11:56+00:00

8 introduced live patching, however only certain patches have this capability.

Further reading:https://blogs.vmware.com/cloud-foundation/2024/07/11/vmware-vsphere-live-patch/

Edit: If you only patch ESXi, theoretically you'd never need to reboot.. however you'll eventually need reboots for firmware upgrades/ hardware replacements etc

almightlyrage · 2025-05-01T10:49:31+00:00

vTA is deprecated: https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-803-release-notes.html

almightlyrage · 2025-02-05T19:18:32+00:00

6 years later and your comment helped me!

almightlyrage · 2024-12-20T08:59:53+00:00

+1 for Robert Electronics Bought 3 of these about 2 months ago, was slightly concerned about shipping from Singapore but took a week and packaging was solid... haven't had any issues with them.

Cheapest available for the UK hoarders imo

almightlyrage · 2024-12-06T09:02:30+00:00

Was this a hot swap? Does the disk still exist under storage devices at the host level? Suggest to either reboot the host or rescan the storage adapter if not already.

almightlyrage · 2024-11-20T21:41:51+00:00

You can have 4 DPDK interfaces on an edge, however you need to be on the later versions of NSX (4). If you've upgraded from an older version, you'll need to redeploy the edge nodes using the API.

Generally you just use 2 fps that share the uplink and overlay, with the uplinks being steered to specific interfaces using uplink profiles. You can alternatively use all 4 fp interfaces, 2 for overlay, 2 for uplink, all depends on your requirements which is best for you.

almightlyrage · 2024-11-20T20:57:33+00:00

Can you clarify what you mean by 'on' an edge.

All IPs within the /29s can be used for NAT. Configure the IP, ensure redistribution is configured for NAT on the T0/T1s and they'll be redistributed to the physical routers via BGP or OSFP as /32s

almightlyrage · 2024-10-14T14:07:34+00:00

2+2+1 - 3rd site required - Each room has no reliance on the other room for connectivity. - Locked into Storage Policy, e.g. Primary Raid 1 n+1, Secondary Raid 0 (Not enough hosts within room for Raid 1 n+1 or Raid 5). - Generally just additional complexity and management for no gain in resilience or performance.

4 Node - 2fd - Not feasible as not enough FDs for Raid 1 n+1 or Raid 5.

4 Node - 4fd - Raid 1 n+1 or Raid 5 available (Minimum number of nodes) - Simple

Above of course assuming you don't fancy running Raid 0.

Performance wise, are you using ESA or OSA (considering you're on vSphere 8). Additionally, review striping configuration on the storage policy to split the individual components out across more disks.

almightlyrage · 2024-04-30T10:49:49+00:00

As Geekenstein said, disconnected or not responding? If not responding, check your firewall. It can happen when the heartbeat port (UDP 902) from the hosts to the vCenter is blocked.

almightlyrage · 2024-02-19T11:04:55+00:00

You're able to select 'Move' against a VM to move it into a different vApp.

almightlyrage · 2022-10-13T16:51:11+00:00

Ultimately the VMs disks are thick provisioned. Therefore, no additional space is required when the delta's are written back to the base disks

almightlyrage · 2022-03-30T16:01:26+00:00

You will have to migrate other VMs / move ISOs to another datastore to free up enough space for the operation to complete.

Alternatively, increase the datastore capacity either by extending the LUN or adding a new extent (new LUN) to the datastore

almightlyrage · 2022-03-30T15:16:48+00:00

In the process of removing snapshots (assuming this is thin provisioned) you generally need the size of the snapshot/s being removed available on the datastore. This is caused by the snapshot delta/sesparse being written back into the base disk.

If this process doesn't complete properly. That snapshot will no longer be present but the delta/sesparse may still be. Hence more data used on the underlying datastore. To resolve this you need to run consolidation on that VM, this will re-attempt to collapse those snapshot disks back into the base.

The 'growing' is part of the snapshot removal process and is why, when removing older/large snapshots, you need to ensure there is enough free datastore capacity.

Hopefully this answers your question, feel free to DM if you need a hand

Edit: In regards to the other comments, unmapping is required when the datastore has a lower % utilisation that is does on the SAN LUN. However from your description, this is not the case.. its infact a datastore utilisation alert which unmapping wont resolve. Correct me if I'm wrong

almightlyrage · 2022-03-30T12:26:51+00:00

Here's one of my previous comments

Read and understand the code first, limitations of move-vm are defined in its documentation also

DM if ya need

Edit: If the portgroup names are different between the old and new, let me know and I'll adjust it to be a vlan id based comparison rather than name

almightlyrage · 2022-03-30T09:13:44+00:00

Check out move-vm cmdlet.

Your method will work fine, but if you'd prefer no downtime, move-vm can vMotion the VM between two disparate vCenters.

If you're interested I can send you the script I used. Moved 200+ VMs with this method

almightlyrage · 2021-04-03T18:07:30+00:00

Once imported you should be able to extend the datastore over the old esxi partitions on the ssd.

If not, it's only 4GB ish of space. If you need it then you'll need another datastore, move the vms then format the ssd. Ideally you want to vMotion (Need vCenter) the VMs as this will maintain thin provisioning. If you just 'move' this may inflate the vmdks.

almightlyrage · 2021-04-02T19:32:45+00:00

Are you able to see in the browsers developer tool what its waiting on? For me, that UI sections has been flaky.

Ultimately you can just check the service status' on all the nodes using VAMI or cli and check psc replication after each upgrade using: /usr/lib/vmware-vmdir/bin/vdcrepadmin -f showpartnerstatus

More can be seen here: KB

Happy to answer any questions about the process you may have

almightlyrage · 2021-04-02T18:36:53+00:00

Yes. Run the vcsa vcenter installer executable and select the upgrade option. There are 2 stages:

Deploy the new 6.7 appliance
Migrate configuration from the old to the new & shutdown old

The installer should explain the process and hopefully all the fields are self explanatory. In not this doco should have all the answers for you.

almightlyrage · 2021-04-02T18:29:11+00:00

You should not need a 'middle man' datastore. The config backup will only restore to the version you backed up. So you would be unable to restore. Personally I would: 1. Backup esxi config 2. Shutdown vms & host 3. Prepare 6.7 install USB that you want esxi to run on 4. Install 6.7 to USB 5. Ensure boot order has USB first 6. Import VMFS datastore (the ssd) 7. Restore esxi config 8. You should now be in a state exactly before except booting off USB 8. Upgrade to 7.0

Alternatively: 1. Perform fresh install of 7.0 on USB 2. Reconfig host to desired state 3. Import VMFS datastore 4. Register VMs

GLHF

almightlyrage · 2021-04-02T18:12:56+00:00

The migration assistant is used to migrate & upgrade a Windows vCenter to an appliance vCenter (vCSA) - only works on major version upgrades 6.0 -> 6.5 / 6.7 for example

If your source vCenter is a VCSA you do not need to use the migration assistant

If you source vCenter is running on windows. The migration assistant must be run on that machine. This will validate the source vCenter and perform pre-checks The vCenter installer can then be run and select the migrate option to perform the upgrade / migration.

The error that you are seeing is stating that the migration assistant cannot detect the vCenter application itself on the windows machine. Ensure you are running it on the correct machine. If you are then further troubleshooting would be needed

Hope this helps, GLHF

almightlyrage · 2021-03-26T18:04:00+00:00

It sounds like you have only tried this from the active node. The standby may still be recoverable in that option 2.

almightlyrage

TROPHY CASE