Egne avbilder

Last opp ditt eget diskavbilde — et herdet basisbygg, et golden image fra CI-pipelinen din, en appliance — og start instanser fra det. Et eget avbilde tilhører den tenanten som lastet det opp: bare den tenanten kan se det, og bare den tenanten kan starte fra det. Det vises ved siden av plattformkatalogen overalt der et avbilde velges.

Pilot — tilgang gis per tenant

Egne avbilder rulles ut som en pilot og er kun tilgjengelige for tenanter der funksjonen er aktivert. Avslaget skjer på serversiden: uten rettigheten svarer enhver opplasting 403 FEATURE_NOT_ENABLED, enten den kommer fra portalen, CLI-et eller Terraform. I portalen vises ikke seksjonen Avbilder i det hele tatt. Kontakt support for å be om tilgang. Å bla i og starte fra plattformkatalogen påvirkes ikke.

Hva du kan laste opp

• Formater: qcow2 og raw (containerformat bare). Ingenting annet — en vmdk, vhd eller vdi må konverteres lokalt først, f.eks. qemu-img convert -O qcow2 disk.vmdk disk.qcow2.
• Opptil 35 GiB opplastet — selve filen. En større fil avvises av lagringskanten før avbildet importeres.
• Opptil 35 GiB utvidet — avbildets virtuelle størrelse (se nedenfor). Et større avvises ved importen.

Siden en raw-fil er sin egen virtuelle størrelse, begrenses et raw-avbilde i praksis av opplastingsgrensen på 35 GiB. Bruk qcow2 for alt som er større.

En qcow2 avvises også hvis den oppgir en backing-fil, er kryptert eller har en annen versjon enn 2 eller 3 — det samme gjelder enhver fil hvis virkelige format ikke stemmer med disk-format-en du oppga. Backing-filen er den vanligste: et avbilde bygget med qemu-img create -b, eller hentet fra en snapshot-kjede, refererer til en annen fil plattformen aldri vil ha. qemu-img convert -O qcow2 src.qcow2 flat.qcow2 flater kjeden ut til et frittstående avbilde.

Det er den utvidede størrelsen som teller

En qcow2 er komprimert og tynt allokert, og Frostmoln konverterer den til raw under importen. Det som lagres, er derfor avbildets virtuelle størrelse — og det er den virtuelle størrelsen som teller mot kvoten din, den du faktureres for, og den en flavors rotdisk må ha plass til.

Dette overrasker mange: en qcow2 på 800 MB som beskriver en disk på 10 GB blir et avbilde på 10 GB. Sjekk før du laster opp:

qemu-img info debian-13.qcow2
# virtual size: 10 GiB (10737418240 bytes)   <- dette er det som teller
# disk size: 794 MiB                         <- dette er bare opplastingen

Hvis den virtuelle størrelsen er større enn du trenger, bygg avbildet med en mindre virtuell disk. (qemu-img resize --shrink kan krympe det i etterkant, men bare etter at filsystemet inne i avbildet er krympet — ellers avkorter du det.)

Avbildet ditt vises som raw

Konverteringen er grunnen til at størrelsen endrer seg — og den endrer også formatet. Laster du opp en qcow2, rapporterer plattformen avbildet som raw når importen er ferdig: både kolonnen Format i portalen og fm compute image get. Det er ingen feil, og ingenting er tapt: raw beskriver det plattformen nå lagrer, altså det utvidede avbildet konverteringen produserte. Så lenge avbildet er Venter på opplasting eller Importeres, vises formatet du oppga.

Terraform er unntaket, og med vilje: disk_format på et frostmoln_image er en verdi du selv konfigurerer, og en refresh overskriver den aldri — state-en din fortsetter derfor å si qcow2. (Å overskrive den ville fått hver apply til å feile med "provider produced inconsistent result after apply".) Datakildene for avbilder rapporterer ikke noe diskformat i det hele tatt.

Frostmoln tar ikke vare på hvilket format du lastet opp, så det finnes ingenting å sammenligne et avbilde med senere. Noter selv hvilken bygging et avbilde kommer fra — feltet beskrivelse er et godt sted.

Klargjør avbildet før du laster det opp

Et avbilde er et helt filsystem, og alle i tenanten din kan starte en instans fra det og lese det som root. Alt byggingen la igjen, følger med.

• Fjern legitimasjon. Private SSH-nøkler, authorized_keys, cloud-init-tilstand (/var/lib/cloud), API-tokens, registry-innlogginger, .env-filer, skallhistorikk, legitimasjon for pakkebehandleren.
• Fjern SSH-vertsnøklene (/etc/ssh/ssh_host_*) og tøm /etc/machine-id. Lar du dem stå, får hver instans som startes fra avbildet, samme vertsidentitet, og verifisering av vertsnøkkelen kan ikke lenger skille instansene dine fra hverandre.
• La cloud-init være installert og aktivert — i et Linux-avbilde. Det er cloud-init som installerer de registrerte SSH-nøklene dine, kjører user data og setter et konsollpassord ved første oppstart. Et Linux-avbilde uten det starter uten noen vei inn — ikke løs det ved å bake inn et passord eller en fast authorized_keys i avbildet. Et konsollpassord som bes om for et slikt avbilde blir godtatt og deretter stille ignorert, fordi det ikke finnes noe i avbildet som kan sette det — med mindre avbildet i tillegg ikke oppgir noen distribusjon plattformen kjenner igjen, og da mislykkes starten i stedet. Windows er unntaket fra dette punktet — se Windows-avbilder.
• Du eier oppdateringen av det. Et eget avbilde er fryst i det øyeblikket du laster det opp. I motsetning til plattformkatalogen er det ingen som oppdaterer det for deg: bygg om og last opp et nytt når pakkene trenger sikkerhetsfikser.

Windows-avbilder

Frostmoln setter ingen påloggingsopplysninger inne i en Windows-gjest. Injisering av SSH-nøkler, konsollpassordet og den administrerte agenten er alle cloud-init-mekanismer, og det finnes ingen API for å hente ut et passord — et konsollpassord blir avvist rett ut for et avbilde som oppgir Windows. For Windows gjelder derfor det motsatte av cloud-init-punktet over: opplysningene må komme fra deg. Windows er ikke et testet plattformavbilde; alt under er hva hypervisoren krever av avbildet du bygger.

Bygg det BIOS/MBR, ikke UEFI. Instanser starter på maskintypen i440fx med et eldre BIOS; plattformen har ingen UEFI-fastvare, og portalen, CLI-en og Terraform gir ingen måte å be om UEFI eller Secure Boot på. Et moderne standardbygg — Hyper-V Generation 2, eller en hvilken som helst UEFI/GPT-disk — har ingen oppstartbar MBR og henger på "no bootable device". Bruk Hyper-V Generation 1, eller tilsvarende BIOS/MBR-oppsett i byggeverktøyet ditt. Hyper-V gir deg dessuten en vhdx, som ikke er et godtatt opplastingsformat: konverter den først med qemu-img convert -O qcow2 disk.vhdx disk.qcow2.

Ta med virtio-driverne. Rotdisken kobles til på virtio-bussen og nettverkskortet er en virtio-modell — slik er standarden for hver instans, og portalen, CLI-en og Terraform gir ingen måte å endre noen av delene på. Legg inn virtio-win-driverne før sysprep: viostor er kritisk for oppstarten, NetKVM er nettverkskortet. Uten dem får Windows en 0x7B INACCESSIBLE_BOOT_DEVICE ved første oppstart, eller kommer opp uten nettverk. Det finnes ingen redningsvei og ingen avbildeegenskap som retter det i etterkant: du bygger om og laster opp på nytt.

Bestem den virtuelle diskstørrelsen selv. New-VHD lager som standard 127 GB dynamisk voksende, og det er den virtuelle størrelsen taket på 35 GiB måler, uansett hvor tom filen er — så et Hyper-V-bygg med standardverdier blir avvist ved importen selv om filen du lastet opp var liten. Lag disken på 32 GiB eller mindre.

Regn med en UTC-klokke. Hypervisoren får aldri vite at gjesten er Windows — os_distro er et signal på Frostmoln-nivå, og den separate egenskapen Nova leser for dette kan ikke settes fra portalen, CLI-en eller Terraform — så den virtuelle sanntidsklokken går i UTC og Windows tolker den som lokal tid. Sett RealTimeIsUniversal (DWORD 1) under HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation i avbildet, eller lev med en klokkeforskyvning.

Å komme seg inn

Har avbildet ditt cloudbase-init, er det den bedre veien. User data leveres fortsatt til instansen, så cloudbase-init kan bruke den, og du kan sette Administrator-passordet fra din egen user data per instans og gi hver instans sitt eget. Frostmoln verken setter det passordet for deg eller tester den veien — men ingenting hindrer den, og den unngår den delte hemmeligheten under. Ikke koble en SSH-nøkkel til en Windows-instans: ingen nøkkel når gjesten uansett, og det bare skriver om den user data cloudbase-init leser — flettet inn i din #cloud-config, eller pakket om som flerdelt — til ingen nytte.

Et passord i user data er likevel ikke skjult. User data serveres uautentisert til alt som kjører i gjesten, på 169.254.169.254, gjennom hele instansens levetid, så hvilken som helst lokal konto på den kan lese passordet — og cloudbase-init legger det dessuten igjen i sine egne logger. Det er også en oppstartsopplysning: bytt den ved første pålogging, og hold den utenfor en startmal, hvis user data hvem som helst i tenanten din kan lese tilbake.

Ellers baker du opplysningene inn i avbildet — sett Administrator-passordet, eller opprett en konto, under sysprep eller den uovervåkede installasjonen din — og nå dem via konsollet. Det er veien som støttes, ikke en nødløsning. Vær samtidig klar over hva hemmeligheten er: en oppstartsopplysning som er identisk på hver eneste instans som startes fra avbildet, lesbar for alle i tenanten din som kan starte det (se over), og å slette avbildet trekker den ikke tilbake på instanser som allerede kjører. Bytt den ved første pålogging.

• Fjern opplysningen der installasjonen la den igjen. Sysprep og uovervåket installasjon lar den ligge i C:\Windows\Panther\unattend.xml, C:\Windows\System32\Sysprep\unattend.xml, C:\unattend.xml og C:\Windows\Panther\setupact.log; PlainText="false" er base64, ikke kryptering. Bruk aldri AutoAdminLogon — det skriver passordet i klartekst i registeret. Windows-motstykkene til punktet over om å fjerne påloggingsopplysninger gjelder også: Credential Manager, lagrede RDP-opplysninger, ConsoleHost_history.txt, produktnøkkelen.

Uansett hvilken vei du velger:

• Velg et passord du kan skrive på et amerikansk tastatur. Konsollet er en VNC-økt med en-US-oppsett, så å, ä, ö — og alt annet som krever et nordisk oppsett — kan ikke skrives der. I motsetning til Linux finnes ingen SSH-nøkkel å falle tilbake på, så et passord som ikke kan skrives, betyr en utilgjengelig instans. Bruk skrivbare ASCII-tegn på amerikanske tasteposisjoner, la tastaturoppsettet i avbildet være amerikansk til du har en annen vei inn, og husk at Windows kan låse kontoen etter gjentatte feil.
• Fang avbildet med sysprep /generalize /oobe /shutdown. Det er Windows-formen av å fjerne SSH-vertsnøklene: uten det deler hver instans fra avbildet samme SID, samme RDP-sertifikat og samme DPAPI-maskinnøkler.
• Oppgi os_distro som windows når du oppretter avbildet: --os-distro windows i CLI-en, OS-distribusjon i portalen, os_distro på en frostmoln_image i Terraform. Det kan ikke endres i etterkant — et avbilde som fikk feil verdi må lastes opp på nytt — og det er det eneste feltet portalen, CLI-en og Terraform eksponerer som forteller plattformen at avbildet er Windows. Det betyr noe når noen ber om et konsollpassord: starten mislykkes da med console password is not supported for Windows images i stedet for det vagere cannot determine the default user for this image; omit the console password or use an SSH key, som aldri nevner distribusjonen. Merk aldri et Windows-avbilde med en Linux-distribusjon for å komme forbi den meldingen — plattformen godtar da konsollpassordet og gjør stille ingenting med det.
• Ikke be om den administrerte agenten (--instance-access, instance_access = true). Den krever systemd og cloud-init og er altså kun for Linux. Å be om den blir ikke avvist: instansen opprettes som vanlig, agenten installeres aldri, og fm ssh mislykkes deretter med beskjed om å opprette instansen på nytt med flagget du allerede brukte.
• Kom deg inn via konsollet. Konsoll på instansen i portalen, eller fm compute instance console <instans>, som skriver ut en konsoll-URL. Det er en noVNC-økt, og det er det eneste konsollet plattformen leverer. Det er ingen vei til RDP.
• Åpne så din egen fjerntilgang, snevert. Logg inn på konsollet, sett opp RDP eller WinRM selv, og åpne det i en sikkerhetsgruppe — aldri mot 0.0.0.0/0. Ingenting er åpent som standard. Nå heller instansen på den private adressen via VPN eller en bastion, la NLA være på, og kjør WinRM over HTTPS (5986), aldri ukryptert 5985.

Windows-lisensen tar du med deg selv, og ansvaret for å overholde den er ditt. Frostmoln leverer ingen Windows-lisens, nøkkel eller aktiveringstjeneste, så et KMS-aktivert avbilde mister aktiveringen her — bruk MAK, eller en KMS instansene dine kan nå.

Ikke installer en gjesteagent

Frostmoln bruker ikke qemu-guest-agent til noe, og du skal heller ikke bake Frostmolns egen agent inn i avbildet.

Frostmoln installerer agenten sin når instansen opprettes, og bare hvis du ber om det — fm compute instance create --instance-access, eller instance_access = true på en frostmoln_instance i Terraform. Den kan ikke legges til på en instans som allerede finnes: opprett instansen på nytt i stedet. Å bruke tilgangen etterpå — fm ssh, fm forward — krever i tillegg rettigheten instance-access på tenanten din; kontakt support hvis fm ssh avvises.

Den kan ikke være en del av avbildet: agentens identitet er instansens egen id, som ikke finnes mens du bygger avbildet, så en innbakt kopi ville hatt verken identitet eller noen måte å skaffe seg en på.

Det avbildet må stille med, er det installasjonen trenger ved første oppstart:

Krav	Hvorfor
x86_64	Den eneste arkitekturen agenten bygges for.
systemd som init, med systemctl i PATH	Agenten installeres som en systemd-tjeneste.
cloud-init, som kan oppgi instansens id	Cloud-init kjører installasjonen, og installasjonen spør den om instansens egen id — som er agentens identitet. Den faller tilbake på å lese konfigurasjonsstasjonen, som krever mount og sed.
sha256sum	Den nedlastede agenten sjekkes mot en fastsatt hash.
curl eller wget	For å hente agenten.
Utgående HTTPS til Frostmolns agent-gateway, permanent	Ikke bare for nedlastingen — den installerte agenten holder en utgående forbindelse til gatewayen, og det er den som bærer øktene dine. Se notatet nedenfor.
En eksisterende /usr/local/bin, og skrivbare /etc + /etc/systemd/system	Dit binærfilen, konfigurasjonen og unit-filen skrives. Installasjonen oppretter ikke /usr/local/bin.

Et manglende verktøy feiler stille

Dette gjelder særlig nedstrippede og minimale avbilder. Mangler noe av det ovenstående, starter instansen normalt og får rett og slett aldri en agent — ingen feil vises ved opprettelsen, og fm ssh til den virker ikke.

Hvor du leter: /var/log/frostmoln-managed-agent-install.log på instansen oppgir årsaken, og det gjør serriekonsollen også. cloud-init status --long rapporterer også en feil, siden en mislykket installasjon avslutter med en verdi ulik null — på en ellers frisk instans er altså en mislykket agentinstallasjon det som gjør cloud-inits sluttstatus rød.

Utgående trafikk er den som svikter etter en vellykket installasjon

Alle andre krav feiler høylytt i den loggen. Utgående trafikk gjør det ikke: agenten installeres helt fint hvis gatewayen er tilgjengelig ved første oppstart, og blir så stille hvis du stenger utgående trafikk etterpå. fm ssh slutter å virke uten at noe i installasjonsloggen forklarer hvorfor, fordi installasjonen gikk bra.

Din tildeling

Som standard kan hver tenant eie 10 egne avbilder på til sammen 376 GB lagrede avbildedata (desimale GB, regnet på den utvidede størrelsen). Øyeblikksbilder og plattformkatalogen teller ikke med.

Ditt nåværende forbruk finnes i portalen under Kvoter, kategorien Egne avbilder. Kontakt support for å få tildelingen hevet.

Tre ulike avslag kan komme under opplasting, og de har ikke samme løsning:

Status	Betydning	Hva du gjør
409 quota_exceeded	Tildelingen din er full.	Slett et eget avbilde for å frigjøre en plass. Å prøve igjen hjelper aldri.
403 quota_exceeded	For mye er allerede underveis — for mange avbilder venter på opplasting, eller for mange byte ligger i mellomlagring.	Fullfør eller slett avbildene som står i Venter på opplasting, og prøv igjen.
429	Du har startet for mange opplastinger den siste timen.	Vent til tidsvinduet har passert. Et avbilde du allerede har opprettet, finnes ennå.

En mislykket import fortsetter å oppta en plass

En mislykket import etterlater avbildet i Venter på opplasting, så det fortsetter å telle mot grensen for pågående opplastinger. Derfor forsvinner en 403 ikke alltid av seg selv — slett avbildene du ikke har tenkt å fullføre.

Å slette et avbilde frigjør plassen umiddelbart — men først når ingenting bygger på det.

Et avbilde lagringsbackenden fortsatt refererer til, kan ikke slettes

Hver instansdisk er en copy-on-write-klone av avbildet den ble startet fra, så plattformen avviser slettingen med 409 så lenge noen av de klonene finnes. Slett instansene som er startet fra avbildet, og prøv igjen.

En avvisning endrer ingenting: avbildet er der fortsatt, fortsatt Aktiv, og den samme slettingen lykkes når den siste klonen er borte.

Last opp fra portalen

Beregning → Avbilder → Last opp avbilde. Du oppgir navn, diskfilen, diskformatet og eventuelt en beskrivelse, OS-distribusjon, OS-versjon og arkitektur (OS-feltene er metadata — de hjelper deg og kollegene dine med å kjenne igjen avbildet senere).

Bak knappen kjører portalen fire steg: den oppretter avbildet, sender filen rett til objektlagringen (avbildets byte passerer aldri API-et), ber plattformen importere det, og poller så til det er klart. Konverteringen skjer på serversiden og er proporsjonal med avbildet, så et stort avbilde kan ta flere minutter; du kan forlate siden — importen fortsetter uten nettleseren.

Statusen til avbildet viser hvor det er:

Status	Betydning
Venter på opplasting	Avbildet finnes, men inneholder ennå ingen byte.
Importeres	Bytene konverteres og lagres.
Aktiv	Klart til å startes.
Importen mislyktes	Bytene ble avvist — se Når en import mislykkes.

En opplasting som avbrytes halvveis, etterlater avbildet som Venter på opplasting. Ikke opprett et nytt: bruk Last opp på nytt på den eksisterende raden for å fylle det.

Last opp 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 kjører hele flyten — opprett, last opp, importer — og skriver ut avbildets id så snart avbildet finnes, før opplastingen starter, slik at en feil senere aldri mister den. (Med -o json / -o yaml kommer dokumentet, og dermed id-en, til slutt i stedet.) --wait blokkerer til avbildet er aktivt (opptil --timeout, 30 minutter som standard); uten den fortsetter importen på serversiden, og fm compute image get viser resultatet.

Hvis opplastingen mislykkes eller avbrytes, finnes avbildet fortsatt — fyll det i stedet for å opprette et nytt:

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

Resten av familien:

fm compute image list --visibility private   # dine egne avbilder
fm compute image list --visibility public    # plattformkatalogen
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>

Bare --name, --description, --min-disk og --min-ram kan endres etter at et avbilde er opprettet. Alle flagg: fm CLI-referansen (på engelsk).

list skriver ut den rå statusen, der en mislykket import ikke kan skilles fra et avbilde som aldri er lastet opp — begge viser queued. Bruk get, som sier det uttrykkelig.

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 er en lokal sti som leses av maskinen som kjører Terraform — ikke en bucket-nøkkel eller en URL. Terraform kan ikke se en endring i filens innhold under en uendret sti, så kombiner den med source_file_hash når du bygger avbildet på nytt på samme sted: en endret hash erstatter avbildet, som da lastes opp og importeres på nytt. terraform import støttes bevisst ikke — deklarer avbildet i konfigurasjonen og kjør apply. Merk at plattformen setter min_disk ut fra avbildets virkelige utvidede størrelse under importen og erstatter det du har konfigurert; en konfigurert min_disk_gb blir liggende i state slik du skrev den, så en senere refresh kan vise plattformens verdi som en diff.

Fullstendig skjema, og datakildene for å slå opp et eksisterende avbilde (på engelsk):

• frostmoln_image-ressursen
• frostmoln_image-datakilden · frostmoln_images-datakilden

Start en instans fra det

Avbildene dine dukker opp overalt der et avbilde velges — portalens skjema for å opprette instanser, fm compute instance create --image <image-id>, image_id i Terraform.

Bare et avbilde som er Aktivt kan startes. Velgeren lister avbildene dine uansett tilstand, så et som venter eller har mislyktes, tilbys som alle andre, og opprettelsen av instansen mislykkes da. Sjekk statusen først.

Under importen registrerer plattformen avbildets minste disk ut fra dets virkelige utvidede størrelse og erstatter verdien du satte. En flavor med mindre rotdisk enn det kan ikke starte avbildet.

Når en import mislykkes

En mislykket import etterlater ikke avbildet i en feiltilstand. Den tilbakestiller avbildet til queued — samme status som et avbilde som aldri er lastet opp — og registrerer et eget importFailed-flagg. Den forskjellen betyr noe hvis du skriver din egen polling: poll etter active ELLER importFailed, aldri etter active alene, ellers venter skriptet ditt for alltid på en mislykket import.

Både portalen og fm compute image get viser det (Importen mislyktes / en advarselslinje), sammen med årsaken når plattformen kan fastslå en:

• Filen inneholder et annet diskavbilde — en qcow2 eksportert inne fra en annen qcow2. Å laste opp den samme filen på nytt mislykkes på samme måte. Eksporter gjestens disk fra hypervisoren som et vanlig qcow2- eller raw-avbilde, og last opp det i stedet.
• Filen bruker en funksjon som ikke kan konverteres — en backing-fil eller kryptering. Slå den sammen til ett enkelt ukryptert avbilde (qemu-img convert) og last opp det.
• Filen er ikke formatet du oppga — kontroller hva den faktisk er (qemu-img info viser det), oppgi riktig diskformat på avbildet og last det opp på nytt.
• Konverteringen mislyktes — som regel en avkortet opplasting eller et skadet avbilde. Kontroller at filen kan åpnes lokalt, og last den opp på nytt.
• Plattformen kunne ikke fastslå noen årsak — kontakt support og oppgi avbildets ID. Å laste opp den samme filen på nytt hjelper sannsynligvis ikke.

Hvis du spør API-et selv, heter årsaken importFailureReason på avbildet, og verdien er en av nestedFormat, unsupportedFeature, declaredFormat, conversionFailed eller unknown. Nye koder kan komme til når som helst — behandle en ukjent kode nøyaktig som unknown.

Årsaken blir liggende på avbildet, så den er der fortsatt etter en ny innlasting eller neste dag.

En feil bruker noen sekunder på å dukke opp, og det er med vilje. Plattformen får vite at en import mislyktes litt før den får vite hvorfor, og den publiserer ingen av delene før begge er klare — slik at du aldri får se "importen mislyktes" uten forklaring og med det ubrukelige rådet om å laste opp filen på nytt. I opptil et minutt ser avbildet derfor ut nøyaktig som et ingen har lastet opp til: queued, ingen importFailed. Fortsett å spørre. I det sjeldne tilfellet der plattformen ikke kunne fastslå noen årsak i det hele tatt, får du feilen uten årsak.

Ikke alle avslag havner her. En fil som ikke er et gyldig qcow2- eller raw-diskavbilde, et som oppgir en backing-fil eller er kryptert, og et der den utvidede størrelsen overstiger taket på 35 GiB, avvises alle umiddelbart, med en 400 og en melding som oppgir årsaken — importen starter aldri, og ingen importFailed registreres. importFailed betyr at filen besto de kontrollene og deretter mislyktes under konvertering eller lagring.

Uansett blir avbildet stående i Venter på opplasting, og du kan laste opp en rettet fil til den samme oppføringen.

Fakturering

Egne avbilder faktureres per GB-måned på avbildets logiske (utvidede) størrelse, i desimale GB, så lenge avbildet finnes — priset som et volumøyeblikksbilde. Størrelsen som vises i portalen, er den størrelsen du betaler for. Å slette et avbilde stopper kostnaden.

Prisene kommer fra plattformens priskatalog og vises i portalen; denne guiden oppgir ingen beløp. Se Fakturering.

Begrensninger

• Kun qcow2 og raw, containerformat bare.
• 35 GiB opplastet / 35 GiB utvidet per avbilde; 10 avbilder / 376 GB per tenant som standard. Hvor mange opplastinger som kan pågå samtidig, er også begrenset.
• Avbilder er private for din tenant — å dele et avbilde med en annen tenant er ikke tilgjengelig. Inne i tenanten er de ikke fortrolige: den som kan starte en instans, kan lese hele filsystemet.
• Ingen nedlasting eller eksport — et opplastet avbilde kan ikke hentes ut igjen som fil. Behold din egen kopi av alt du kan trenge igjen.
• Å lage et eget avbilde fra øyeblikksbildet av en kjørende instans er ikke tilgjengelig; last opp diskavbildet i stedet.

Relatert

• Databehandling / Instanser · Kvoter og fakturering
• fm CLI · Terraform-leverandør