General IAUG Discussion Forum

 View Only

  • 1.  VMWare Host servers

    Posted 08-28-2020 10:27 AM

    A member of our chapter asked this question, and I cannot answer it.  Can someone help?
    We are in the process of upgrading our physical VMWare host servers.  To do this we built a new VMWare cluster on new host servers and planned to migrate the existing virtual servers over.  Per an Avaya bulletin, this is not supported.  Due to a change in the "VMWare Virtual Machine Hardware Version", they are saying we need to literally rebuild the Avaya virtual servers from scratch on the new VMware environment.   We have never had to do this with any other system/application.  Has anyone else encountered this problem?



    ------------------------------
    Susan Cope
    Telecommunications Manager
    McCormick Place
    Chicago, Illinois
    312-791-6536
    scope@mccormickplace.com
    ------------------------------


  • 2.  RE: VMWare Host servers

    Posted 09-15-2020 01:40 PM
    No, we have not encountered it. That just sounds bananas to me. Yes, real-time voice is a unique beast, but we have absolutely vMotioned servers from one host/cluster to another.
    Original Message


  • 3.  RE: VMWare Host servers

    Posted 09-16-2020 03:07 PM
    I just want to get into the details a little deeper. The Avaya servers that you vMotioned from one host/cluster to another, was the VMWare software, hardware or both upgraded on the new host/cluster? We were already into the upgrade of one of our data locations when we found out about this Avaya restriction and have plans next year to upgrade to the next VMWare version (I think it's version 7 - but don't quote me - I'm just the phone guy).

    ------------------------------
    George Ahlenius
    Manager Telecommunications
    College of DuPage
    Glen Ellyn
    ------------------------------

    Original Message


  • 4.  RE: VMWare Host servers

    Posted 09-16-2020 04:27 PM

    Yeah, I'm just the phone guy too, so I would love it if folks like @Nick Kwiatkowski, @Tom Lynn, or @Sam Osheroff would jump in. My understanding of VMware and Avaya solutions' interactions with it is very limited. Forgive me if I get stuff wrong here.

    As you know, a VMware server is a segmented portion of a physical machine somewhere with it's own OS, applications, etc. That physical machine is the host. A cluster is - I believe - simply a grouping of servers that can be managed easily in one place. They can be on one host or different hosts. I think.

    So we've done it all. We've moved servers off ​​​a host to upgrade ESXI and then moved them back on. We've restored servers from the snapshots Avaya tells you not to use for backups (turn off quiescing). We've vMotioned servers to new hosts and put them in new clusters while they were live.

    What you DON'T want to do is attempt to dismount an .iso drive that you accidentally left mounted to one of your HA CM's without taking that machine out of production first. This caused all our H.323 phones to reboot, and about 5% of them didn't come back up on their own. This is the only real VMware problem we've had so far. (Knocking on wood and crossing my fingers.)

    Maybe I've played with fire and been lucky. 

    So again, I may have some of this wrong, but to the best of my understanding this is how it all works, and this has been our experience. I have continued to implore Avaya to keep it's applications to current ESXI releases. It's tough when no other application in your enterprise cares about the difference between ESXI 6.5 and 6.7...except yours. Because now you're holding up host upgrades.


    Original Message


  • 5.  RE: VMWare Host servers

    Posted 09-17-2020 08:56 AM
    We've vMotioned servers between data centers, live-migrated the filesystem to other locations as well.  From the folks I've spoken to deep at Avaya, the recommendation comes from IT departments randomly moving hosts around (or in some cases, they've seen it where they have a policy to rotate machines between hosts on a scheduled or regular basis "just because".

    When you vMotion or do a live migration between hosts you will screw up the real-time clock that is in the application level of quite a few of the Avaya apps.  This means you will drop packets (not a ton, but a few), cause clock instability, and have different network performance when you are done.  The result ends up being, you will most likely drop audio, possibly drop calls, possibly reset connections to media gateways, and possibly do warm (or cold) resets of cabinets.  After a few minutes the systems will have taken care of their maintenance, and things will be back to normal.

    If you understand the consequences and do the vMotion and other actions during maintenance windows when things are allowed to break for a few minutes you will be fine.  Make sure you check that the application you are migrating is compatible with the version of VMWare (this is important, because the VMWare Tools embedded in the Avaya software is only compatible with a range of ESXI versions).  Just don't let the VMWare admins upgrade the bundled-in tools -- that /will/ break things :)

    ------------------------------
    Nick Kwiatkowski
    Director of Design and Engineering
    Michigan State University
    East Lansing MI
    ------------------------------

    Original Message


  • 6.  RE: VMWare Host servers

    Posted 09-16-2020 05:05 PM
    We (University of Washington) are running a Nutanix/KVM environment so I can't speak to vmWare very much.  We definitely migrated guests between Nutanix hosts in the cluster during host maintenance.  I wouldn't do it during peak hours.   As far as moving VMs to a new cluster via vMotion, I would think it would work.  VM hardware version info is held in the VM's config so the only issue I'd think you'd run into is migrating to a substantially newer VMware might get you a warning.  Avaya builds the OVA with a VM hardware version number that matches their minimum supported VMware version so as long as you're also not going above their highest supported version, I don't think you need to change anything.   You might consider shutting down the VM, depending on how much different the new host hardware is.  It's been a long time since I've touched a VMware cluster.  I vaguely recall the cluster's hardware/CPU specs were dumbed down to the specs of the least capable CPU in the cluster.  Enabling/elevating the cluster hardware version required shutting down all VMs in the cluster.  I'm not sure if that's still a requirement.  You might consider, if the new cluster is built as a separate entity, enabling the highest supported CPU capabilities for the new hosts and migrated the guest VMs offline (if that's still required).   As long as the same private VLAN for the CM duplication link is available on both clusters, you can down the standby, migrated it, boot back up, interchange after shadowing has come back, then migrate the was-active server.  That's how we did it when we moved to Nutanix (well, we had to build new VMs in the KVM world but regardless, we didn't take a CM outage).

    -Sam

    ------------------------------
    Sam Osheroff
    UC Engineer
    University of Washington
    Seattle WA
    ------------------------------

    Original Message