grosas's Posts

Hi Krzysztof, There's no documentation at the moment that lists the internal validation in detail. I can give some here/ For VM validations there are some things validated at the source:  - You already mentioned ISOs. - HCX also looks at snapshots, - mac addresses, - vm tools, - change block tracking, - encryption configurations (vm encryption/vmo encryption), - scsi bus configs, - disk persistency modes,  - vmx/hw version, - virtual hardware (usb, URI serial port, floppys,) - raw disk mapping, - audio cards, - NVME controllers, - guest customization inputs, - power state, - watchdog/precision clock devices, - user permissions for the migration, - disk values. At the destination, there are several checks related to compatibility: - hardware version, - storage policies, - migration type support, - migration container connections, - seedcheckpoint data, - genera things like "will the VM fit on the storage"  - "can the VM run on the host" - MA health, - vmotion and replication heath at the target. This is not exhaustive, just to give you an idea of what validation button does.  it doesn't do any functions related to environmental or point-in-time performance or point-in-time activity on the VM.  In this sphere you can do some baselining and testing to understand the environments capability to deal with VM change and theres's some alarms that will show up on the dashboard when noisy conditions are detected, but neither of these things are tied to the per-migration validation function. 

Hi @lvaibhavt  This is the closest thing. WAF/CDN service ranges: connect.hcx.vmware.com uses Imperva/Incapsula WAF.  https://docs.imperva.com/howto/c85245b7 hybridity-depot.vmware.com is Akamai CDN backed.  https://learn.akamai.com/en-us/webhelp/origin-ip-acl/origin-ip-acl-guide/GUID-E5AD1B2B-BDA1-4C3F-87DE-B0CDBDD1E1B0.html (edited)    learn.akamai.com Allow Origin IP Access Control List addresses through your firewall Edit your firewall settings to allow the listed addresses to access your origin.

it helps to see the full error message from the HCX Cloud manager, but this usually comes up when there is no NSX-T Overlay Transport Zone available at the destination.  Specifically the selected HCX Deployment Cluster in the CP has to be part of the overlay tz.  Also this error can happen if DVS were selected instead of the NSX-T Overlay TZ in the CP screen where you select objects for Network Extension (the screen says select DVS, so it's misleading, but it will be fixed in upcoming release).

Hi Trevor, Not sure I'm understanding the question. But you can edit HCX Manager IP address configuration in the appliance management interface (9443), under Administration tab > Network Settings > General Network.

Yes, With an HCX network extension, you don't need to go configure the subnets, the network extension operation creates an overlay based broadcast domain extension in either Azure Vmware Solution or VMC.   Migrated VMs keep the same IP configuration and the same MAC addresses.  Everything continues to communicate like it's business as usual. Then at some point, you can unextend the network (disable the L2 bridge, and shut off the on-prem gateway)  to "transition the entire gateway/subnet function to the cloud.

Sounds good.  Just keep in mind - this is a workaround for your testing, if you’re using a network extension, You will have to manage the power states at the origin,this operation assumes the source become ceases to exist at the “disaster side”.  A coordinated bulk migration will more gracefully manage the states to minimize downtime.

Hi Simon, The Bulk and RAV migration workflows don't support it today.  It is being considered as an enhancement.  Although it's not quite a coordinated migration, as a workaround to reduce the egress cost, you could use the HCX Disaster Recovery workflows to consume the original seed data and recover the VM to the original site once the changes are replicated.

Hi trevordavismsft​ - good to see you here!   Just to let you know, there is a HCX​ specific place here in VMTN communities.  Opaque networks are coming from NSX, with I would try to see what the network extension service is logging on the HCX Cloud app.log. 

Hi tgrayatshi​, There is a dedicated HCX place in VMTN. Did you ever work through the issue?   Using vMotion VSS PGs for the vMotion Network Profile is supported.  The documentation entry you mentioned (about VSS Management).  That capability came later.  Support for VSS vMotion networks existed prior to the RN's existence, that's why it's not specifically mentioned.

Just wanted to mention there is now a dedicated place for HCX​ discussions in communities! What was the resolution to this issue? Looks like you may have been registering an unsupported NSX-T version.

Hi Daniel, There is a place for HCX​ inquiries now. Replication-Assisted vMotion (RAV) is one of the HCX migration types, it combines the VMware HBR Replication engine (used for initial seeding and continuous replication of disks at large parallel scale) with the vMotion protocol (for the memory state / transaction Integrity for the last phase of the migratio. Feel free to break in the HCX page with any questions.