Två förändringar som flyttar diskussionen från funktioner till support
Proxmox har presenterat två närliggande besked: utökad leverantörssupport och certifiering för Omnissa Horizon. Nyheterna gäller olika delar av en produktionsmiljö, men båda berör frågan som ofta blir avgörande efter en lyckad teknisk pilot: vem hjälper oss när tjänsten står stilla, och vilka kombinationer kan vi faktiskt få stöd för?
Det är också viktigt att hålla isär tidpunkterna. Supportutökningen är annonserad, inte införd vid artikelns publicering den 13 september. Horizon-beskedet gäller en uttryckligt avgränsad provisioneringsmodell. Ingen av nyheterna bör därför användas som ett generellt klartecken för att flytta hela en befintlig VMware- eller VDI-miljö.
LabOps IT:s analys är att förändringarna motiverar en förnyad utvärdering där Proxmox tidigare sorterats bort av supportskäl. De ersätter däremot inte verksamhetens egna krav på återställning, bemanning och dokumenterade integrationsflöden.
Premium får dygnet-runt-support från 19 oktober
Enligt Proxmox besked den 2 september börjar den globala, leverantörsdrivna 24/7-supporten den 19 oktober 2026. Den omfattar Proxmox Virtual Environment, Backup Server och Datacenter Manager. Premium får tillgång från starten inom befintlig plan, med obegränsade ärenden, två timmars prioriterad respons och SLA-baserade eskaleringsflöden för kritiska ärenden och produktionsavbrott.
Standard får tillgång under ett senare anslutningsfönster i fjärde kvartalet 2026. Basic behåller sin befintliga SLA. Det är alltså inte korrekt att beskriva alla abonnemang som dygnet-runt-avtal från oktober. Proxmox supportbesked.
För ett svenskt driftteam är den praktiska kontrollfrågan inte enbart om leverantören går att nå på natten. Be om avtalsvillkor för den egna planen och kontrollera hur prioritet sätts, vem som får öppna ärenden och vad som krävs för att hålla en eskalering aktiv. En svarstid är inte samma sak som en garanterad tid till återställd tjänst.
Skriv därför inte om interna återställningsmål enbart på grund av supportbeskedet. Ett produktionsavbrott behöver fortfarande ett lokalt beslut om återställning, failover eller fortsatt felsökning. Leverantörens incidenthantering bör vara en del av den kedjan, inte hela kedjan.
Horizon-certifieringen gäller manuell provisionering
Den 4 september meddelade Proxmox att VE certifierats inom Omnissa Horizon Ready Hypervisor-programmet. Beskedet anger kompatibilitet i Manual Provisioning Mode och att Proxmox finns listat som certifierad tredjepartshypervisor med NVIDIA vGPU-stöd. Verifierade konfigurationer och driftsättningskrav hänvisas till Omnissas kompatibilitetsguide. Proxmox Horizon-besked.
Avgränsningen är central för en migrationsplan. Certifieringen innebär inte i sig att automatiserade pooler, klonflöden eller hela den vCenter-baserade livscykeln kan flyttas oförändrade. Artikeln anger därför inga generella versionskombinationer eller GPU-modeller som godkända; den exakta kombinationen behöver kontrolleras inför varje införande.
LabOps IT rekommenderar att en pilot följer skrivbordets hela livscykel: skapa virtuell maskin, etablera agent och identitet, ansluta användare, uppdatera grundmiljön och slutligen avveckla maskinen. Dokumentera vad som sköts av Horizon, vad som sköts av hypervisorn och vad som kräver ett eget arbetsflöde.
För grafiktunga användare bör piloten dessutom testa den faktiska applikationen med avsedd belastning. En fungerande inloggning eller en synlig GPU i gästen räcker inte som acceptansprov. Licenser, drivrutiner, kapacitet och ansvar vid ett fel behöver finnas i samma verifieringsprotokoll. Detta är en rekommenderad testmetod, inte ytterligare funktioner som certifieringsbeskedet garanterar.
Plattformens klusterfunktioner är en separat kontrollpunkt
Som bakgrund introducerade Proxmox VE 9.2 den 21 maj Dynamic Load Balancer. Leverantören beskriver automatisk migrering av gäster som hanteras av HA-stacken, med hänsyn till definierade HA-regler och aktuell resursanvändning. Proxmox VE 9.2:s releasebesked.
Den äldre releasen är inte huvudnyheten här. Den visar däremot varför en desktoputvärdering behöver förena applikationslagret med klusterlagrets policy. Att en virtuell maskin är kompatibel med en leveransplattform säger inte automatiskt vilka rörelser mellan värdar som passar dess resursbindningar eller verksamhetskrav.
LabOps IT:s rekommendation är att skilja testerna åt. Verifiera först den certifierade desktopkonfigurationen. Testa därefter underhåll och tillåtna klusteråtgärder för just den konfigurationen. Försök inte härleda GPU-migreringsstöd från en allmän beskrivning av lastbalansering.
Samma princip gäller lagring och nätverk. Dokumentera vad en värdförlust innebär för en pågående session, hur länge användaren faktiskt väntar och hur återanslutning sker. Resultatet bör användas för dimensionering och tjänstebeskrivning, även om alla enskilda komponenter uppfyller sina respektive kompatibilitetskrav.
Räkna på hela driftmodellen, inte bara hypervisorn
En relevant kostnadsjämförelse behöver omfatta vald supportnivå, desktopplattform, eventuella GPU-licenser, övervakning, backup, utbildning och tid för egna integrationsflöden. Pressmeddelandenas budskap om lägre kostnader är leverantörens positionering, inte ett verifierat resultat för en svensk organisation.
Börja med dagens kostnad och driftarbete. Lägg därefter in ett realistiskt alternativ med samma servicenivå och användarvolym. Om den nya modellen kräver fler manuella steg behöver de få både en kostnad och en ansvarig. Annars blir jämförelsen mellan en färdig tjänst och en ofullständig komponentlista.
Pröva också två olika scenarier: en organisation som redan driver Proxmox och vill addera desktopleverans, samt en organisation som måste bygga ny kompetens och nya rutiner samtidigt som den byter plattform. Samma certifiering kan ha olika ekonomisk betydelse i de två fallen.
För supportbudgeten bör avtalsnivån väljas efter vilka tjänster som faktiskt behöver hjälp utanför kontorstid. Undvik att planera en produktionsstart runt Standards senare anslutningsfönster utan ett bekräftat datum för den egna kunden.
Prioritera avtal först och en avgränsad pilot därefter
För en miljö där supporttäckning varit det tydligaste hindret är första steget en skriftlig avtalskontroll. Bekräfta plan, startdatum, prioriteringsregler och eskaleringsväg. Uppdatera sedan jourinstruktionen och se till att rätt personer har åtkomst till supportkanalen.
För en Horizon-miljö kommer kompatibilitetskontrollen före kapacitetstestet. Spara underlaget för den avsedda kombinationen och lista vilka befintliga arbetsflöden som inte ingår i den manuella provisioneringsmodellen. Välj en begränsad användargrupp och tydliga kriterier för att avbryta piloten.
Slutligen bör ett övat felärende ingå i införandet. Samla loggar, beskriva påverkan, pröva eskalering och återställa tjänsten enligt den lokala planen. Det ger mer beslutsvärde än ytterligare en demonstration där alla värdar och sessioner redan fungerar.
LabOps IT:s bedömning
Vår bedömning är att beskeden är en väsentlig utveckling för Proxmox som alternativ i enterprise-miljöer. Supportutökningen kan förändra ett tidigare avtalsmässigt hinder, medan Horizon-certifieringen öppnar en tydligare väg för en avgränsad desktopmodell.
Det starkaste skälet att agera nu är därför att uppdatera beslutsunderlaget, inte att accelerera en otestad migration. Behåll två separata godkännanden: ett för support och driftorganisation, ett för den faktiska desktopkonfigurationen och dess livscykel.
Ett genomtänkt införande kan börja med dessa verifieringar redan före oktober. Produktionsbeslutet bör däremot följa bekräftad avtalstäckning, dokumenterad kompatibilitet och lyckade återställningstester. Då blir nyheterna praktiskt användbara utan att deras avgränsningar försvinner i jämförelsen med VMware.