Egna avbilder

Ladda upp din egen diskavbild — ett härdat basbygge, en golden image från din CI-pipeline, en appliance — och starta instanser från den. En egen avbild tillhör den tenant som laddade upp den: bara den tenanten kan se den, och bara den tenanten kan starta från den. Den visas bredvid plattformens katalog överallt där en avbild väljs.

Pilot — åtkomst beviljas per tenant

Egna avbilder rullas ut som en pilot och är endast tillgängliga för tenanter som funktionen har aktiverats för. Avslaget sker på serversidan: utan behörigheten svarar varje uppladdning 403 FEATURE_NOT_ENABLED, oavsett om den kommer från portalen, CLI:t eller Terraform. I portalen visas avsnittet Avbilder inte alls. Kontakta supporten för att begära åtkomst. Att bläddra i och starta från plattformens katalog påverkas inte.

Vad du kan ladda upp

• Format: qcow2 och raw (containerformat bare). Inget annat — en vmdk, vhd eller vdi måste konverteras lokalt först, t.ex. qemu-img convert -O qcow2 disk.vmdk disk.qcow2.
• Upp till 35 GiB uppladdat — själva filen. En större fil avvisas av lagringskanten innan avbilden importeras.
• Upp till 35 GiB expanderat — avbildens virtuella storlek (se nedan). En större avvisas vid importen.

Eftersom en raw-fil är sin egen virtuella storlek begränsas en raw-avbild i praktiken av uppladdningsgränsen på 35 GiB. Använd qcow2 för allt större.

En qcow2 avvisas också om den anger en backing-fil, är krypterad eller har en annan version än 2 eller 3 — liksom varje fil vars verkliga format inte stämmer med det disk-format du angav. Backing-filen är den vanligaste: en avbild byggd med qemu-img create -b, eller tagen ur en snapshot-kedja, refererar till en annan fil som plattformen aldrig kommer att ha. qemu-img convert -O qcow2 src.qcow2 flat.qcow2 plattar ut kedjan till en fristående avbild.

Det är den expanderade storleken som räknas

En qcow2 är komprimerad och tunt allokerad, och Frostmoln konverterar den till raw vid importen. Det som lagras är därför avbildens virtuella storlek — och det är den virtuella storleken som räknas mot din kvot, som du faktureras för och som en flavors rotdisk måste rymma.

Det här överraskar många: en qcow2 på 800 MB som beskriver en disk på 10 GB blir en avbild på 10 GB. Kontrollera innan du laddar upp:

qemu-img info debian-13.qcow2
# virtual size: 10 GiB (10737418240 bytes)   <- det här är vad som räknas
# disk size: 794 MiB                         <- det här är bara uppladdningen

Om den virtuella storleken är större än du behöver, bygg avbilden med en mindre virtuell disk. (qemu-img resize --shrink kan krympa den i efterhand, men bara efter att filsystemet inne i avbilden har krympts — annars trunkerar du det.)

Din avbild listas som raw

Konverteringen är anledningen till att storleken ändras — och den ändrar även formatet. Laddar du upp en qcow2 rapporterar plattformen, när importen är klar, avbilden som raw: både kolumnen Format i portalen och fm compute image get. Det är inget fel och inget har gått förlorat: raw beskriver det som plattformen nu lagrar, alltså den expanderade avbild som konverteringen gav. Så länge avbilden är Väntar på uppladdning eller Importeras visas det format du angav.

Terraform är undantaget, och avsiktligt så: disk_format på en frostmoln_image är ett värde du själv anger, och en refresh skriver aldrig över det — ditt state fortsätter alltså att säga qcow2. (Att skriva över det skulle få varje apply att misslyckas med "provider produced inconsistent result after apply".) Datakällorna för avbilder rapporterar inget diskformat alls.

Frostmoln sparar inte vilket format du laddade upp, så det finns inget att jämföra en avbild med i efterhand. För egna anteckningar om vilket bygge en avbild kommer från är fältet beskrivning ett bra ställe.

Förbered avbilden innan du laddar upp den

En avbild är ett helt filsystem, och alla i din tenant kan starta en instans från den och läsa den som root. Allt som bygget lämnade kvar följer med.

• Rensa bort autentiseringsuppgifter. Privata SSH-nycklar, authorized_keys, cloud-init-tillstånd (/var/lib/cloud), API-tokens, registry-inloggningar, .env-filer, skalhistorik, pakethanterarens uppgifter.
• Ta bort SSH-värdnycklarna (/etc/ssh/ssh_host_*) och töm /etc/machine-id. Lämnar du kvar dem får varje instans som startas från avbilden samma värdidentitet, och verifieringen av värdnyckeln kan inte längre skilja dina instanser åt.
• Låt cloud-init vara installerat och aktiverat — i en Linux-avbild. Det är cloud-init som installerar dina registrerade SSH-nycklar, kör din user data och sätter ett konsollösenord vid första uppstart. En Linux-avbild utan det startar utan någon väg in — lös inte det genom att baka in ett lösenord eller en fast authorized_keys i avbilden. Ett konsollösenord som begärs för en sådan avbild accepteras och ignoreras sedan tyst, eftersom det inte finns något i avbilden som kan tillämpa det — om inte avbilden dessutom saknar en distribution som plattformen känner igen, då misslyckas starten i stället. Windows är undantaget från den här punkten — se Windows-avbilder.
• Du ansvarar själv för uppdateringarna. En egen avbild är fryst i det ögonblick du laddar upp den. Till skillnad från plattformens katalog är det ingen som uppdaterar den åt dig: bygg om och ladda upp en ny när paketen behöver säkerhetsuppdateras.

Windows-avbilder

Frostmoln sätter inga inloggningsuppgifter inuti en Windows-gäst. Injicering av SSH-nycklar, konsollösenordet och den hanterade agenten är alla cloud-init-mekanismer, och det finns inget API för att hämta ut ett lösenord — ett konsollösenord nekas rakt av för en avbild som anger Windows. För Windows gäller alltså tvärtemot cloud-init-punkten ovan: uppgifterna måste komma från dig. Windows är ingen testad plattformsavbild; allt nedan är vad hypervisorn kräver av avbilden du bygger.

Bygg den BIOS/MBR, inte UEFI. Instanser startar på maskintypen i440fx med ett äldre BIOS; plattformen har ingen UEFI-firmware, och portalen, CLI:n och Terraform erbjuder inget sätt att begära UEFI eller Secure Boot. Ett modernt standardbygge — Hyper-V Generation 2, eller vilken UEFI/GPT-disk som helst — har ingen startbar MBR och fastnar på "no bootable device". Använd Hyper-V Generation 1, eller motsvarande BIOS/MBR-layout i ditt byggverktyg. Hyper-V ger dig dessutom en vhdx, som inte är ett accepterat uppladdningsformat: konvertera den först med qemu-img convert -O qcow2 disk.vhdx disk.qcow2.

Ta med virtio-drivrutinerna. Rotdisken ansluts på virtio-bussen och nätverkskortet är en virtio-modell — så är standarden för varje instans, och portalen, CLI:n och Terraform erbjuder inget sätt att ändra något av det. Lägg in virtio-win-drivrutinerna före sysprep: viostor är kritisk för starten, NetKVM är nätverkskortet. Utan dem får Windows en 0x7B INACCESSIBLE_BOOT_DEVICE vid första uppstart, eller kommer upp utan nätverk. Det finns ingen räddningsväg och ingen avbildsegenskap som rättar det i efterhand: du bygger om och laddar upp på nytt.

Bestäm den virtuella diskstorleken själv. New-VHD skapar som standard 127 GB dynamiskt växande, och det är den virtuella storleken som taket på 35 GiB mäter, hur tom filen än är — så ett Hyper-V-bygge med standardvärden nekas vid importen trots att filen du laddade upp var liten. Skapa disken på 32 GiB eller mindre.

Räkna med en UTC-klocka. Hypervisorn får aldrig veta att gästen är Windows — os_distro är en signal på Frostmoln-nivå, och den separata egenskap Nova läser för detta går inte att sätta från portalen, CLI:n eller Terraform — så den virtuella realtidsklockan går i UTC och Windows tolkar den som lokal tid. Sätt RealTimeIsUniversal (DWORD 1) under HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation i avbilden, eller lev med en klockförskjutning.

Att ta sig in

Har din avbild cloudbase-init, är det den bättre vägen. User data levereras fortfarande till instansen, så cloudbase-init kan använda den, och du kan sätta Administrator-lösenordet från din egen user data per instans och ge varje instans ett eget. Frostmoln varken sätter det lösenordet åt dig eller testar den vägen — men inget hindrar den, och den undviker den delade hemligheten nedan. Koppla ingen SSH-nyckel till en Windows-instans: ingen nyckel når ändå gästen, och det skriver bara om den user data som cloudbase-init läser — infogad i din #cloud-config, eller ompaketerad som flerdelad — i onödan.

Ett lösenord i user data är dock inte dolt. User data serveras oautentiserat till allt som kör i gästen, på 169.254.169.254, under hela instansens livstid, så vilket lokalt konto som helst på den kan läsa lösenordet — och cloudbase-init lämnar det dessutom i sina egna loggar. Det är också en startinloggning: byt den vid första inloggningen, och håll den borta från en startmall, vars user data vem som helst i din tenant kan läsa tillbaka.

Annars bakar du in uppgifterna i avbilden — sätt Administrator-lösenordet, eller skapa ett konto, under sysprep eller din obevakade installation — och nå dem via konsolen. Det är den väg som stöds, inte en nödlösning. Var samtidigt klar över vad hemligheten är: en startinloggning som är identisk på varje instans som någonsin startas från avbilden, läsbar för alla i din tenant som kan starta den (se ovan), och att radera avbilden återkallar den inte på instanser som redan kör. Byt den vid första inloggningen.

• Ta bort uppgiften där installationen lämnade den. Sysprep och obevakad installation lämnar kvar den i C:\Windows\Panther\unattend.xml, C:\Windows\System32\Sysprep\unattend.xml, C:\unattend.xml och C:\Windows\Panther\setupact.log; PlainText="false" är base64, inte kryptering. Använd aldrig AutoAdminLogon — det skriver lösenordet i klartext i registret. Windows-motsvarigheterna till punkten om att rensa inloggningsuppgifter ovan gäller också: Credential Manager, sparade RDP-uppgifter, ConsoleHost_history.txt, produktnyckeln.

Oavsett vilken väg du väljer:

• Välj ett lösenord du kan skriva på ett amerikanskt tangentbord. Konsolen är en VNC-session med en-US-layout, så å, ä, ö — och allt annat som kräver en nordisk layout — går inte att skriva där. Till skillnad från Linux finns ingen SSH-nyckel att falla tillbaka på, så ett lösenord som inte går att skriva betyder en onåbar instans. Använd skrivbara ASCII-tecken på amerikanska tangentpositioner, låt avbildens tangentbordslayout vara amerikansk tills du har en annan väg in, och kom ihåg att Windows kan låsa kontot efter upprepade misslyckanden.
• Fånga avbilden med sysprep /generalize /oobe /shutdown. Det är Windows-formen av att ta bort SSH-värdnycklarna: utan det delar varje instans från avbilden samma SID, samma RDP-certifikat och samma DPAPI-maskinnycklar.
• Ange os_distro som windows när du skapar avbilden: --os-distro windows i CLI:n, OS-distribution i portalen, os_distro på en frostmoln_image i Terraform. Det går inte att ändra i efterhand — en avbild som fick fel värde måste laddas upp på nytt — och det är det enda fält som portalen, CLI:n och Terraform exponerar som talar om för plattformen att avbilden är Windows. Det spelar roll när någon begär ett konsollösenord: starten misslyckas då med console password is not supported for Windows images i stället för det vagare cannot determine the default user for this image; omit the console password or use an SSH key, som aldrig nämner distributionen. Märk aldrig en Windows-avbild med en Linux-distribution för att komma förbi det meddelandet — plattformen accepterar då konsollösenordet och gör tyst ingenting med det.
• Begär inte den hanterade agenten (--instance-access, instance_access = true). Den kräver systemd och cloud-init och är alltså bara för Linux. Att begära den nekas inte: instansen skapas som vanligt, agenten installeras aldrig, och fm ssh misslyckas sedan med beskedet att du ska skapa om instansen med flaggan du redan använde.
• Ta dig in via konsolen. Konsol på instansen i portalen, eller fm compute instance console <instans>, som skriver ut en konsol-URL. Det är en noVNC-session och den enda konsol plattformen tillhandahåller. Den är ingen väg till RDP.
• Öppna sedan din egen fjärråtkomst, snävt. Logga in på konsolen, sätt upp RDP eller WinRM själv och öppna det i en säkerhetsgrupp — aldrig mot 0.0.0.0/0. Ingenting är öppet som standard. Nå hellre instansen på dess privata adress via VPN eller en bastion, låt NLA vara på, och kör WinRM över HTTPS (5986), aldrig okrypterad 5985.

Windows-licensen tar du med dig själv, och ansvaret för att följa den är ditt. Frostmoln tillhandahåller ingen Windows-licens, nyckel eller aktiveringstjänst, så en KMS-aktiverad avbild tappar aktiveringen här — använd MAK, eller en KMS som dina instanser kan nå.

Installera ingen gästagent

Frostmoln använder inte qemu-guest-agent till någonting, och du ska inte heller baka in Frostmolns egen agent i avbilden.

Frostmoln installerar sin agent när instansen skapas, och bara om du ber om det — fm compute instance create --instance-access, eller instance_access = true på en frostmoln_instance i Terraform. Den kan inte läggas till på en instans som redan finns: skapa om instansen i stället. Att sedan använda åtkomsten — fm ssh, fm forward — kräver dessutom rättigheten instance-access på din tenant; kontakta supporten om fm ssh nekas.

Den kan inte vara en del av avbilden: agentens identitet är instansens eget id, som inte finns när du bygger avbilden, så en inbakad kopia skulle sakna identitet och sakna sätt att skaffa en.

Det avbilden måste tillhandahålla är det som installationen behöver vid första uppstart:

Krav	Varför
x86_64	Den enda arkitektur agenten byggs för.
systemd som init, med systemctl i PATH	Agenten installeras som en systemd-tjänst.
cloud-init, som kan uppge instansens id	Cloud-init kör installationen, och installationen frågar den efter instansens eget id — som är agentens identitet. Den faller tillbaka på att läsa konfigurationsenheten, vilket kräver mount och sed.
sha256sum	Den nedladdade agenten kontrolleras mot en fastställd hash.
curl eller wget	För att hämta agenten.
Utgående HTTPS till Frostmolns agent-gateway, permanent	Inte bara för nedladdningen — den installerade agenten håller en utgående anslutning till gatewayen, och det är den som bär dina sessioner. Se noteringen nedan.
Ett befintligt /usr/local/bin, och skrivbara /etc + /etc/systemd/system	Dit binären, dess konfiguration och dess unit skrivs. Installationen skapar inte /usr/local/bin.

Ett saknat verktyg misslyckas tyst

Det här gäller framför allt nedbantade och minimala avbilder. Saknas något av ovanstående startar instansen normalt och får helt enkelt aldrig någon agent — inget fel visas när den skapas, och fm ssh till den fungerar inte.

Var du letar: /var/log/frostmoln-managed-agent-install.log på instansen anger orsaken, och det gör även seriekonsolen. cloud-init status --long rapporterar också ett fel, eftersom en misslyckad installation avslutas med nollskild kod — på en i övrigt frisk instans är alltså en misslyckad agentinstallation det som gör cloud-inits slutstatus röd.

Utgående trafik är det som fallerar efter en lyckad installation

Alla andra krav misslyckas högljutt i den loggen. Utgående trafik gör det inte: agenten installeras utmärkt om gatewayen är nåbar vid första uppstart, och tystnar sedan om du stänger den utgående trafiken i efterhand. fm ssh slutar fungera utan att något i installationsloggen förklarar varför, eftersom installationen lyckades.

Din tilldelning

Som standard får varje tenant äga 10 egna avbilder på totalt 376 GB lagrad avbildsdata (decimala GB, räknat på den expanderade storleken). Ögonblicksbilder och plattformens katalog räknas inte in.

Din aktuella förbrukning finns i portalen under Kvoter, kategorin Egna avbilder. Kontakta supporten för att få tilldelningen höjd.

Tre olika avslag kan komma vid uppladdning, och de har inte samma åtgärd:

Status	Betydelse	Vad du gör
409 quota_exceeded	Din tilldelning är full.	Ta bort en egen avbild för att frigöra en plats. Att försöka igen hjälper aldrig.
403 quota_exceeded	För mycket är redan på gång — för många avbilder väntar på uppladdning, eller för många byte ligger i mellanlagring.	Slutför eller ta bort avbilderna som står i Väntar på uppladdning och försök igen.
429	Du har startat för många uppladdningar den senaste timmen.	Vänta tills tidsfönstret har passerat. En avbild du redan skapat finns kvar.

En misslyckad import fortsätter uppta en plats

En misslyckad import lämnar avbilden i Väntar på uppladdning, så den fortsätter räknas mot gränsen för pågående uppladdningar. Därför försvinner en 403 inte alltid av sig själv — ta bort de avbilder du inte tänker slutföra.

Att ta bort en avbild frigör dess plats omedelbart — men först när inget bygger på den.

En avbild som lagringsbackenden fortfarande refererar till kan inte tas bort

Varje instansdisk är en copy-on-write-klon av avbilden den startades från, så plattformen nekar borttagningen med 409 så länge någon av de klonerna finns kvar. Ta bort instanserna som startats från avbilden och försök igen.

Ett nekande ändrar ingenting: avbilden finns kvar, fortfarande Aktiv, och samma borttagning lyckas när den sista klonen är borta.

Ladda upp från portalen

Beräkning → Avbilder → Ladda upp avbild. Du anger namn, diskfilen, diskformatet och valfritt en beskrivning, OS-distribution, OS-version och arkitektur (OS-fälten är metadata — de hjälper dig och dina kollegor att känna igen avbilden senare).

Bakom knappen kör portalen fyra steg: den skapar avbilden, skickar filen direkt till objektlagringen (avbildens byte passerar aldrig API:et), ber plattformen importera den och pollar sedan tills den är klar. Konverteringen sker på serversidan och är proportionell mot avbilden, så en stor avbild kan ta flera minuter; du kan lämna sidan — importen fortsätter utan webbläsaren.

Avbildens status visar var den befinner sig:

Status	Betydelse
Väntar på uppladdning	Avbilden finns men innehåller ännu inga byte.
Importeras	Byten konverteras och lagras.
Aktiv	Klar att starta.
Importen misslyckades	Byten avvisades — se När en import misslyckas.

En uppladdning som avbryts halvvägs lämnar avbilden som Väntar på uppladdning. Skapa inte en till: använd Ladda upp igen på den befintliga raden för att fylla den.

Ladda upp med fm CLI

fm compute image create \
  --name my-debian \
  --file debian-13.qcow2 \
  --disk-format qcow2 \
  --os-distro debian \
  --os-version 13 \
  --arch x86_64 \
  --wait

create kör hela flödet — skapa, ladda upp, importera — och skriver ut avbildens id så snart avbilden finns, innan uppladdningen börjar, så att ett senare fel aldrig tappar bort det. (Med -o json / -o yaml kommer dokumentet, och därmed id:t, i stället på slutet.) --wait blockerar tills avbilden är aktiv (upp till --timeout, 30 minuter som standard); utan den fortsätter importen på serversidan och fm compute image get visar resultatet.

Om uppladdningen misslyckas eller avbryts finns avbilden kvar — fyll den i stället för att skapa en ny:

fm compute image upload <image-id> --file debian-13.qcow2

Resten av familjen:

fm compute image list --visibility private   # dina egna avbilder
fm compute image list --visibility public    # plattformens katalog
fm compute image get <image-id>
fm compute image update <image-id> --name my-debian-13 --min-disk 20
fm compute image delete <image-id>

Bara --name, --description, --min-disk och --min-ram kan ändras efter att en avbild har skapats. Alla flaggor: fm CLI-referensen (på engelska).

list skriver ut den råa statusen, där en misslyckad import inte går att skilja från en avbild som aldrig laddats upp — båda visar queued. Använd get, som säger det uttryckligen.

Med Terraform

resource "frostmoln_image" "golden" {
  name             = "golden-ubuntu-24.04"
  source_file      = "${path.module}/build/golden-ubuntu-24.04.qcow2"
  source_file_hash = filesha256("${path.module}/build/golden-ubuntu-24.04.qcow2")
  disk_format      = "qcow2"

  os_distro    = "ubuntu"
  os_version   = "24.04"
  architecture = "x86_64"
  min_disk_gb  = 20
}

resource "frostmoln_instance" "app" {
  name      = "app-01"
  image_id  = frostmoln_image.golden.id
  flavor_id = "gp1.small"
  subnet_id = frostmoln_subnet.main.id
}

source_file är en lokal sökväg som läses av maskinen som kör Terraform — inte en bucket-nyckel eller en URL. Terraform kan inte se en ändring av filens innehåll under en oförändrad sökväg, så kombinera den med source_file_hash när du bygger om avbilden på plats: en ändrad hash ersätter avbilden, vilket laddar upp och importerar den på nytt. terraform import stöds medvetet inte — deklarera avbilden i konfigurationen och kör apply. Observera att plattformen sätter min_disk utifrån avbildens verkliga expanderade storlek under importen och ersätter det du konfigurerat; ett konfigurerat min_disk_gb ligger kvar i state som du skrev det, så en senare refresh kan visa plattformens värde som en diff.

Fullständigt schema, och datakällorna för att slå upp en befintlig avbild (på engelska):

• frostmoln_image-resursen
• frostmoln_image-datakällan · frostmoln_images-datakällan

Starta en instans från den

Dina avbilder dyker upp överallt där en avbild väljs — portalens formulär för att skapa instanser, fm compute instance create --image <image-id>, image_id i Terraform.

Bara en avbild som är Aktiv kan startas. Väljaren listar dina avbilder oavsett tillstånd, så en som väntar eller har misslyckats erbjuds som vilken annan som helst, och skapandet av instansen misslyckas då. Kontrollera statusen först.

Under importen registrerar plattformen avbildens minsta disk utifrån dess verkliga expanderade storlek och ersätter det värde du satt. En flavor vars rotdisk är mindre än så kan inte starta avbilden.

När en import misslyckas

En misslyckad import lämnar inte avbilden i ett felaktigt tillstånd. Den återställer avbilden till queued — samma status som en avbild som aldrig laddats upp har — och registrerar en separat importFailed-flagga. Den skillnaden spelar roll om du skriver din egen pollning: polla efter active ELLER importFailed, aldrig efter enbart active, annars väntar ditt skript för alltid på en misslyckad import.

Både portalen och fm compute image get visar det (Importen misslyckades / en varningsrad), tillsammans med orsaken när plattformen kan fastställa någon:

• Filen innehåller en annan diskavbild — en qcow2 som exporterats inifrån en annan qcow2. Att ladda upp samma fil igen misslyckas på exakt samma sätt. Exportera gästens disk från hypervisorn som en vanlig qcow2- eller raw-avbild och ladda upp den i stället.
• Filen använder en funktion som inte kan konverteras — en backing-fil eller kryptering. Slå ihop den till en enda okrypterad avbild (qemu-img convert) och ladda upp den.
• Filen är inte det format du angav — kontrollera vad den faktiskt är (qemu-img info visar det), ange rätt diskformat på avbilden och ladda upp den igen.
• Konverteringen misslyckades — oftast en ofullständig uppladdning eller en skadad avbild. Kontrollera att filen går att öppna lokalt och ladda upp den igen.
• Plattformen kunde inte fastställa någon orsak — kontakta supporten och ange avbildens ID. Att ladda upp samma fil igen hjälper sannolikt inte.

Om du frågar API:et själv heter orsaken importFailureReason på avbilden, och värdet är något av nestedFormat, unsupportedFeature, declaredFormat, conversionFailed eller unknown. Nya koder kan tillkomma när som helst — behandla en okänd kod precis som unknown.

Orsaken stannar kvar på avbilden, så den finns kvar efter en omladdning eller nästa dag.

Ett fel tar några sekunder att synas, och det är avsiktligt. Plattformen får veta att en import misslyckats något innan den får veta varför, och den publicerar ingetdera förrän båda är klara — så att du aldrig visas "importen misslyckades" utan förklaring och med det meningslösa rådet att ladda upp filen igen. Under upp till en minut ser avbilden därför ut precis som en som ingen har laddat upp till: queued, ingen importFailed. Fortsätt fråga. I det ovanliga fall där plattformen inte kunde fastställa någon orsak alls får du felet utan orsak.

Alla avslag kommer inte hit. En fil som inte är en giltig qcow2- eller raw-diskavbild, en som anger en backing-fil eller är krypterad, och en vars expanderade storlek överstiger taket på 35 GiB avvisas alla direkt, med en 400 och ett meddelande som anger orsaken — importen startar aldrig och ingen importFailed registreras. importFailed betyder att filen klarade de kontrollerna och sedan misslyckades under konverteringen eller lagringen.

I båda fallen står avbilden kvar i Väntar på uppladdning och du kan ladda upp en rättad fil till samma post.

Fakturering

Egna avbilder faktureras per GB-månad på avbildens logiska (expanderade) storlek, i decimala GB, så länge avbilden finns — prissatt som en volymögonblicksbild. Storleken som visas i portalen är den storlek du betalar för. Att ta bort en avbild stoppar avgiften.

Priser kommer från plattformens priskatalog och visas i portalen; den här guiden anger inga belopp. Se Fakturering.

Begränsningar

• Endast qcow2 och raw, containerformat bare.
• 35 GiB uppladdat / 35 GiB expanderat per avbild; 10 avbilder / 376 GB per tenant som standard. Hur många uppladdningar som får pågå samtidigt är också begränsat.
• Avbilder är privata för din tenant — att dela en avbild med en annan tenant är inte tillgängligt. Inom tenanten är de inte hemliga: den som kan starta en instans kan läsa hela filsystemet.
• Ingen nedladdning eller export — en uppladdad avbild kan inte hämtas ut igen som fil. Behåll en egen kopia av allt du kan tänkas behöva igen.
• Att skapa en egen avbild från en körande instans ögonblicksbild är inte tillgängligt; ladda upp diskavbilden i stället.

Relaterat

• Beräkning / Instanser · Kvoter och fakturering
• fm CLI · Terraform-leverantör