SCENARIO

1. Please describe the user scenario(s) in elaborate detail
   a. When a live migration is triggered by VMM (for example if the dynamic optimizier is enabled) it does not take the number of available VMQs on the target host into account.
   VMM may move more VMs onto that host than it has available hardware VMQs.




2. For the above user scenario(s), what is the expected result?
   a. VMM should stop moving VMs to a Hyper-V host when the number of available VMQs will be <1 when another VM is moved to that host.




3. For the above user scenario(s), what is the observed result?
   a. VMM moves VMs onto that host until the dynamic optimizer finished it’s tasks.

IMPACT

1. Please describe how your ability to conduct day-to-day business is being blocked or impacted.
   
   a. VMs which are placed onto a host with no available VMQs are experiencing network outages. This impacts directly our product availability and visibility with the end customers of our cloud clients

Hello,

is my assumption correct, that the Fabric Update Remediation steps

1.2 reboot computer
1.3 Start compliance scan

are based on a timeout value?

with a current update baseline (which includes multiple server reboots] this regrettably breaks an automated update remediation on a cluster level, as it runs into an Error (2927) with the compliance scan as the Node undergoes a second reboot, while VMM is doing so.

Can you either create the tasks a little more sophisticated in terms of checking for the installation status in between if possible (so its aware that another reboot is being performed..)
or at least offer the possibility to change the timeout values?

Thank you for VMM and all the cool features which make the admin life easier. :)

best regards
Alex

Currently, if you have both your primary and replica hosts managed within VMM, and static MACs configured on the VMs, you cannot use VMM to make ANY networking changes to the primary VM. VMM knows another VM exists with the same MAC and reads it as a conflict, disallowing any changes until the conflict is resolved. Well, it's not a conflict at all because the other VM with the same MAC is a replica. VMM doesn't seem to know anything about replication beyond the fact that a VM is replicating.

In addition to the MAC conflict issue, VMM does not let you make any changes to a replica VM, like expanding a VHD, or increasing resource allocations to match any changes you make to a primary VM.

It would also be nice to be able to configure replication from within VMM.

Currently, a Service Template requires Machine Tiers defined by using a VM Template. This VM Template can be preexisting (in the Library) or created in the Service Template Designer.

At deploy-time, VM Templates will always mount an ISO file with an unattend.xml file, containing info like Windows License Key, hostname, IP addresses, etc. The deploy job will sit and wait until the VM is shutdown, which results in the job completing successfully.

Although uncommon, there is sometimes a need to deploy Windows VMs that are not sysprep'd, bypassing the out-of-box-experience (OOBE). An example of this would be in training or virtual lab environments, where you cannot script all customization out. Yes, you run the risk of IP and hostname conflicts, but if you're using SDN, this shouldn't be an issue.

There is currently no way to use Service Templates in this type of requirement (due to the above-described way VM Templates are deployed). If you actually specify a non-sysprep'd VHDX, this process will "work", but the VMM job will wait until it times out. You can manually shut down the VM (from Hyper-V or FCM) and trick VMM into thinking everything finished successfully, but that's obviously not the way to handle this.

I propose allowing for VM Templates to have an option to "bypass" the sysprep/OOBE step. I envision the Configure Operating System tab having this on by default, but perhaps a checkbox somewhere that allows for no configuration to be compiled into the unattend.xml and ISO.

Since we upgraded to VMM 2019 it has been very unstable. Console is constantly crashing with .net errors like:

Faulting application name: VmmAdminUI.exe, version: 10.19.1013.0, time stamp: 0x5c5d5de4
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0500b1eb
Faulting process id: 0x20c8
Faulting application start time: 0x01d5cb9256b376e5
Faulting application path: C:\Program Files\Microsoft System Center\Virtual Machine Manager\Bin\VmmAdminUI.exe
Faulting module path: unknown
Report Id: 7772ad44-677c-4a87-acda-a10f437b2f30
Faulting package full name:
Faulting package-relative application ID:

Especially after triggering remediation on a number of hosts. The more hosts, the longer time it keeps crashing. Can be several days if many hosts...